D'abord, je continue à penser que le xhtml valide est un frein à la publication. Ce n'est pas comme de dire que l'orthographe est un frein à l'expression
Surtout, la grosse différence, c'est que si ton message contient des fautes d'orthographe, il est quand même en général accepté par le récepteur (avec des niveaux de tolérance variés selon les individus).
Avec le XHTML validé en mode XML, bernique !
Ok, on demande au navigateur un surcroit de travail, mais je me demande si ce n'est pas de demander au codeur un surcroit de travail, qui énerve.
Bien vu. La majorité des gens ici sont des programmeurs (je le suis aussi) qui valorisent leur tranquillité. Mais c'est perdu d'avance : toute l'informatique va au contraire dans le sens d'une complexification de la tâche des programmes, précisément pour simplifier celle des utilisateurs.
(c'est même à ça que sert l'informatique, hein)
Le pire c'est qu'il n'y avait absolument pas besoin de XML pour rendre la grammaire un peu plus rigoureuse. Il suffisait de spécifier dans la norme HTML la machine à états qui construit l'arbre à partir des balises. Ce serait pas la première fois qu'une norme spécifie une machine à états.
Le pire c'est qu'il est à peu près admis que XML n'est pas fait pour être produit par un être humain (juste lu, et encore... vas-y pour lire du RDF encodé en XML). Mais sur ce forum on nous explique benoîtement que des webmestres devraient être capables de coder le XHTML dans le texte, et sans erreur.
(et les zigotos qui pensent qu'omettre des balises fermantes empêche un parsing rigoureux n'ont jamais dû utiliser Python, ou alors ils n'ont pas remarqué que le parser savait refermer une classe en même temps que la dernière méthode... et penser que ça bouffe beaucoup de cycles CPU est quand même d'une ânerie grave, les algos de positionnement CSS sont certainement mille fois plus compliqués)
Mais le W3C trouvait sûrement plus rigolo de lancer un autre standard parallèle à l'original, en plus on peut mettre du MathML dans les pages, chouette, ça va servir à au moins 0,01% des webmestres... Et à côté de ça, aucune fonctionnalité importante en plus, tout ce qui est bouge étant du côté de CSS, Javascript, Ajax & co (c'est-à-dire de façon orthogonale au schisme HTML/XHTML).
[^] # Re: IE, HTML à la papa et XHTML
Posté par Antoine . En réponse à la dépêche Tim Berners-Lee évoque l'avenir d'(X)HTML. Évalué à 3.
Surtout, la grosse différence, c'est que si ton message contient des fautes d'orthographe, il est quand même en général accepté par le récepteur (avec des niveaux de tolérance variés selon les individus).
Avec le XHTML validé en mode XML, bernique !
Ok, on demande au navigateur un surcroit de travail, mais je me demande si ce n'est pas de demander au codeur un surcroit de travail, qui énerve.
Bien vu. La majorité des gens ici sont des programmeurs (je le suis aussi) qui valorisent leur tranquillité. Mais c'est perdu d'avance : toute l'informatique va au contraire dans le sens d'une complexification de la tâche des programmes, précisément pour simplifier celle des utilisateurs.
(c'est même à ça que sert l'informatique, hein)
Le pire c'est qu'il n'y avait absolument pas besoin de XML pour rendre la grammaire un peu plus rigoureuse. Il suffisait de spécifier dans la norme HTML la machine à états qui construit l'arbre à partir des balises. Ce serait pas la première fois qu'une norme spécifie une machine à états.
Le pire c'est qu'il est à peu près admis que XML n'est pas fait pour être produit par un être humain (juste lu, et encore... vas-y pour lire du RDF encodé en XML). Mais sur ce forum on nous explique benoîtement que des webmestres devraient être capables de coder le XHTML dans le texte, et sans erreur.
(et les zigotos qui pensent qu'omettre des balises fermantes empêche un parsing rigoureux n'ont jamais dû utiliser Python, ou alors ils n'ont pas remarqué que le parser savait refermer une classe en même temps que la dernière méthode... et penser que ça bouffe beaucoup de cycles CPU est quand même d'une ânerie grave, les algos de positionnement CSS sont certainement mille fois plus compliqués)
Mais le W3C trouvait sûrement plus rigolo de lancer un autre standard parallèle à l'original, en plus on peut mettre du MathML dans les pages, chouette, ça va servir à au moins 0,01% des webmestres... Et à côté de ça, aucune fonctionnalité importante en plus, tout ce qui est bouge étant du côté de CSS, Javascript, Ajax & co (c'est-à-dire de façon orthogonale au schisme HTML/XHTML).