Discussion :

[sekaijin]

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

[SylvainPV]

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 ?

[danielhagnoul]

Bonjour

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

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).

[sekaijin]

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 :

S�lectionner tout - Visualiser dans une fen�tre � part

toString

et

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

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 :

S�lectionner tout - Visualiser dans une fen�tre � part

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

[SylvainPV]

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)

[sekaijin]

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�.

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

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