Forum d'entraide PHPFrance

Bonjour à tous,

suite à quelques lectures : http://www.w3.org/TR/xhtml2/
et http://www.w3.org/TR/css3-roadmap/ (principalement)
je me demandais si quelqu'un savait où nous en sommes au juste.

En gros, que répondre à la double question : "Je veux développer un site en xhtml2+css3, à partir de quand il y aura des validateurs ? Car pour l'instant le validateur c'est moi... Et où en sont les différents navigateurs par rapport à ces deux langages ?"

Donc en gros, tout se résume à "À partir de quand je commence à développer entièrement en xhtml2 et css3 ?"

D'après les docs c'est pas très précis, mais j'ai lu, et je ne sais malheureusement plus où, que ça serait peut être début 2011 (xhtml 2 ou css3 je sais plus lequel).

Voilà, vos réponses m'intéressent beaucoup !

Hey ,

Tu tentes d'ouvrir la boîte de Pandore là … Bon, on va essayer d'être succinct et au maximum précis.

Déjà, il faut connaître les différence entre HTML et XHTML [0], donc il faut bien comprendre ce qu'est XML et ce qu'est HTML. Je ne ferai pas l'historique ici, ce serait trop long. On va juste considérer HTML 5, ce sera suffisant.

On va vite traiter le cas CSS 3. Comme tu peux le voir au W3C [1], il y a des modules qui sont terminés (Recommandation ou Candidate Recommendation), en passe de l'être (Proposed Recommendation ou Last Call) ou en chantier (Working Draft).
Il faut comprendre que la norme 3 de CSS apporte énormément de choses par rapport aux normes précédentes (comme la 2 ou la 2.1). On voit qu'on a des priorités pour valider les différents modules et qu'elles sont respectées, i.e. les priorités les plus hautes sont traitées en urgence.
Par contre, ce n'est pas parce qu'une recommandation n'est pas encore terminée (ou en passe de l'être), qu'elle n'est pas dores et déjà intégrée dans les navigateurs. Par exemples, les modules sur les transitions [2] et les animations [3] sont encore à l'état de brouillon, mais Webkit y travaille depuis plusieurs mois et on a des résultats très impressionnants.
Il faut bien comprendre que la plupart des membres des groupes de travail sont employés chez les différents navigateurs (Mozilla, Apple, Microsoft, Opera etc.) ou travaillent dans d'autres entreprises, ou simplement individuels. Mais on trouve beaucoup de développeurs Mozilla, Apple et Opera. Pourquoi ? C'est très simple. Déjà, ils sont très bien placés pour écrire les standards car ce sont des gens de « terrains » (dans le bon sens du terme), et ils sont bien placés pour faire des implémentations et qualifier leurs intégrations (faisable ou pas ?). Par exemple, Opera travaille souvent comme ça, il développe un module, et disent : « Vous voyez, ça marche, on l'a fait », et donc les autres disent : « Ah ok, très bien, sauf que gna gna et gna ». On évolue comme ça. Bien sûr, ce n'est pas systématique, mais je grossis le trait pour que tu comprennes.
Donc pour CSS 3, les modules principaux sont déjà intégrés. Par contre, c'est souvent à l'état de propriétés propres aux navigateurs (i.e. préfixées par -moz, -webkit etc.) ; mais on pourra chercher dans les documentations l'évolution précises des choses [4] [5] etc.

