XHTML est mort, vive HTML !

\o/
Ça fera ça de trolls en moins.

Mais oui mais non, c'est XHTML2 qui est mort, heureusement pas XHTML! HTML5 sera proposé autant en text/html qu'en pur xml (XHTML5, donc).

Sachant que Shantanu Narayen, le CEO d’Adobe déclare attendre la sortie officielle de l’HTLM 5 dans 10 ans : http://daringfireball.net/linked/2009/06/22/a...
On a le temps d'attendre ;)

@Benjamin D.C. : oui mais ça faisait moins d'effet dans le titre :D
J'ai précisé que XHTML 1.1 subsisterait (et par extension XHTML 1.0)

@krakkos : HTML5 est *déjà* implémenté dans pas mal de navigateurs.
C'est aussi le cas de CSS 2.1 (qui n'est encore qu'en Candidate Recommandation, si si) et CSS 3 : tous deux sont déjà bien utilisés par nos navigateurs alors qu'ils ne sont pas encore officiels.
Les navigateurs et les usages évolueront toujours plus vite que les standards...

J'ai envi de cire une connerie, alors j'me lance...

Pourquoi non de non, les mises en place des ces standards sont ils aussi longs !!! ?

C'est juste fou que le web qui bouge autant soit encore basé sur des specs d'il y a 10 ans..
En lisant hier un post sur IE6 taxé d'être un vieux clou de 8 ans, j'en viens à me demander ce qu'on attends pour avancer vraiment.

non ?

@Benjamin D.C. : Ouais mais maintenant ça se résume à parler chiffons autour d'une même spéc. Ce qui est largement préférable à parler chiffons _et_ de deux trucs différents.

C'est une bonne nouvelle pour le web je pense. La co-existante de ces 2 "formats" d'écriture était une incohérence selon moi. XHTML n'ést qu'une règle d'écriture du HTML plu sémantique basé sur le XML. Aujourd'hui tout le monde est d'accord pour dire que coder de manière sémantique est la bonne méthode donc l'écriture permissive du HTLM4 façon SGML n'a plus raison d'être.
D'ailleurs si l'on regarde de plus près on peut voir que la déclaration du <doctype> dans HTML5 a été simplifié car désormais il n'y aura plus qu'une seule façon d'écrire du HTML... tout se tient.
http://www.w3.org/TR/html5-diff/#doctype

@Raphael : Il y a une erreur sur l'acronyme XHTML, c'est eXtensible et non eXtended.

C'est une bonne nouvelle qu'il n'y ait plus qu'un seul standard mais j'aime toujours pas HTML5 donc je suis partagé sur cette news …

@ernstein : Quand tu parles de mise en place, tu parles de la rédaction et de la validation d'une spec, ou de son implémentation par les agents utilisateur (navigateurs)?

Il est vrai que la rédaction d'une spec est longue, car c'est un processus exigeant et que sur de très nombreux points il faut obtenir un consensus des acteurs, acteurs qui sont tous des concurrents plus ou moins directs sur un même marché. Ceci dit, il faut noter deux choses. La première, c'est que l'on se fout pas mal des dates du type «HTML 5 sera une spécification en 2020». En effet, selon le W3C une recommandation candidate ne devient une recommandation que lorsqu’elle est implémentée complètement (ou éventuellement avec quelques réserves, ce serait à vérifier) par 2 acteurs différents. Je ne suis pas sûr que cette règle ait toujours été appliquée (je ne crois pas qu’il y ait deux implémentations complètes de HTML 4.01 par exemple), mais c’est celle retenue pour HTML 5 et les travaux en cours du W3C. Ce qui ne veut PAS dire que la spécification ne sera prête qu’en 2020! Le but du HTML Working Group actuellement est d’arriver à un document stable cet automne (en 2009, donc). Et d’aboutir, après corrections de ce document (en fonction de “bugs” de la spécification et de retour suite aux premières implémentations) à une recommandation candidate (Candidate Recommendation) en 2012.

À retenir donc comme dates: fin 2009 ou au pire début 2010 pour une version stable et complète de HTML 5. 2012 pour la recommandation candidate. La date de 2020 est négligeable.

