INFO : HTML 5, un grand pas...

HTML 5 : les documents deviennent des applications

La publication par le W3C de la premiere version de travail [1] de la=20
specification HTML 5 marque la reprise de travaux interrompus depuis=20
HTML 4.01 publie en decembre 1999. Elle represente donc un grand pas,=20
mais dans quelle direction?

Eric van der Vlist=A0 , Dyomedea ( [email protected] ).
---------------
Retrouvez cet article en ligne
(http://xmlfr.org/actualites/decid/080131-0001).

Donnez votre avis !
mailto:[email protected]?subject=3DRe:%20INFO%20:%20HTML%205,%20un%20gr=
and%20pas...
---------------

HTML 5 n'est pas HTML 4 + 1
Beaucoup d'encre electronique a deja coule depuis l'annonce de cette=20
publication et je ne reviendrai pas sur la liste factuelle des=20
differences entre HTML 4 et HTML 5 dont vous trouverez un resume [2]=20
dans le carnet web de Laurent Jouanneau=A0 .

Ces differences sont egalement exposees dans l'un des documents [3] de=20
la specification HTML 5 mais curieusement cette liste detaillee se=20
concentre sur le detail des differences syntaxiques sans evoquer les=20
differences de fond.

Ces differences sont pourtant clairement visibles des l'introduction=20
[4] :

"Le langage de balisage du World Wide Web a toujours ete HTML . HTML a=20
ete concu principalement comme un langage pour decrire semantiquement=20
des documents scientifiques bien que sa conception generale et ses=20
mises a jours successives lui aient permis d'etre utilise pour decrire=20
de nombreux autres types de documents. Le principal des domaines qui=20
n'ont pas ete correctement specifies par HTML est un sujet decrit de=20
maniere vague comme celui des applications web. Cette specification=20
tente de corriger cela tout en mettant a jour les specifications HTML=20
pour rectifier les problemes signales ces dernieres annees."

Cette introduction eclaire de maniere lumineuse le reste de ces=20
specifications : il s'agit de passer d'une logique de documents a une=20
logique d'applications et ce point est confirme a plusieurs autres=20
endroits, comme par exemple la section [5] intitulee "Relations avec=20
XUL, Flash, Silverlight, et autres langages proprietaires de=20
description d'interfaces utilisateurs" :

"Cette specification est independante des nombreux langages de=20
description d'interfaces utilisateurs proprietaires. Tout en etant=20
ouvert et independant de tout fournisseur, HTML fournit une solution=20
aux meme problemes sans risque de blocage par un fournisseur."

Pour comprendre cette evolution, il faut remettre les choses dans leur=20
contexte.

HTML a effectivement ete cree pour representer des documents. Son=20
succes vient de sa neutralite : bien que l'on puisse pretendre comme=20
j'aime a le faire [6] , que le Web 2.0 n'est que le Web comme il aurait=20
toujours du etre, les createurs de HTML ne pouvaient pas avoir imagine=20
tout ce que peuvent faire les applications web modernes. Si ces=20
applications sont possibles, c'est parce que HTML n'a pas cherche a=20
specifier ce qu'etait une application web et qu'il est suffisamment=20
generique pour decrire a la fois les applications du web du vingtieme=20
siecle, celles du web d'aujourd'hui et tres vraisemblablement celles du=20
web de demain.

A l'inverse, si HTML 4.01 avait cherche en 1999 a specifier ce qu'etait=20
une application web, il y a toutes les chances que cette specification=20
aurait du etre contournee pour permettre au Web 2.0 de se developper et=20
que cela ait pu contribuer a ralentir voir bloquer son developpement.

En ce sens, je fais a HTML 5 le meme reproche [7] que je fais a W3C XML=20
Schema : celui de vouloir specifier l'utilisation que l'on attend d'un=20
document au risque de limiter la creativite et d'accroitre le couplage=20
entre applications.

Alors que l'idee que les applications peuvent etre concues comme des=20
documents tend a s'imposer comme une evidence, HTML 5 cherche au=20
contraire a concevoir les documents comme des applications ce qui me=20
semble etre un grand pas... en arriere!

Retour sur l'histoire de HTML
Un autre point qui merite d'etre souligne sont les relations entre HTML=20
5 et XML en general et XHTML en particulier.

HTML 5 se presente comme etant a la fois la suite logique de HTML 4.01=20
et XHTML 1.1 et en concurrent de XHTML 2.0.

Sans vouloir reprendre l'historique [8] de ces langages, pour=20
comprendre la situation, il faut revenir quelques annees en arriere...

HTML a ete concu comme un vocabulaire SGML et utilise certaines=20
fonctionnalites qui permettent de reduire la verbosite des documents,=20
c'est le cas par exemple de certaines balises comme <img> ou <link> qui=20
n'ont pas besoin d'etre refermees en HTML .

XML a ete concu pour etre une simplification de SGML et cette=20
simplification ne permet pas d'utiliser ces fonctionnalites qui=20
reduisent la verbosite des documents.

Apres la publication de XML , le W3C s'est donc trouve avec d'un cote=20
une application ( HTML ) et d'un autre cote un meta langage ( XML ) qui=20
etaient incompatibles. Dans un souci de coherence bien comprehensible,=20
il fut decide de faire evoluer HTML pour le rendre compatible avec XML=20
en gardant le meme perimetre fonctionnel. Le nouveau vocabulaire fut=20
appele XHTML 1.0 et donna naissance a une version 1.1 gardant les memes=20
fonctionnalites mais les decoupant en modules pour les rendre=20
utilisables separement.

Ce travail accompli, le W3C commenca des travaux portant sur la=20
modernisation des formulaires de saisie ( XForms ) puis s'attaqua a une=20
nouvelle version majeure ( XHTML 2.0) encore en cours de=20
standardisation.

L'approche semble si logique et la demarche si peu contestable que le=20
W3C a sans doute neglige de verifier qu'il avait toujours le support de=20
la communaute. Dans l'euphorie qui accompagna la publication de XML 1.0=20
et l'accord parfait entre Microsoft et ses concurrents, l'interet pour=20
HTML maintenu auparavant par la =AB guerre des navigateurs =BB etaient=20
retombe et les travaux du W3C autour de XHTML se poursuivirent dans une=20
indifference quasi generale.

Il faut dire egalement que l'interet pratique de XHTML par rapport a=20
HTML etait loin d'etre evident pour les developpeurs de sites web=20
puisque les fonctionnalites etaient restees les memes. Migrer un site=20
vers XHTML represente donc un travail supplementaire qui ne presente=20
souvent aucun autre interet a court terme que de pouvoir afficher=20
fierement le logo =AB W3C XHTML 1.x =BB.

C'est egalement a cette periode que Microsoft abandonna pendant un=20
certain temps tout developpement sur son navigateur Internet Explorer=20
et ou Netscape transfera le developpement de son navigateur a Mozilla .

Les acteurs de la =AB guere des navigateurs =BB bien representes au W3C q=
ui=20
etait un de leur champs de bataille laisserent donc place a de nouveaux=20
acteurs, Mozilla , Opera et Apple / Safari plus jeunes et acceptant=20
sans doute plus mal les lourdeurs des procedures du W3C .

Dans le meme temps, les premieres applications Web 2.0 donnerent=20
egalement un regain de creativite aux developpeurs d'applications web=20
et tout ces mouvements s'opererent en dehors du W3C . Ce n'est guere=20
choquant puisque la vocation d'un organisme de normalisation comme le=20
W3C est de standardiser et non pas d'innover. Par contre, le W3C n'a=20
pas suffisamment pris la mesure de ces developpements et a laisse se=20
creuser un veritable fosse entre ses utilisateurs et ses groupes de=20
travail.

Et lorsque ces utilisateurs menes par Opera , Mozilla et Safari ont=20
ressenti le besoin de voir HTML s'ameliorer, plutot que de participer=20
aux travaux en cours sur XHTML 2.0, ils ont cree un groupe de travail,=20
le WHATWG [9] , a l'exterieur du W3C . C'est ce groupe de travail qui a=20
redige les premieres versions de HTML 5 ainsi que celles d'une=20
specification s?ur, Web Forms [10] 2.0 destinee a etre une amelioration=20
des fonctionnalites de formes de saisie de HTML moins complexe que=20
XForms .

Microsoft restant silencieux, le W3C se voyait donc redacteur d'une=20
specification XHTML 2.0 ne semblant pas interesser grand monde alors=20
que se developpait a l'exterieur de ses murs une specification se=20
reclamant de la tradition HTML et redigee par les principaux outsiders=20
des navigateurs web.

Lors de la conference XTech 2007, j'ai eu l'occasion de mesurer, lors=20
d'un debat contradictoire, le fosse qui separe les deux groupes. d'un=20
cote le groupe de travail XHTML 2.0 dans la continuite a la fois de=20
HTML mais aussi de XML et cherchant a tirer les lecons d'annees=20
d'experiences dans le domaine des langages de balisage et de l'autre le=20
groupe de travail WHATWG n'hesitant pas a rejeter XML en tant que tel,=20
se reclamant uniquement de HTML et donnant l'impression de chercher a=20
specifier le web tel qu'on le connait aujourd'hui.

Tim Berners-Lee=A0 a sans doute juge ce fosse trop large pour etre comble=
=20
puisqu'il a pris la decision [11] d'inviter le WHATWG a poursuivre ses=20
travaux au sein du W3C dans un groupe de travail forme pour l'occasion=20
et distinct du groupe de travail XHTML 2.0 qui continue egalement ses=20
travaux.

HTML 5 ou XHTML 2.0?
Le W3C a donc desormais deux groupes de travail.

Des missions tres proches
Le groupe de travail [12] XHTML [13] 2.0 [14] poursuit le developpement=20
d'un vocabulaire extensible base sur XML :

"La mission du groupe de travail XHTML 2 est d'accomplir la promesse de=20
XML de deployer XML sur une large variete de plateformes en accordant=20
une attention particuliere a l'internationalisation, l'accessibilite,=20
la portabilite entre plateformes, l'utilisabilite et la structuration=20
des documents. Le groupe apportera une piece essentielle aux contenus=20
riches sur le web en combinant XHTML avec d'autres travaux tels que les=20
mathematiques, les dessins vectoriels, les contenus multimedia=20
synchronises et les formulaires de saisie en cooperation avec d'autres=20
groupes de travail"

Le groupe de travail [15] HTML [16] assure quant a lui la continuite=20
avec les versions precedentes de HTML :

"La mission du groupe de travail HTML , au sein de l'activite HTML est=20
de poursuivre l'evolution de HTML (qui inclut les syntaxes HTML=20
classique et XML )."