Le cas HTML 5 … hmm, c'est plus compliqué. Il faut voir qu'avec cette paire HTML/CSS précède un lot d'autres nouveaux standards : SVG a bien le vent en poupe, ARIA marche à grand pas, MWI (Mobile Web Iniative) a de plus en plus d'importance, RFD (et RDFa) même histoire, SMIL redevient intéressant etc. On a aussi des technologies qui fusionnent, à l'instar de XForms 2.0 qui passe dans HTML 5 (même si les spécifications vont rester dissociées un moment) [6] etc.
Donc ce n'est pas juste l'histoire de l'HTML 5, c'est tout un mouvement qu'il ne faut pas déséquilibrer.
En ce qui concerne l'HTML 5, il y a de très grosses nouveautés très intéressantes (comme la balise <video> ou <audio> qui sont bien à la mode). On trouvera une petite vidéo de notre cher Hixie [7]. Bien sûr, les navigateurs s'efforcent d'implémenter ces nouveautés tant attendues par la communauté de développeurs Web. Gecko en supporte une bonne partie, Webkit aussi et Presto bien sûr. Trident est toujours en retard, mais il fait des efforts. Ah oui, j'ai oublié de préciser qu'il faut oublier CSS 3 dans IE 8+ … Microsoft supporte seulement (et enfin !) la spécification 2.1, c'est déjà pas mal.
L'écriture de la spécification HTML 5 prend du temps car elle est loin d'être simple. Le plus gros est déjà fait et je pense qu'on attaque la fin. 2011 … moui, ou pas. C'est très difficile de donner une date de fin. Mais certaines balises sont déjà décrites de manière très précise et ça ne changera pas. C'est pourquoi la plupart des moteurs de rendu (layout engine ou LE) implémente déjà une partie de l'HTML 5. Ce que ça implique, c'est qu'il ne faut pas attendre la validation totale de la spécification pour commencer à utiliser l'HTML 5. Même Trident en supporte une partie, c'est dire .

SVG est trop cool aussi. Ça fait un moment que ça existe, mais il est de plus en plus riche et on commence à faire des choses intéressantes, surtout en le couplant avec Javascript.

Pareil pour ARIA. Le Javascript devient plus puissant, mais aussi plus accessible.

Bref, les nouveaux standards sont orientés dynamisme.


Alors pour l'utilisation … Personnellement, je vais commencer à coder en HTML 5 (d'ailleurs, je le fais déjà pour des petits sites). Pourquoi ? Parce que la plupart des navigateurs en supporte une partie, donc t'en qu'on reste dans de l'« HTML 4.01 optimisé », ça sera très bien compris, pas de soucis. Si on veut s'attaquer aux vidéos, audios, canvas etc., j'attendrais encore un peu, genre 6 à 8 mois, voir comment les choses évolues du côté de IE 8 (car c'est toujours le E-blue qui dicte les tendances).
Si on veut intégrer du CSS 3, … bon. Qu'est-ce qui pourrait être gênant ? Les nouvelles propriétés de layout (comprendre de positionnement, comme les flux de position, les colonnes etc.) peuvent être très gênantes car visuellement importante. En effet, si on a un site sur 3 colonnes, et que l'utilisateur n'a qu'1 seule colonne, c'est vexant. Par contre, si on utilise les propriétés de texte (comme les effets d'ombre) ou d'animation, c'est plus du gadget.
Il faut donc réfléchir de cette façon : qu'est-ce qui est vitale pour l'utilisateur ? Une page Web avec un bon positionnement. On peut parler de version amoindrie, c'est le minimum. Ensuite, les nouveaux standards déjà implémentés peuvent servir à enjoliver la page. Donc deux cas : pour un utilisateur à jour, ce sera super, tout beau, tout neuf, et pour un utilisateur un chouilla en retard, ce sera comme avant, aucune différence, donc ça ne peut pas lui faire de mal.