Deuxième chose à noter: faire avancer les spécifications, c’est bien. Mais il ne faut pas prendre une distance trop grande avec les implémentations. La majeure partie de CSS 3 est restée lettre morte pendant des années, les navigateurs travaillant à compléter et corriger leur support de CSS 2 (puis CSS 2.1). Ce n’est que récemment (deux ans environ) que le support de CSS 3 fait timidement son apparition dans les navigateurs. Donc la lenteur observée est aussi due aux implémentations. Et là, ça s’explique par des stratégies de gestion dans certains cas, par un manque de ressources dans d’autres.

Je crains de ne pas avoir complètement compris la news. Cela signifie que dans le future, XHTML va complètement disparaitre et que HTML5 sera la seule norme HTML ?

@Skoua : : XHTML 1.0 et 1.1 resteront tout à fait valides, comme le sera encore longtemps HTML 4.01.

@Raphael : OK je viens de lire un peu la FAQ du W3C concernant ça, apparemment ils comptent inclure la déclinaison XML de HTML directement dans HTML5 de ce que j'ai compris.
Donc, si j'ai bien compris, il s'agit plutôt d'une bonne nouvelle car ils vont se concentrer sur HTML5 plutôt que partir dans deux voies différentes. C'est ça ? :D

@Skoua :

Acte 1: le W3C travaille sur un successeur à XHTML 1.1, nommé XHTML 2. Ce dernier est novateur mais casse la compatibilité avec les contenus HTML 4 pour une bonne partie.

Acte 2: certains acteurs du marché, pas convaincus par l'orientation de XHTML 2, travaillent en dehors du W3C dans un groupe nommé WHAT-WG, et travaillent sur une amélioration progressive de HTML 4.

Acte 3: le W3C récupère en son sein ce travail, qui devient HTML 5, avec sa déclinaison XML: XHTML 5. Le travail sur XHTML 2 n'est pas abandonné, mais est pour ainsi dire au point mort.

Acte 4: abandon de XHTML 2. Le groupe de travail sur XHTML 2 doit se concentrer sur la maintenance de XHTML 1.0 et 1.1 (publier des révisions, un peu comme HTML 4.01 qui est une révision de HTML 4), et des ressources supplémentaires sont allouées à (X)HTML 5.

«Donc, si j'ai bien compris, il s'agit plutôt d'une bonne nouvelle car ils vont se concentrer sur HTML5 plutôt que partir dans deux voies différentes.»

