PUBLIC MARKS with tag html5

Pour HTML 5, la démarche a l'apparence de la simplicité : lorsqu'on reconnaît un nouveau besoin on ajoute un nouvel élément. Puisque beaucoup de pages web sont utilisées pour publier des articles (au sens large), on ajoute un élément <article> Puisque beaucoup de pages web ont des barres de navigation on ajoute un élément <nav>....

L'approche du groupe de travail XHTML 2.0 est totalement opposée. Elle propose au contraire de faire le ménage dans la liste des éléments XHTML tels que nous les connaissons et à supprimer tout ceux qui ne sont pas vraiment nécessaires.

Elle s'appuie ensuite sur l'observation des pratiques actuelles : comment fait-on aujourd'hui pour représenter un article ou une barre de navigation? L'approche la plus commune est d'utiliser des éléments standards, tels que l'élément «<div>, et d'identifier ces élément par leur attribut « class » pour leur appliquer un style CSS ou une animation JavaScript.

L'inconvénient de cette approche est que les classes utilisées ne sont pas standardisées et que cela constitue un détournement de la fonctionnalité de l'attribut « class » utilisé pour qualifier la signification d'un élément plutôt que la manière dont il doit être présenté à l'écran. Ce détournement est devenu chose courante, puisqu'il est à la base de l'approche des microformats.

Pour éviter ce détournement tout en gardant la souplesse de cette approche, XHTML 2.0 propose d'introduire un attribut « role » permettant de définir le rôle des éléments XHML.

HTML5, however, exposes the varying state of the tree throughout; an application may examine a new element's parent pointer at one point, find one value, and then examine it after new events have been processed and find a different value. The very nature of SAX events prohibits that degree of flexibility.

Implémenter le modèle de parsing de HTML5 dans libxml est-il possible sans bouleverser la structure interne de libxml ?

Validator.nu does offer file upload and pasting file contents in its complex generic facet

Comet doesn’t have to be a hack. Currently, as we saw last time, Comet relies on undocumented loopholes and workarounds, each one with some drawbacks. We can make Comet work effectively in every browser, using streaming transports on subdomains of the same second-level domain, or using script tag long polling across domains. But this leaves Comet developers implementing (and more frustratingly, debugging) several transports across several browsers. Traps are numerous and easy to stumble into.

event-source is the future of all Comet things.

WebKit had a number of minor parsing bugs that Acid 3 targeted. [...] We have updated our parser to be much closer to the HTML5-specified parsing rules.

Eric van der Vlist est plus que sceptique sur html5.

Sur certains points il n'a pas tort, ne pas se reposer sur les technologies xml et introduire trop de nouvelles balises par exemple.

Cependant, html5 standardise les pratiques présentes dans les navigateurs d'aujourd'hui en ce qui concerne l'analyse des documents, ce qui est peut-être tard mais bien. En outre, le dévelopeur web apprécie la standardisation d'avancées importantes des navigateurs d'aujourd'hui. xhtml 2 + 5 = 7 ?

For all these reasons, HTML 5 looks to me as a big step backward and XHTML 2.0 seems to be a much better alternative.