Pour l'instant, il ne faut pas utiliser entièrement de l'HTML 5 (quoi que) ou du CSS 3 car ils ne sont pas supportés entièrement. Mais HTML 4.01 CSS 2.1 ne l'est pas non plus (si si, il reste toujours des petits détails …). On peut commencer à l'instaurer pour effectuer la transition.
Voilà, on va conclure là-dessus : il y a quelque mois, on n'était en train de lire les brouillons, maintenant c'est la transition car on a des bases solides sur lesquelles s'appuyer, c'est à dire que les bêta des navigateurs supportent déjà une bonne partie des parties fixes des spécifications (et c'est déjà important). J'espère que d'ici 1 an, la majorité (90 %) de l'HTML 5 sera supporté, mais je peux rêver. Mais franchement, les grosses nouveautés sont : vidéo, audio, formulaire, canvas, web worker. Pour les sections imbriquées, les balises de sorties, de métrique etc., c'est moins important pour le quotidien (même si elles ont une importance hein) et c'est d'ailleurs une priorité d'implémentation plus faible !

Donc : nous vivons une période de transitions, à nous de nous intéresser aux standards et de commencer l'utilisation de l'HTML 5 tout doucement.

Est-ce que j'ai répondu à ta question ?


[0] http://www.whatwg.org/specs/web-apps/cu ... l-vs-xhtml
[1] http://www.w3.org/Style/CSS/current-work
[2] http://www.w3.org/Style/CSS/current-work#transition
[3] http://www.w3.org/Style/CSS/current-work#animation
[4] https://developer.mozilla.org/en/CSS
[5] http://webkit.org/projects/css/index.html
[6] http://www.whatwg.org/specs/web-apps/cu ... and-xforms
[7] http://www.whatwg.org/demos/2008-sept/

j'ai tout lu!

Il reste juste une chose qui me faire très peur en fait, tu parles toujours d'HTML5 mais jamais d'XHTML2, pourquoi ?

Je ne parle pas de l'XHTML car je ne connais pas trop son avancement. Je fais seulement parti du groupe de travail sur l'HTML 5 au W3C, et pas celui de l'XHTML 2. Mais il existe de grosses différences entre les deux langages (même s'ils évoluent ensemble).

Déjà, l'XHTML est réellement de l'XML, à la différence d'HTML (du à son passé). Le document est servi comme une application application/xhtml+xml, il est donc traité comme un document XML. Certaines balises (comme <noscript />) n'existent pas en XHTML. On ne peut pas étendre l'HTML, alors qu'on peut étendre l'XHTML, via les espaces de noms par exemple. Enfin bref, on trouve toute la puissance d'XML dans l'XHTML, ce qu'il n'est pas possible dans l'HTML.

Donc je n'en parle pas car les différences sont subtiles d'un point de vue strict (on prend tout l'HTML et on compare avec XHTML, et pas avec XML) et que les développements vont de paires (ou pas, car XForm est plus balèze dans XHTML par exemple). Je ne tiens pas au courant pour XHTML, désolé .

Oki, pas de quoi être désolé, tes informations m'ont très bien renseigné, merci.
J'avoue développer beaucoup plus en xhtml, c'est pour ça que je voulais savoir où en était xhtml2. C'est vrai que certaines balises d'html5 sont prometteuses . Mais je ne développe pas trop html :d.

Pour la version courante, c'est vrai que je préfère XHTML 1.1 à HTML 4.01, mais attention, je pense me remettre à l'HTML 5 car amplement suffisant. Un exemple, est-ce que tu utilises XLink par exemple ? Non, dans 99,9% des cas, un simple lien est suffisant. Autre exemple, est-ce que tu utilises XForms ? Non, car les formulaires de l'HTML 5 seront suffisant (bon, c'est une partie de XForms en réalité :-p). Est-ce que tu utilises XPointer, XQuery etc. Non et encore non (je parle bien d'un cadre Web « normal »). Donc ça ne sert à rien d'utiliser XHTML 2 dans ce cas, autant retourner sur le bon vieux HTML 5 . Non ?

Avant, j'utilise l'XHTML 1.1 car l'HTML 4.01 avait encore des restes de SGML qui me répugnaient :-p. Ceci dit, XHTML n'est pas encore du XML pure dans sa syntaxe. Typiquement, on peut avoir des balises d'ouvertures avec auto-fermeture : i. <br /> et non pas ii. <br></br>. En XHTML/HTML, on aurait i., alors qu'en XML, ce serait forcément ii.

Pour le XHTML 2, en comparaison avec le HTML 5, on peut trouver quelques éléments de réponse là : xhtml.com/fr/future/x-html-5-versus-xhtml-2/, sans oublier le brouillon de la spécification XHTML 2 du W3C.

Il faut souligner que la future version majeure du XHTML ne fait pas l'unanimité : beaucoup de développeurs Web ont critiqué la spécification XHTML 2, estimant qu'elle ne pourra pas être implémentée telle quelle ; autrement dit, ces critiques reprochent, d'une certaine façon, à ses rédacteurs de travailler dans une espèce de tour d'ivoire sans avoir eu à développer eux-mêmes un site Web.

Quant à la validation d'un document en XHTML 2 par un outil de validation automatique, pour autant que je sache, ce n'est pas possible à l'heure actuelle, contrairement au HTML 5 (et encore, pour ce dernier, c'est au moyen d'une version bêta du validateur du W3C si l'on utilise le service de validation de ce dernier).

