Monday, November 26th, 2007
Traditionally, SGML-based HTML validation has treated most attribute values as “anything goes” strings. This has meant that all kinds of bogus values have passed as valid. W3C XML Schema added a fixed set of datatypes. The spec is mostly useless for HTML5 validation, since the HTML5 microsyntaxes do not match exactly the XSD datatypes for the same concepts. XSD regular expressions were suitable for representing the syntax of a number of HTML5 microsyntaxes, though. XSD datatypes can be used from RELAX NG and Validator.nu used to XSD regular expressions for many HTML5 microsyntaxes.
The problem with using XSD regular expressions has been that they are not user-friendly. When an attribute value did not match the required regular expression, the UI told the user that the attribute value was “bad”. Nothing else.
Fortunately, unlike XSD, RELAX NG allows pluggable datatype libraries. A datatype library is a library written in a general-purpose programming language. The RELAX NG engine calls the library to check if a string conforms to a named datatype. Validator.nu has used this approach for a long time for the more complex microsyntaxes in HTML5.
I have recently made an effort to move Validator.nu away from XSD regular expressions to a more comprehensive custom datatype library. Even though as a formalism regular expressions are sufficient for many syntaxes, writing checking by hand allows more useful error messages in cases of failure. Moreover, having identifiers for the datatypes makes it possible to tell which datatype failed as opposed to the UI being able to tell that some regular expression failed under the hood. This allows the UI to pull in per-datatype advice from a wiki page.
In addition to improving the user experience with previously supported microsyntaxes such as integers, I have implemented support for previously unsupported microsyntaxes such as MIME types and Media Queries.
There is still work to do. For example, the syntaxes for accept-charset and WF2 type=email are not done. data: and mailto: IRIs are not properly validated yet. The syntaxes for image map coordinates still use XSD regular expressions. The advice on the wiki page is far from complete. (You can help!)
For the parts already implemented, please try the new features out and let me know what needs improvement.
Posted in Conformance Checking, Syntax | Comments Off on Validating attribute values
Tuesday, November 20th, 2007
Currently, Validator.nu mines the HTML 5 spec for UI text describing permissible content models, element contexts and element-specific attributes. The text is shown when an element or attribute is misplaced on missing.
Unfortunately, the spec does not contain similarly extractable text for microsyntax descriptions. Microsyntaxes are syntaxes that appear mostly in attribute values—for example, HTML5 integer, Web Forms 2.0 week, RFC 2616 media types (aka. MIME types) or CSS3 Media Queries.
Based on IRC discussions, there is interest in producing the descriptions collaboratively. To that end, I have seeded the WHATWG wiki with a page for microsyntax descriptions. If you would like to help make validator messages better, please feel free to edit the wiki (under the MIT license).
Posted in Conformance Checking, Syntax | 1 Comment »
Friday, August 17th, 2007
There is now an open-source implementation of the HTML5 parsing algorithm in Java 5: the Validator.nu HTML Parser. The parser can be used as a drop-in replacement for the XML parser in applications that use SAX, DOM or XOM APIs to read XHTML 1.x content with an XML parser.
Posted in Conformance Checking, Processing Model, Syntax | Comments Off on Implementation of the HTML5 parsing algorithm in Java
Wednesday, August 15th, 2007
This is a French translation of HTML vs. XHTML.
L'un des problèmes prédominants soulevés dans un récent appel à commentaires était de parvenir à dépasser le débat HTML contre XHTML, car beaucoup de gens estimaient que nous devions chercher non pas à étendre HTML, mais à nous concentrer sur XHTML seulement.
Cependant, la chose que de nombreuses personnes n'ont pas saisi est que HTML 5 résoud ce problème : la spécification (X)HTML 5 se propose en fait d'étendre simultanément HTML et XHTML, et de ne pas faire dépendre ce choix sur le DOCTYPE.
De nombreux webmasters utilisent un DOCTYPE XHTML 1.0 et s'empressent ensuite d'annoncer qu'ils utilisent XHTML - mais les ce sont les navigateurs eux-mêmes qui font le choix ou non de traiter un document comme du HTML ou du XHTML en se basant sur ... le type MIME. (X)HTML 5 se propose de résoudre ce souci en se reposant exclusivement sur le type MIME - ainsi, si un document est servi comme text/html, il sera parsé comme du HTML ; mais s'il est servi avec un type MIME de type XML, comme application/xml ou application/xhtml+xml, il sera parsé comme du XHTML.
Sérialisation de document
HTML 5 introduit le concept de sérialisation pour un document HTML. Une sérialisation dans ce contexte fait référence à une représentation physique de l'essence même du document : son arborescence. (X)HTML 5 attend des agents utilisateurs qui supportent l'ajout de script qu'ils présentent l'arborescence du document en utilisant l'API DOM et le modèle de données. HTML 5 utilise la sérialisation HTML et XHTML 5 utilise la sérialisation XML. Grâce à cela, la distinction entre HTML et XHTML est réduite.
Dans la plupart des cas, chacun des deux types de sérialisation peut être employé pour représenter exactement le même document. Les différences principales sont que la sérialisation HTML, pour des raisons de compatibilité descendante, ne peut représenter de façon structurée des éléments de niveau "in-line" (alignés les uns à côté des autres, non-blocs) comme étant des enfants des enfants de l'élément <p> et que la sérialisation XML ne peut pas représenter la totalité des arborescences qui pourraient être le résultat d'un document généré à la suite d'une récupération d'erreur de l'algorithme du parseur HTML. De même, dans certains navigateurs, quelques fonctionalités particulières de l'API de scripting et quelques détails dans l'interprétation des styles CSS fonctionnent différemment suivant la sérialisation du document pour des raisons de compatibilité descendante.
La sérialisation XML utilisée par XHTML implique que le document soit bien formé (well-formed) au format XML 1.0. Cependant, contrairement au précédentes versions de HTML, la sérialisation n'est plus considérée comme une application de SGML mais définit à la place sa propre syntaxe. Cette dernière est inspirée par SGML, mais elle est définie d'une manière qui se rapproche plus de la façon dont les navigateurs gèrent HTML dans le monde réel - surtout en ce qui concerne la gestion des erreurs.
La sérialisation d'HTML 5 et les algorithmes de parsing qui l'accompagnent sont rendus nécessaire pour 3 raisons :
- Le navigateur qui a pour l'instant la plus forte part de marché ne supporte pas XHTML (du moins celui qui est effectivement servi et traité comme tel).
- L'ancien contenu text/html toujours présent sur le web a besoin d'un algorithme de traitement clairement défini - quelque chose que les spécifications HTML basées sur SGML n'ont pas été en mesure de fournir.
- Il existe des gestionnaires de contenu (CMS), des applications web et autres workflows qui ne sont pas basés sur des outils XML et sur qui on ne peut compter pour reproduire une sortie bien formée. Ces systèmes peuvent bénéficier des nouvelles fonctionnalités même s'ils ne fonctionnent nécessairement correctement avec la sérialisation XHTML.
D'un autre côté, grâce à la dualité HTML/XHTML, les nouveaux systèmes peuvent être directement conçus pour fonctionner avec des outils XML interne et convertir ensuite vers HTML 5 et à partir de HTML 5 lors des échanges de type entrée/sortie. Une fois que la base des navigateurs installés supportera correctement le type MIME application/xhtml+xml, ces systèmes pourront échanger le sérialiseur de sortie et utiliser des fonctionnalités autorisées seulement par XHTML telles que les listes placées dans des paragraphes.
Le nouveau DOCTYPE
Dans la pratique, le DOCTYPE sert à deux choses : la validation basée sur la DTD et (pour HTML seulement) la détection (sniffing) de DOCTYPE. Puisque HTML n'est plus considéré comme une application de SGML et qu'il y a de nombreuses limitations dans la validation basée sur les DTD, il n'y aura aucune DTD officielle pour (X)HTML 5.
Ainsi, lors de la sérialisation HTML, la seule raison pour laquelle on place un DOCTYPE est d'activer le mode "standard" dans les navigateurs. Du coup, puisqu'elle n'a plus besoin de faire référence à une DTD, la déclaration de type de document se trouve réduite à ceci :
<!DOCTYPE html>
Vous conviendrez avec moi que cette syntaxe est aussi simple qu'elle est facile à retenir. Mais pour XHTML, c'est encore plus simple : il n'y en a pas besoin ! Puisque les navigateur n'ont pas introduit et n'introduiront pas de détection de DOCTYPE pour le XML, il n'y a pas réellement besoin d'un DOCTYPE.
Cependant, il me faut admettre que l'absence de DTD dans XML présente encore un problème technique mineur : les références aux entités qui sont déclarées dans la DTD XHTML 1.0 ne pourront plus être utilisées. Toutefois, puisque les browsers n'utilisent pas de parseurs de validation et ne lisent pas les DTD depuis le réseau de toutes façons, l'utilisation d'entités n'est [de toutes façons] pas recommandée. Il est préférable d'utiliser les références des caractères ou un bon encodage (comme l'utf8) qui supporte nativement les caractères.
Vérification de la conformité
Vous devez sûrement vous demander comment il sera possible de valider la conformité d'un document sans DTD. Eh bien, cela est tout simple : il existe en fait d'autres méthodes, plus robustes, qui sont disponibles pour s'assurer de la bonne formation d'un document. Plusieurs langages de schéma, dont RELAX NG et Schematron pourraient être utilisés. Cependant, même eux ne pourraient exprimer totalement les besoins de (X)HTML 5 en termes d'éléments de conformité qu'il est possible de vérifier avec une machine.
Henri Sivonen est en train de développer un vérificateur de conformité pour HTML 5 qui est conçu pour donner des messages d'erreur qui vont au-delà de ceux qu'il est possible de fournir en utilisant une approche basée sur les DTD. Par exemple, la vérification de l'intégrité d'un tableau est une fonctionnalité qu'il est impossible d'implémenter en utilisant simplement une approche basée sur les DTD.
(more…)
Posted in Conformance Checking, Syntax | 1 Comment »