Normalisation HTML5 2D-Context

Bonjour.

nous sommes dans cette section du forum directement concernés par plusieurs normes.
la première qui normalise le langage est Ecmascript de ECMA
la seconde qui normalise quels objets un navigateur internet met à disposition du langage est HTML du W3C.

Le W3C vient de faire un pas en avant pour HTML la norme est finalisée. en clair l'API est arrêtée et une release candidate vient d'être publiée, cela signifie que très peut de chose sont succeptible de changer d'ici la normalisation complète. seuls des éléments mineurs pourraient encore évoluer.
http://www.w3.org/TR/2012/CR-html5-20121217/

Mais nous avons droit à une autre norme. En effet certains éléments avaient été ajouté par divers constructeurs à HTML. mais le W3C a préféré ne pas les intégrer directement. La raison est simple il est possible de les utiliser hors de HTML.
le W3C a donc normalisé de façon indépendante de HTML le canvas et vient là aussi de publier une candidate finalisée.
http://www.w3.org/TR/2012/CR-2dcontext-20121217/

Le point fondamental de ces normes qui nous concernent directement est que HTML5 n'est pas une norme sur un langage de balisage comme l'était HTML4.
HTML5 ne normalise pas le langage de tag pour décrire une page. Mais il normalise l'implémentation DOM que le navigateur doit faire. Le balisage n'est qu'une forme sérialisée du DOM.
Ces deux normes s'appuient pour cela sur une troisième que nous allons devoir apprivoiser si ce n'est déjà le cas.
http://dev.w3.org/2006/webapi/WebIDL/
comme vous pouvez le voir elle n'est pas toute jeune.
l'ensemble HTML5 est décrit sous forme web IDL.

A+JYT

Citation:

---

HTML5 ne normalise pas le langage de tag pour décrire une page. Mais il normalise l'implémentation DOM que le navigateur doit faire. Le balisage n'est qu'une forme sérialisée du DOM.

---

Très intéressant tout ça. Si le balisage n'est considéré à présent que comme une forme sérialisée du DOM, la question qui me brûle les lèvres c'est : une parmi d'autres ? Le M de HTML pour markup sera-t-il toujours approprié à l'avenir ?

Re.

Je reviens sur un point qui me parait fondamental (même s'il ne bouleversera pas ne habitudes immédiatement)

Dans les version antérieures HTML à été normaliser à partir du langage de balise. de cette norme sur le balisage on a ajouté une représentation le DOM puis on a ajouté des spécification sur l'API que le navigateur devait implémenter.

Avec HTML on prend les choses dans le sens opposé.

Citation:

---

Envoyé par w3c

Implementations must support DOM Core and the events defined in DOM Events, because this specification is defined in terms of the DOM, and some of the features are defined as extensions to the DOM Core interfaces.

---

ce point est très important. ce qui fait fois c'est le DOM. doc tout ce qui peut produit un DOM respectant cette spécification est conforme à la norme HTML5 et ce même s'il n'y a pas une seule linge de code source html.

on peut légitimement se poser la question du code source HTML. la réponse tient en 4 lignes

Citation:

---

Envoyé par w3c

The following features are defined in the DOM Parsing and Serialization specification:
innerHTML
outerHTML
insertAdjacentHTML

---

ce que nous dit donc la norme c'es que l'écriture d'un code source pour HTML5 ne relève pas de la norme HTML5 mais de la norme sur la sérialisation et le parsing du DOM. on peut noter que cette norme n'est qu'à l'état de DRAFT.

en l'état nous avons donc un DOM qui est arrêté et dont l'API EcmaScript est elle aussi arrêtée. et de l'autre une écriture HTML qui est en DRAFT.

Si vous utilisé l'API DOM dans vos scripts l'avancement des travaux vous garanti que si vous resté conforme à la norme HTML5 vos scripts sont pérennes.
par contre si vous utiliser du code source HTML ie innerHTML, outerHTML, et insertAdjacentHTML le contenu de ces éléments n'étant pas arrêté est susceptible d'évoluer. et donc vos script ne sont pas pérennes.

Il convient de relativiser les évolutions sur la syntaxe HTML5 on peu de chance d'évoluer fondamentalement.

Un point qui me parait intéressant est l'apparition de toJSONdans les spécifications de Web IDL
Je n'ai pas encore exploré la chose mais il semble que la norme Web IDL prévoit que les objets sérialisables doivent implémenter cette méthode. et HTML5 se base sur Web IDL. il sera intéressant de vérifier que les élément du DOM soit sérialisable en JSON
car si tel est le cas les échange de fragments pourront se faire par ce biais.

A+JYT

Bonjour

C'est bien connu, le monde est simple et notre environnement de travail est simpliste. :aie:

Les projets et les normes du W3C sur le HTML5 me laissent indifférent depuis le coup du XHTML2 je t'aime moi non plus.

Depuis ce jour-là, je me suis promis de ne plus faire que du HTML et de suivre une seule spécification : HTML: The Living Standard (A technical specification for Web developers).

Je reviens sur toJSONau premier abord cela m'est apparut evident.

Le DOM est défini en terme Web IDL et Web IDL laisse apparaitre les mesthodes

Code:

---

toString

---

et

Code:

---

toJSON

---

j'ai donc suputé que les éléments du DOM implémentaient ces deux méthodes.

Mais il n'en est rien seul les objet JS du navigateur implémente cette méthode.

Code:

---

1 2	var date = new Date(); console.log(date.toJSON());

---

c'est dommage car avoir une forme standard JSON de fragment HTML aurrait permis de charger des fragment via XHR dans ce format sans trop d'efforts.

la norme DOM HTML5 Serialisation/Parsing propose donc deux sérialisation
HTML et XML les deux étant quasi similaires. la deuxième est en fait une écriture XHTML du DOM5

A+JYT

Citation:

---

c'est dommage car avoir une forme standard JSON de fragment HTML aurrait permis de charger des fragment via XHR

---

D'un autre côté tous les frameworks front à la mode ont leur solution de templating en Javascript (angular, ember, backbone...). Perso je trouve old-school de charger directement du DOM (même sous une autre forme que HTML) plutôt que de la data pure et dure. Sauvegarder côté client les vues en templates précompilés, c'est une sacrée optimisation. C'est d'autant plus important pour le mobile (sur un de mes projets handlebars et des web-services envoyant du JSON ont pratiquement divisé par deux le temps de chargement de nos pages sur smartphone)