Vraiment très intéressant le premier lien.

Je pense que tout dépend du type de site qu'on veut faire.
Par exemple, mon site expose plutôt des éléments de type document, des tutoriels par exemple, donc je préfère vraiment xhtml2, et pas seulement pour sa structure, je pense aussi que le fait que ça soit du xml simplifie énormément les choses pour l'interaction avec php et ça, ça me plaît beaucoup.
Àprès, forcément, pour un site ou la présentation a plus d'importance, au niveau design, c'est sur que la balise vidéo de l'html5 à l'air vraiment très intéressante.

Hmm, explique moi ce dont tu as besoin de l'XHTML que tu ne trouves pas dans l'HTML à l'heure actuelle (on parle des versions 2 et 5 hein).

Et pour le validateur, j'avais oublié d'en parler, mais Henri Sivonen développe un validateur (Simon Pieters et Mozilla l'ont rejoint je crois, à vérifier) : http://validator.nu. Un exemple de tout ce qu'il valide avec les services API.

Je partage complètement le point de vue selon lequel XHTML est définitivement mieux qu'HTML tout simplement parce que c'est du XML.

HTML5 me semble simplement fait pour ceux qui n'arrivent pas à bien supporter du XML.

Le projet de conversion de formulaires XForms en pages XHTML+Javascript que je développe ne peut exister que parce que le XHTML existe et que XSLT est maintenant bien implémenté sur les navigateurs.

L'utilisation de XSLT, de Javascript ou de Flash pour ne pas avoir à attendre que les navigateurs suivent telles ou telles recommandations me parait être une ouverture importante pour les valider.

Attention, il n'y a pas de mieux ou de moins bien ; c'est juste que les deux langages ne répondent pas tout à fait aux même besoins.

On voulait au départ structurer des documents, donc on a fait SGML. Bon, tout le monde sait que c'était un peu une catastrophe car la notation n'était pas toujours respectée (mais tolérée). Enfin bref, c'était le début. Après, on a eu HTML qui est venu le remplacer. Déjà plus standard, moins de bizarreries, mais c'était pas encore ça. Ensuite, on a fait XML en parallèle, basé sur le principe de l'HTML, mais en ajoutant beaucoup de possibilité (les espaces de noms par exemple). Au passage (une petite parenthèse), on s'est rendu compte que les DTD n'étaient pas assez fines pour valider un document et on est passé à XSD. Suite à XML, on sait dit que ce serait bien de profiter de sa puissance mais avec de l'HTML. On a donc fait l'XHTML qui est un moyen terme. On prend un peu d'XML, un peu d'HTML et hop. Donc pour moi, c'est une sorte de langage un peu bâtard en fait, et j'aurais bien voulu le voir mourir pour sa version 2 ; autrement dit, qu'il n'y ait pas de version 2 !
Soit on fait de l'HTML — avec les petits soucis qu'il a mais aussi les avantages —, soit on fait de l'XML, mais pas un peu des deux. On ne sait qu'est-ce qui fonctionne ou pas, et surtout on ne sait pas pourquoi.

Si on fait de l'XML, on se rend compte que c'est très puissant. Il suffit de regarder XPath, XPointer (qui est basé sur XPath), XQuery (pareil), XLink qui permet de pousser le système de lien très loin, XSLT (génial) etc.

Maintenant (peut-être que je me trompe) mais voici mon impression. Au début de l'HTML, il n'y avait pas vraiment de CSS. Donc les balises avaient un rendu par défaut fait par les navigateurs. Par exemple : b était systématiquement en gras. Ensuite, CSS est apparu et on s'est dit qu'il fallait qu'HTML ne répresente que la structure du document, et point barre. Donc on a écrit la balise strong pour bien faire la différence, montrer qu'il y avait une étape de franchie. Les navigateurs font encore une mise en page par défaut, mais il est possible de la modifier via CSS (ce qui n'était théoriquement pas prévue dans les anciennes versions d'HTML — 2, 3 … —). Mais à quoi sert l'HTML alors ? Quelle est la différence avec XML ? On veut quitter tout doucement HTML pour aller vers XML, bah alors, pourquoi on ne s'arrête pas tout d'un coup …
On adopterait du XML, donc on a toute sa puissance. Ensuite, on impose une XSD pour le nom des balises, et le tour est joué. On aurait bien de l'XHTML (si on pourrait l'appeler comme ça), en tant que document XML avec une structure HTML comme on la connaît, c'est à dire avec le même sens pour les balises. De cette façon, on pourrait se brancher avec ARIA, SVG etc.
Pour moi, l'HTML 5 va dans ce sens (mais pas assez vite). L'X/HTML 5 ou XHTML 2 sont un peu du vent … en tout cas, un des deux langages au moins (j'aimerais les deux) doit mourir.

On aurait bien de l'XHTML (si on pourrait l'appeler comme ça), en tant que document XML avec une structure HTML comme on la connaît, c'est à dire avec le même sens pour les balises.