Si on pense que les orientations de (X)HTML 5 sont meilleures que celles de XHTML 2, alors oui c'est une bonne nouvelle. Si on pense le contraire, c'est une mauvaise nouvelle (mais pas surprenante car c'était en gestation).

@Florent V. : OK merci pour ta réponse, je comprends mieux l'idée.
Etant donné que HTML5 commence doucement à être supporté par les navigateurs, ce qui n'est pas le cas de XHTML 2, on peut donc se dire que cette décision va provoquer une accélération (ou du moins ne pas ralentir) l'implémentation des futures versions de HTML par les navigateurs, car ils n'auront pas à se soucier d'implémenter les deux.

Pour ce qui est de la meilleure version, vous qui êtes plus que pros dans le domaine, vous auriez préféré qu'on garde XHTML 2 ou HTML 5 ?

Tant que tout reste sémantiquement correct, et accéssible à tous, peu importe le nom, c'est un bon langage. Les bons développeurs continueront à séparer le font de la forme, et les autres se feront lapider.

Par contre, si je me souviens bien, n'y avait-il pas une histoire de classe prédéfini, ou quelque chose comme ça, en HTML5 ? Il faudra quand même le réviser un peu plus à la sauce XML, ce langage, et éviter ce genre d'horreur.

Salut tout le monde,

Je vois que le web avance à grand pas. Merci Raphaël pour ton article. À propos d'une réponse que tu as faite et si j'ai bien saisie, tout CSS 2.1 est supporté par les navigateurs. Est ce que par exemple les pseudos classes :before et :after le sont ?

Après lecture de ton article, j'ai fait également une recherche en rapport avec ce dernier. N'étant pas anglophone totalement, je suis tombé sur le lien qui suit : [url=http://xhtml.com/fr/future/x-html-5-versus-xhtml-2/#x2]X/HTML 5 Versus XHTML 2[/url].

Bonne soirée à tous :)

Ah, ils se sont enfin décidé !
La séparation xHTML2 et HTML5 était une simple aberration.
Que nous préférions les règles xHTML2 ou HTML5, n'a que peu d'importance finalement, le plus important à mon humble avis étant que nous ne nous retrouvions pas avec deux voies différentes alors qu'il n'y avait aucune raison logique à la base.

@Nolem : "Est ce que par exemple les pseudos classes :before et :after le sont ?"
A partir d'IE8, oui.

Le titre de l'article est plus qu'exagéré, il est parfaitement mensonger.

C'est xhtml 2 qui officiellement abandonné. Il l'était de fait depuis plusieurs années.
Mais il y aura un standard xhtml 5, version xml de html 5. Celle-ci devra être servi en type mime application/xhtml+xml ou application/xml. Cela pose problème avec les anciennes versions d'IE mais celles-ci sont évidemment également incapables de parser du html 5.
Bref quand html 5 pourra être généralisé, xhtml 5 pourra l'être aussi.

Le débat html / xhtml est hautement trollesque et reflète souvent une opposition entre une approche pragmatique et sincère (html me suffit largement j'ai pas besoin de faire le malin en xhtml) face à une posture d'esbroufe (xhtml c'est le top même si en fait je n'en aucune utilité et que je sais même pas ce qu'est xslt, ni xpath). Et il n'y a d'ailleurs pas pire escroc que celui qui travaille en xhtml 1.0 transitional. Mais quand même...

Quand on travaille dans des processus impliquant beaucoup de xml, utiliser du html, au lieu de xhtml, peut devenir franchement incongru et bloquant. Un contenu balisé xhtml peut-être traité en tant que xml. C'est une approche théorique pour certains ; pour d'autres c'est une utilisation quotidienne. Cette utilisation de contenu xhtml en tant que xml devrait s'étendre très fortement demain, ne serait-ce qu'avec les technologies du web sémantique.

Au contraire du titre de l'article, on peut penser légitiment que xhtml 5 a un bel avenir devant lui...

«Le titre de l'article est plus qu'exagéré, il est parfaitement mensonger.»

Je suis d’accord. Un titre correct aurait été «XHTML 2 est mort, vive XHTML 5!».

Le truc que beaucoup de gens ignorent c'est que la différence entre text/html et application/xhtml+xml ne se limite pas à une question de syntaxe, deux codes identiques peuvent avoir des rendus différents comme dans les exemples sur cette page: < http://www.webdevout.net/articles/beware-of-x... >. Alors ma question c'est pourquoi continuer avec HTML ? Les développeurs web ne sont-ils pas capable de produire du code avec une syntaxe un peu plus exigeante ?

@Changaco : A mon avis ils n'ont pas envie de bouleverser les habitudes de milliers de développeurs. Sans parler du fait que beaucoup de particuliers font leur site eux-mêmes, et ils savent à peine ce qu'est une syntaxe.

@Skoua : si on ne changeait jamais les habitudes on ne progresserait pas, c'est clairement pas une bonne raison pour moi.

@Changaco : Ce n'est peut-être pas une bonne raison mais c'est une réalité. Je suis d'accord avec toi que si la syntaxe était aussi stricte que n'importe quel language de programmation, cela éviterait bien des choses mais je ne sais pas dans quelle mesure les gars du W3C font la part entre la "masse" et les développeurs qui respectent les standards.

@Changaco : petite réponse en quatre pionts à la question «pourquoi faire du HTML plutôt que du (vrai) XHTML?»:

1. Parce que si tu n'intègres pas un contenu dans un autre langage XML alors tu n'as pas besoin d'une transcription en XML de HTML. Autant utiliser HTML, qui correspond alors bien au besoin.

2. Parce que si le contenu que tu produits (pages web) n'est pas destiné entre autres à des agents utilisateurs nécessitant du XML, alors tu n'as pas besoin d'une transcription en XML de HTML.

3. Parce qu’Internet Explorer ne supporte pas le vrai XHTML. Servir du application/xhtml+xml à certains navigateurs, et du text/html à d'autres, alors qu'on n'a pas spécifiquement besoin d'un langage XML (voir points 1 et 2 ci-dessus), n'est une solution intéressante que si l'on a du temps à perdre pour rien.

4. Parce que les navigateurs web qui supportent application/xhtml+xml afficheront un yellow screen of death (ou équivalent) pour tout code XML mal formé. Et quiconque a déjà livré un CMS à un client, à un rédacteur non expert en XML, ou parfois à lui-même, sait que le risque de code mal formé est extrêmement élevé. Pourquoi diable se passer des largesses des parseurs HTML, quand on n'a pas strictement besoin d'un langage XML (cf. points 1 et 2, à nouveau)?

CQFD?

@Florent V. :

1 → rester bloqué à HTML c'est empêcher la sémantisation du web car un seul format ne peut pas être adapté à toutes les situations tandis que XML qui est plutôt un méta-langage est extensible à beaucoup plus de situations.

2 → Utiliser du HTML dans un programme/script externe à un navigateur est compliqué tandis que parser un XML est possible dans un grand nombre de langages, le plus important ce n'est pas à qui est destiné un contenu c'est qui y a accès et comme en général tout le monde a accès à une page web on se doit de produire quelque chose le plus accessible possible, l'accessibilité c'est un concept qui t'es cher il me semble …

3 → Je me fous totalement d'IE et ça m'énerve quand on parle du présent/passé dans une réflexion sur le futur.

4 → L'excuse habituelle de la rigueur de la syntaxe XML, le yellow screen n'a aucune raison d'être et peut tout à fait être rendu user-friendly et les CMS il faut mieux les coder. Le CMS sait exactement ce qui va être envoyé au client puisque c'est lui qui le gère, il peut tout à fait détecter les erreurs pendant l'édition au lieu de les laisser arriver jusqu'au client …

"on se doit de produire quelque chose le plus accessible possible"
+ "Je me fous totalement d'IE"

=> euh, c'est moi ou... ? Ah oui, ça doit être moi.
Bref, IE est un navigateur comme d'autres et être accessible c'est aussi l'être pour les utilisateurs (volontaires ou forcés) d'IE.
Sinon le message d'accessibilité n'a strictement aucun sens.

J'ai toujours pensé que XHTML2 était un peu bizarre / inutilement compliqué, donc c'est une bonne nouvelle.

Une petite remarque en passant :
[quote]
HTML5 est *déjà* implémenté dans pas mal de navigateurs.[/quote]
Ca par contre, c'est faux, hors considérations IE. Les nouveautés de HTML5 ne se limitent pas à <audio>, <video> et <canvas>. Rien n'est encore fait du côté des améliorations prévues pour les formulaires, et c'est un élément clé au moins aussi important que les trois précédents, sinon plus, dans un web qui s'oriente de plus en plus vers une logique applicative où les formulaires ont une place essentielle. Il y aurait beaucoup à dire sur ce sujet, mais je vais m'arrêter là pour le moment.

A propos du débat XHTML/XML vs HTML, question peut-être idiote, mais je pose quand même : En supposant qu'on parte de zéro pour créer un nouveau site, qu'est-ce que ça vous coûte en plus de produire un code XHTML offrant potentiellement plus de possibilités de réutilisation, autant du côté des humains que du côté des machines, plutôt qu'un code HTML qui ne pourra s'afficher que dans un navigateur et pas grand chose de plus ?
Vu la tournure polyvalente que prend gentiment la techno web, ne vaudrait-il pas mieux voir un peu plus large ?
Qui peut le plus peut le moins, il me semble. IL y a autant de CMS et/ou framework travaillant en XHTML qu'en HTML, donc le problème ne doit pas être là.

Par contre pour ce qui est de reprendre de l'existant, c'est une autre paire de manches, effectivement, et là je conviens aisément qu'on puisse se poser la question si c'est vraiment nécessaire/intéressant de passer de HTML à XHTML.

@Raphael : il s'agit de deux paragraphes différents, je parlais d'accessibilité pour les programmeurs pas pour les utilisateurs. De plus ma réflexion se situe sur le long terme et pas sur le présent comme je l'ai dit.

bonjour,

a lire sur ce(s) sujet(s) cet excellent article (traduction d'une interview de Steven Pemberton)

Ps : petit "bug" dans la traduction "C’est la raison pour laquelle je pense qu’envoyer du XHTML en text/html."
Texte original : "That is why I believe it is perfectly acceptable to send XHTML to a browser using the media type text/html."

Chacun se fera sa propre opinion bien entendu ...

laurent
++

Salut,

Je débute vraiment, je termine le cour sur le xHTML (du SdZ). ^_^
Ma question est peut être vraiment inutile...

Ayant passé devant du PHP, j'ai déjà vu qu'il pouvait contenir du HTML. Que va t'il en devenir ?

@ +