La concision de cette phrase n'empeche pas HTML 5 de se vouloir=20
egalement extensible et independant des plateformes, puisque la liste=20
des livrables indique qu' "il y a un seul livrable, la specification=20
HTML , concue de maniere independante des plateformes" et que l'on=20
apprend un peu plus loin que "le groupe de travail HTML est encourage a=20
fournir un mecanisme pour permettre a des vocabulaires developpes de=20
maniere independante tels que nternationalization Tag Set ( ITS ), Ruby=20
, et RDFa d'etre melanges dans les documents HTML" .

Il s'agit donc bien, au risque de voir se developper une guerre des=20
standards de developper deux specifications concurrentes et de laisser=20
les utilisateurs choisir.

XHTML 5 n'est qu'un mauvais alibi
On retrouve cette politique au sein meme de la specification HTML qui=20
propose de choisir entre deux syntaxes :

"Cette specification definit un langage abstrait pour decrire des=20
documents et des applications et des APIs pour acceder a la=20
representation en memoire des ressources utilisant ce langage. La=20
representation en memoire est appelee " DOM5 HTML ", ou "le DOM " pour=20
faire court. Il peut y avoir de nombreuses syntaxes pour representer=20
des ressources utilisant de langage abstrait dont deux sont definies=20
dans cette specification. La premiere de ces syntaxes concretes est "=20
HTML5 ". C'est le format recommande pour la plupart des utilisations.=20
Elle est compatible avec tout les navigateurs historiques. Si un=20
document est transmis avec le type text/html, il devra etre traite=20
comme un document " HTML5 " par les navigateurs. La deuxieme de ces=20
syntaxes utilise XML et est appelee " XHTML5 ". Quand un document est=20
transmis avec un type XML tel que application/xhtml+xml, il doit etre=20
analyse avec un parseur XML et traite par les navigateurs comme un=20
document " XHTML5 ". Nous rappelons aux auteurs que le traitement de=20
XML est different du traitement de HTML et que notamment, meme les=20
erreurs de syntaxe mineures empechent un document XML d'etre affiche de=20
maniere complete alors qu'elles seraient ignorees avec la syntaxe "=20
HTML5 "."