C'est justement ce que j'attends, après, dire que l'Xhtml2 c'est nul, c'est pas forcément vrai car justement ça va dans ce sens. Et puis présenter une page comme un document, je trouve pas ça bête.
À mon avis, x/html5 et xhtml2 ont tous deux leur avenir, l'un en tant que langage html et xml et l'autre xml seulement, mais plus orienté mise en page de document. Je pense sincérement que pour écrire de la documentation xhtml2 est idéal pour tout le reste il y a eurocard... qu'est-ce que je dis... x/html5.

On voulait au départ structurer des documents, donc on a fait SGML. Bon, tout le monde sait que c'était un peu une catastrophe car la notation n'était pas toujours respectée (mais tolérée). Enfin bref, c'était le début. Après, on a eu HTML qui est venu le remplacer. Déjà plus standard, moins de bizarreries, mais c'était pas encore ça. Ensuite, on a fait XML en parallèle, basé sur le principe de l'HTML, mais en ajoutant beaucoup de possibilité (les espaces de noms par exemple).

Le SGML est un méta-langage, c'est-à-dire un ensemble de règles générales (une sorte de grammaire théorique, si l'on veut) que doit respecter tout langage qui s'en réclame (auquel cas le langage en question est une sorte de grammaire appliquée). Le HTML est un langage qui se réclame du SGML (même si le HTML 5 prend des distances vis-à-vis de ce dernier), de même que le XML, qui est lui-même un méta-langage, dont se réclament beaucoup de langages et de formats (XHTML, les schémas XML, MathML, SVG, XSLT, RDF, les différents formats RSS, Atom, DocBook, les différents formats constituant l'ODF, et j'en passe…).

Je n'ai pas compris ta définition d'un méta-langage. Attention, un langage n'est pas forcément un langage de programmation. On trouve des langages structurels, comme le XML justement.
Pour moi, la définition d'un méta-langage est un langage qui se définit par lui-même, ce qui pourrait être le cas de XML à cause des XSD, mais bon … est-ce que c'est ce que tu voulais dire ?

Pour moi, la définition d'un méta-langage est un langage qui se définit par lui-même, ce qui pourrait être le cas de XML à cause des XSD, mais bon … est-ce que c'est ce que tu voulais dire ?

On peut dire que oui.