<foo>
simply produces <foo>in the text).
<URL: http://somewhere.tld/ >
,
and it will be automatically made into a link.
(Do not try any other way or it might count as an attempt to spam.)mailto:
URI,
e.g. mailto:my.email@somewhere.tld
,
if you do not have a genuine Web site).
patrick (2011-12-05T05:24:15Z)
"La raison est sans doute entre autres parce que le XML oblige un navigateur qui détecterait une erreur de non-bien-formitude dans une page XHTML à ne rien afficher du tout sauf le message d'erreur (et de fait, c'est ce que fait Firefox)."
Ça, ce n'est pas tout à fait vrai : http://xmlfr.org/actualites/decid/080131-0001 (à partir de "Cette mise en garde repose d'ailleurs sur une incompréhension hélas assez commune de la recommandation XML")
.
xavier (2011-12-04T14:16:42Z)
Sous quelle forme aimerait on avoir les règles régissant ce qui se passe "après ce parseur"?
Ruxor (2011-12-03T23:14:06Z)
Il y a plusieurs niveaux. Le parseur, celui qui se contente de transformer la séquence d'octets constituant le fichier HTML en un arbre de balises (ce qu'on appelle le DOM) est complètement spécifié. Mais après ce parseur, il faut vérifier que les balises existent bien, que chacune contient les balises qu'elle a le droit de contenir, etc., i.e., valider l'arbre DOM. C'est ça la partie difficile. Mais quant à savoir pourquoi c'est à ce point compliqué qu'il faille 400Mo de validateur pour y arriver, c'est bien ma question, et je n'ai pas la réponse.
xavier (2011-12-03T22:30:57Z)
"décrit de façon complètement formelle" à propos de HTML5 : Qu'est ce qui rend alors un validateur si compliqué??
La description formelle est sous une forme totalement imbittable?
Produire des rapports d'erreurs bittables pour un humain est très délicat MAIS dire si c'est ok ou pas devrait être une trivialité.