Cette section [17] , heureusement non normative, semble exclure qu'un=20
navigateur puisse accepter un document HTML autre que HTML5 ou XHTML=20
autre que XHTML5 ! Et avec une telle mise en garde, on se demande quel=20
auteur va choisir le syntaxe XML ...

Cette mise en garde repose d'ailleurs sur une incomprehension helas=20
assez commune de la recommandation XML . On entend effectivement=20
souvent dire que l'analyse syntaxique d'un document XML doit s'arreter=20
a la premiere erreur, mais la recommandation est en fait beaucoup plus=20
souple que cela. Elle distingue [18] deux types d'erreurs :

- Les erreurs simples sont "une violation des regles de cette=20
  specification. Sauf specification contraire, le non respect d'une=20
  regle de cette specification indiquee avec un verbe DOIT, EXIGE, NE=20
  DOIT PAS, DEVRAIT et NE DEVRAIT PAS est une erreur. Les logiciels=20
  conformes PEUVENT detecter et signaler les erreurs et PEUVENT les=20
  corriger."
- Les erreurs fatales sont "une erreur qu'un processeur XML conforme=20
  [19] DOIT detecter et signaler a l'application. Apres avoir rencontre=20
  une erreur fatale, le processeur PEUT continuer le traitement des=20
  donnees pour rechercher d'autres erreurs et PEUT signaler ces erreurs=20
  a l'application. Pour assurer cette correction, le processeur PEUT=20
  rendre les donnees brutes en provenance du document (melangeant texte=20
  et balisage) disponible a l'application. Neanmoins, lorsqu'une erreur=20
  fatale est detectee, le processeur de DOIT pas continuer son=20
  traitement normal (c'est a dire qu'il NE DOIT PAS continuer a=20
  transmettre les informations sur le contenu textuel et la structure=20
  du document a l'application de maniere normale)."
On voit que la recommandation XML precise au contraire qu'un processeur=20
XML peut corriger les erreurs simples. On peut argumenter sur le fait=20
que ce que la recommandation XML appelle erreur fatale peut etre=20
considere par un auteur comme une erreur mineure (ce peut etre le cas=20
par exemple lorsqu'une balise <img> n'est pas refermee), mais meme en=20
cas d'erreur fatale, la recommandation n'impose pas d'arreter tout=20
traitement. Elle impose de signaler l'erreur a l'application (le=20
navigateur dans le cas d'un document lu sur le web) mais elle ne=20
specifie pas la maniere dont le navigateur doit reagir et permet de=20
continuer l'analyse du document pour peu que ce ne soit pas de maniere=20
=AB normale =BB.

Un navigateur qui deciderait de basculer dans un mode d'analyse degrade=20
apres detection d'un erreur fatale pour continuer a afficher le=20
document serait donc parfaitement conforme a la recommandation XML .

Si les navigateurs reagissent de maniere aussi stricte aux erreurs=20
d'analyse des documents XML , cela ne vient donc pas d'un souci de=20
respect de la recommandation, mais d'un souhait de la communaute XML au=20
moment ou ces navigateurs ont introduit le support de XML . On sortait=20
alors de la guerre des navigateurs entre Microsoft et Netscape et tout=20
le monde deplorait que pour supporter les extensions introduites de=20
maniere sauvage, les navigateurs en etaient venus a accepter a peu pres=20
n'importe quel document aussi peu conforme aux specifications soit-il=20
et a afficher les non conformites de maniere specifique parce que non=20
documentee.

En reaction a ce laxisme, il y a eu un consensus quasi absolu lorsque=20
les navigateurs ont decide de s'arreter a la premiere erreur rencontree=20
dans un document XML comme la recommandation leur permet mais ne leur=20
impose pas de le faire.

Si cette position doit etre assouplie, il serait dommage de rejeter XML=20
puisque nous avons vu qu'elle n'est en aucun cas imposee par la=20
recommandation.

La maniere dont sont presentees ces deux syntaxes laisse clairement=20
supposer que la mention de la syntaxe XML qui n'etait pas mentionnee=20
dans les premiers travaux du WHATWG est un compromis permettant=20
d'eviter a une recommandation W3C de tourner le dos a XML mais que le=20
but est bel et bien de maintenir et promouvoir l'utilisation d'une=20
syntaxe non XML .

HTML 5 coupe les ponts avec SGML
Non content de s'affranchir de XML , HTML 5 abandonne egalement toute=20
recherche de compatibilite avec SGML puisque la specification indique=20
que "bien que la syntaxe HTML de HTML5 ressemble a SGML et XML , il=20
s'agit d'un langage different avec ses propres regles d'analyse=20
syntaxique" .

Cette phrase est caracteristique de l'attitude generale de la=20
specification qui donne l'impression de vouloir se batir sur=20
l'experience du web en ignorant celle des langages de balisages au=20
risque la encore, de geler le web tel que nous le connaissons=20
aujourd'hui.

L'attitude du groupe de travail XHTML est plus mesuree. Il s'agit bien=20
entendu de prendre en compte les evolutions du web mais en utilisant=20
des approches qui tiennent egalement compte de l'experience acquise en=20
developpant d'autres vocabulaires XML ou SGML .

Des approches techniques opposees
Sans entrer dans une comparaison en detail des specifications HTML 5 et=20
XHTML 2.0, deux points meritent notre attention.

Seul XHTML 2.0 est extensible
Les deux specifications reconnaissent la necessite de mieux prendre en=20
compte les besoins apparus depuis la creation de HTML lorsqu'ils ne=20
sont pas deja pris en compte, mais la maniere de le faire est=20
totalement differente.

Pour HTML 5, la demarche a l'apparence de la simplicite : lorsqu'on=20
reconnait un nouveau besoin on rajoute un nouvel element. Puisque=20
beaucoup de pages web sont utilises pour publier des articles (au sens=20
large), on ajoute un element <article>. Puisque beaucoup de pages web=20
ont des barres de navigation on ajoute un element <nav>....

On a pourtant vu avec les grands vocabulaires utilises dans le domaine=20
de la documentation quelles sont les limites de cette approche : elle=20
conduit a une explosion du nombre d'elements et ce qui etait simplicite=20
se transforme en complexite. Il devient difficile de choisir quel=20
element utiliser et comme ces elements sont specialises, ils ne=20
correspondent que rarement exactement a ce que l'on cherche a faire.

Appliquer cette approche a HTML revient a plus ou moins long terme a le=20
transformer en un clone de DocBook pour le web...

L'approche du groupe de travail XHTML 2.0 est totalement opposee. Elle=20
propose au contraire de faire le menage dans la liste des elements=20
XHTML tels que nous les connaissons et a supprimer tout ceux qui ne=20
sont pas vraiment necessaires.

Elle s'appuie ensuite sur l'observation des pratiques actuelles :=20
comment fait-on aujourd'hui pour representer un article ou une barre de=20
navigation? L'approche la plus commune est d'utiliser des elements=20
standards, tels que l'element =AB<div>, et d'identifier ces element par=20
leur attribut =AB class =BB pour leur appliquer un style CSS ou une=20
animation JavaScript .

L'inconvenient de cette approche est que les classes utilisees ne sont=20
pas standardisees et que cela constitue un detournement de la=20
fonctionnalite de l'attribut =AB class =BB utilise pour qualifier la=20
signification d'un element plutot que la maniere dont il doit etre=20
presente a l'ecran. Ce detournement est devenu chose courante,=20
puisqu'il est a la base de l'approche des micro-formats.

Pour eviter ce detournement tout en gardant la souplesse de cette=20
approche, XHTML 2.0 propose d'introduire un attribut =AB role =BB=20
permettant de definir le role des elements XHML .

Cet attribut peut prendre un certain nombre de valeurs standards,=20
definies dans la specification (=AB navigation =BB par exemple pour une=20
barre de navigation) mais peut egalement prendre d'autres valeurs=20
differenciees par le mecanisme des espaces de noms XML .

Par ce biais, on peut donc introduire les memes fonctionnalites que=20
HTML 5 en evitant de creer de nouveaux elements. Ce mecanisme est plus=20
extensible puisque n'importe qui peut creer de nouveaux roles en=20
utilisant de nouveaux espaces de noms. Cela donne egalement aux=20
micro-formats le moyen de se developper sans detourner l'attribut =AB=20
class =BB qui peut reprendre sa fonction initiale et ne definir que la=20
presentation des elements.

Approche document ou approche application?
Le second point notable sur lequel les deux specifications divergent=20
est dans leurs relations entre donnees et applications ou traitements.

XHTML 2.0 s'appuie non seulement sur la syntaxe mais sur l'architecture=20
XML qui consiste a superposer les couches suivantes :

- Au plus bas niveau, on definit les regles syntaxiques, c'est a dire=20
  les recommandations XML et espaces de noms.
- Au dessus de ces regles, on definit un modele de donnees : l'infoset=20
  XML independant de tout traitement.
- S'appuyant sur ce modele de donnees, on definit ensuite des=20
  interfaces et des langages specifiques ( DOM , XPath , XQuery , ...)=20
  et des langages de schema ( W3C XML Schema , RELAX NG , Schematron ,=20
  ...).
Cette architecture a mis du temps a se construire et historiquement les=20
choses n'ont pas toujours ete aussi simple, mais elle dissocie=20
totalement donnees et traitements et permet un couplage lache entre=20
applications.

Nous avons vu que HTML 5 se coupe volontairement de ses racines XML et=20
SGML . Cela signifie egalement que cette specification ne s'appuie pas=20
sur cette architecture et au contraire, elle melange les aspects=20
syntaxiques, modele de donnees et interface ( DOM ) dans une seule=20
specification sous un pretexte de simplicite.

Cette conception est liee au fait que HTML 5 se presente, nous l'avons=20
vu en introduction, comme un format permettant de developper des=20
applications web. On ne parle plus de documents mais bien de=20
developpement d'applications.

La difference me semble importante notamment en matiere de perennite :=20
les documents sont transformables et reutilisables et tout le monde=20
s'accorde a dire que l'utilisation de XML est la meilleure garantie=20
pour la conservation a long terme des documents. Il n'en va pas de meme=20
des applications. Une application HTML 5 combinant du texte, du=20
balisage et une bonne dose de JavaScript a t-elle la meme perennite=20
qu'un document XHTML 2.0? J'en doute fort.

L'architecture XML sur laquelle est batie XHTML 2.0 n'empeche pas=20
l'ecriture d'applications web, mais elle dissocie plus clairement ce=20
qui est donnees et ce qui est traitement.

XHTML 2.0 cherche egalement a promouvoir, notamment au travers de=20
XForms , des methodes de developpement declaratives mieux adaptees que=20
JavaScript a l'architecture orientee documents a laquelle HTML 5=20
cherche a echapper.

Que le meilleur gagne?
Pour toutes ces raisons, HTML 5 me semble constituer un grand pas en=20
arriere et je considere XHTML 2.0 comme lui etant la seule alternative=20
techniquement viable et souhaitable.

Est-ce que cela signifie pour autant que XHTML 2 va s'imposer et le=20
fait que HTML 5 soit tire par ceux qui developpent les navigateurs de=20
demain ne signifie t-il pas au contraire que c'est HTML 5 qui=20
l'emportera?

XHTML 2.0 semble effectivement avoir un serieux handicap sur ce plan,=20
mais les des ne sont pas jetes. Le groupe de travail ne prevoit pas que=20
HTML 5 devienne recommandation avant le troisieme trimestre 2010 et=20
d'ici la bien des choses peuvent encore changer.

Il nous revient en tant qu'utilisateurs de faire savoir ou va notre=20
preference en commencant par boycotter les fonctionnalites HTML 5=20
qu'implementent deja certains navigateurs.

A court terme, certifier qu'une page est conforme XHTML 1.x est=20
egalement un moyen de certifier qu'elle ne contient pas de HTML 5!

Voir aussi :

- Vers une nouvelle guerre du Web? [20]
- XML, quel historique ? [21]
- Web 2.0 : mythe et realite [22]
Copyright 2008, Eric van der Vlist .

---------------------------------------------------------
References:
[1] http://www.w3.org/TR/2008/WD-html5-20080122/
[2]=20
http://www.ljouanneau.com/blog/2008/01/23/747-premier-brouillon-de-html5
[3] http://www.w3.org/TR/2008/WD-html5-diff-20080122/
[4] http://www.w3.org/TR/2008/WD-html5-20080122/#introduction
[5] http://www.w3.org/TR/2008/WD-html5-20080122/#relationship1
[6] http://xmlfr.org/actualites/decid/051201-0001#N506
[7] http://xmlfr.org/actualites/decid/020905-0002
[8] http://xmlfr.org/documentations/articles/000321-0001
[9] http://www.whatwg.org/
[10] http://www.whatwg.org/specs/web-forms/current-work/
[11] http://dig.csail.mit.edu/breadcrumbs/node/166
[12] http://www.w3.org/MarkUp/
[13] http://www.w3.org/MarkUp/
[14] http://www.w3.org/MarkUp/
[15] http://www.w3.org/2007/03/HTML-WG-charter
[16] http://www.w3.org/2007/03/HTML-WG-charter
[17] http://www.w3.org/TR/2008/WD-html5-20080122/#html-vs
[18] http://www.w3.org/TR/2006/REC-xml-20060816/#sec-terminology
[19] http://www.w3.org/TR/2006/REC-xml-20060816/#dt-xml-proc
[20] http://xmlfr.org/actualites/decid/050603-0001
[21] http://xmlfr.org/documentations/articles/000321-0001
[22] http://xmlfr.org/actualites/decid/051201-0001
---------------------------------------------------------
Mail genere par FormatedTextOutputHandler pour XT=20
(http://4xt.org/downloads/examples/outputhandlers/formatedtext/).