Note à moi-même

Je me demande bien si le petit PluXml est à la hauteur de mon projet...

Benjamin — Wed, 01 Feb 2012 13:47:00 +0100

i Source photo : Idee... par Alessandro Pinna

À chaque étude de projet je me pose la question, je n'y suis pas obligé mais bon, j'ai un petit attachement pour ce système de gestion de contenu, allez savoir pourquoi. Peut-être parce-qu'il est beaucoup plus surprenant que tu ne pourrais l'imaginer.

Je suis souvent confrontés aux articles qui honorent PluXml, mais pas trop, de peur que nous le transformions en usine à gaz sûrement...

Dans un sens je trouve ça dommage, j'ai donc voulu écrire cet article afin de continuer dans la lancée de Dis tonton, c'est quoi PluXml ?

Moi je veux un blog, ça passe ?

Pour sûr, les capacités du CMS sont tout à fait capables de vous permettre de bloguer, seul ou à plusieurs avec des niveaux différents si vous souhaitez garder pour vous seul le contrôle total de votre administration, gérer vos plugins simplement ou encore modifier votre thème depuis l'administration.

C'est nouveau ? Non, pas vraiment, mais au lieu de parler tout le temps du stockage ( non fiable pour tous ceux venant de wordpress ) via XML, essaie donc de tester toutes les fonctionnalités et les capacités de charges, j'entend par là les limites à ne pas dépasser.

Oui faut pas déconner, tu ne peux pas vraiment envisager PluXml pour un blog comme celui de Korben par exemple, les temps de chargements te le feront ressentir, mais pour un blog de type classique, comme le tien par exemple, peux très largement être réalisé avec PluXml et si tu ne me crois pas avec ces quelques mots, sache que tu disposes d'un plugin concocté par Stéphane pour que tu puisses charger ( sans efforts ) ton site de test en articles et commentaires, cela te permet de juger avec comme autre preuve que "J'ai lu chez machin qu'avec 100 articles ça passe pas".

PluXml se limite t-il à un blog ?

Non, j'aurai pu limiter ce paragraphe à cela mais bon, j'ai envie de râler donc...
NON, ce n'est pas JUSTE un moteur de blog, tu as vu ça où ? Bien sur quand nous le présentons c'est sous cette forme, et c'est là que nous ne sommes pas malin. En effet, tu disposes désormais de plusieurs méthodes afin de modifier PluXml pour qu'il ressemble ( dans sa structure ) au projet de tes rêves ( enfin presque hein ).

Via des plugins : Méthode qui ne nécessite pas d'explication je pense, c'est relativement simple à prendre en main.

Via les pages statiques : Facilement gérables depuis l'administration, elle peuvent vous permettre de réaliser très simplement des pages avec divers sorte de contenu puisqu'elles acceptent le PHP et le JavaScript, c'est pas mal pour les dev en herbe.

Via les pages statiques : Merde il radote, et bien non, tu peux attribuer une structure différente à chaque page statique, regarde bien les options lors de la rédaction. Tu peux donc avoir bon nombre de pages différentes avec un contenu totalement différent à compter du moment où tu aimes mettre les mains dans le cambouis, pour les dev un peu plus expérimentés on va dire.

Tu es soucieux des performances au plus haut point ? Sache aussi que PluXml intègre une méthode appelée templateCss, couplée avec le système de template il te permet de charger une feuille de style personnalisée pour chaque page statique, cela peux s'avérer utile si tu as beaucoup de CSS. Exemple; tu crées une page statique-folio.php dans ton dossier thème, tu peux lui attribuer une feuille statique-folio.css, ainsi tu n'est pas obligé de charger tout ton css dans une seule page si tu disposes d'un site assez important, pas mal non ?

De même avec les mobiles, aujourd'hui beaucoup utilisent les medias-queries, c'est vraiment sympa et cela peux permettre de réaliser une version mobile en moins d'une heure, c'est Raphaël qui l'a dit !, je peux le prouver, j'étais à son atelier lors du barcamp Bordeaux 2011 et je dois avouer que c'est assez impressionnant.

Mais comme il le précise, certains site nécessite une version mobile à part afin de ne pas faire n'importe quoi avec le chargement des fichiers, ainsi PluXml dispose d'un plugin permettant la détection d'un appareil mobile et dans ce cas l'affichage d'un thème différent que vous pouvez modifier avec les mêmes outils que pour la version web, c'est pas du bonheur ça ?

Et c'est tout ?

C'est pas mal non ? Tu imagines ce que l'on peux faire avec un CMS qui ne sais sois-disant faire que du blog correctement, et encore, je ne te donne pas toutes les astuces, mais sache que tu peux faire beaucoup plus qu'un simple blog, ne l'oublie pas, il paraît que ça peux être utile !

Et si tu ne trouves chaussure à ton pied dans la galerie de thèmes ( c'est un des points noir nous le savons ) n'oublie pas que le forum est là, si l'équipe n'a pas toujours le temps, il y a peut-être un bénévole qui acceptera de t'aider, ils ne mordent pas, enfin pas à ma connaissance.

Ressources

Demain c'est bien, mais demain c'est loin

Benjamin — Tue, 01 Nov 2011 21:46:00 +0100

i Source photo : Route 66, west of Seligman par vambo25

C'est ce que je me dis en général quand je fais ma veille ( je parle du titre tu l'auras bien compris ), je suis curieux et fasciné par ce que seront les avancées de demain avec les nouvelles technologies, mais ce que je constate, c'est que personne ne pense réellement à aujourd'hui, enfin si, mais trop peu.

Où sommes-nous partis ? Que visons-nous ? C'est la question que je me pose bien souvent. Ce billet ne sera pas vraiment "méchant" dans sa critique mais assez étayé ( de mon point de vue ) pour que vous puissiez voir pourquoi je ne suis pas content ( encore une fois ).

Sommes-nous avides de nouveautés ?

Moi je vois plus un manque à combler, pendant de longues années, CSS3 s'est limité à du border-radius pour la plupart des gens, c'est en tout cas l'exemple qui revenait à coup sur, de même avec xHTML 2 et HTML5, il y avait une ébauche pourtant bien réelle mais personne, ou peu, ne se tentait à utiliser ce qui était encore des brouillons. Mais attends là, ce n'est toujours pas finalisé ? Ah bah oui tiens, mais pourquoi se ruer dessus alors ? Parce-que nous avons faim, c'est en tout cas mon point de vue .

J'ai tort, penses-tu ? C'est probable, mais je vais étayer ma critique, ne t'inquiète pas. Explique moi, si ce n'est pas de la bêtise, pourquoi nous utilisons des modules CSS3 encore non finalisés pour les navigateurs récents et une "dégradation gracieuse" via divers méthodes pour nos anciens combattants ? Ce qui passait sur les anciens navigateurs passe encore à l'heure d'aujourd'hui sur les plus récents, alors pourquoi faire une masse de travail en plus en voulant remplacer quelques détails imagés ou Javascript par des dizaines de lignes de CSS3 préfixées car sinon tous les navigateurs ne les comprendront pas.

On en est là, que tu le dénigre ou non, on se surcharge de travail pour mettre en avant les nouvelles technologies. A quoi servirait modernizr ( par exemple ) sinon ? C'est normal sérieux d'utiliser du javascript afin de pouvoir bidouiller du CSS3 pour au final remplacer une image ? Moi je pense que non.

Faire la part des choses ?

Peut-on réellement faire la part des choses en restant dans une vraie logique ? Je te vois venir de loin là; "Oui mais toi t'es toi un con ( si tu l'as pensé ! ), pourquoi tu utilises HTML5 et CSS3 sur ton site alors ?"

Mais dans un sens tu as raison, mais regarde bien, ai-je perdu du temps en faisant ce choix ? Non car j'ai choisi de ne pas faire de dégradation dite gracieuse. Pourquoi ? Parce-que je m'en branle ( bah voilà, à faire comme ça forcément ! ). Mais je peux me permettre de faire ce choix, ce site ne compte que peu de visites, ce n'est pas l'objectif principal. Je choisi donc de faire le choix de mettre en avant un espace de test, un atelier en ligne si tu préfères et de ce fait, je n'ai que peu d'intérêt à passer du temps à adapter ce site pour Internet Explorer 6.

Mais si j'utilise les technologies de demain, pourquoi de critique? Parce-qu'il faut faire la part des choses ! Je ne comprend pas pourquoi les gens passent un temps fou à vouloir faire des sites utilisant du CSS3 pour les navigateurs récents et une dégradation pour I.E ( faut l'avouer c'est lui ... ), c'est faire du travail pour ... pas grand chose, désolé, on bouffe du temps, ah si, on est cité sur quelques blogs influents, et ça c'est cool.

Des clients ayant besoin d'une rétro-compatibilité poussant jusqu'à I.E 6, ont certainement des contraintes, et ces derniers ( dans la majorité des cas ) se contrefoutent que vous puissiez économiser une image de coin arrondi parce-que CSS3 peux le faire tout seul comme un grand. Il veux un espace en production fiable et stable le plus rapidement possible.

Est-ce pour autant qu'il faut laisser de côté ces nouveautés ?

Non, je n'ai jamais dit ça, mais comment allons-nous nous en sortir pour la maintenance des feuilles par exemple, à chaque sortie d'une version d'un ou l'autre navigateur, il faudra vérifier à virer les préfixes prioritaires histoire d'avoir un code propre ? Ah non, je suis con, on peux utiliser du Javascript sinon ! Non je ne critique pas complètement le dernier jouer de Lea Verou, mais pas sur un projet en production, des tests oui.

Nous avons tant à faire avec les technologies disponibles aujourd'hui, pourquoi toujours voir demain ? C'est important en effet, mais ne faut-il pas garder les pieds sur terre ? Où sommes-nous partis ? Tu te souviens, j'ai posé la question plus haut, on est partis sur la lune selon moi, on sais que l'on peux le faire mais si c'est pour alourdir la charge de travail, je trouve ça bien dommage. Demain on pourra utiliser toutes ces technologies sans se soucier, demain ...

Allez, à toi de critiquer !

Dis tonton, c'est quoi PluXml ?

Benjamin — Tue, 27 Sep 2011 22:04:00 +0200

i Source photo : Question par Oberazzi

Je ne sais pas si tu le sais, mais j'aime bien PluXml, et de ce fait, je vais te le présenter aujourd'hui. Je profite de la sortie de PluXml 5.1.3 pour écrire enfin ce billet qui me trotte dans la tête depuis un petit moment maintenant. Nous allons faire le tour de ce qu'est capable PluXml à l'heure d'aujourd'hui, un CMS si petit soit-il, pourrait surprendre bien des gens.

Je ne vais pas parler que de la légèreté de PluXml, ce serait (presque) trop facile, je vais tenter de vous prouver que les "gros" CMS qui existent aujourd'hui ne sont , malheureusement, pas toujours utilisés dans de bonnes conditions. Je ferai tout cela le plus concrètement possible afin de ne pas être tenté de donner mon avis personnel trop souvent dans cet article, puisque forcément, je ne suis pas neutre !

Présentation de la petite bête

Le titre de ce billet n'est pas là par hasard, en effet, mon petit neveu ma demandé il y a quelques temps en voyant mon adresse email : " Dis tonton, c'est quoi plu-ixé-melle ? ", je n'ai pu m'empêcher de rire, puis face à l'air dubitatif de mon frère, je me suis lancé dans des explications sans fin.

PluXml est un système de gestion de contenu ayant pour but de vous faciliter la tâche dans la création de votre site web. Il n'est pas tout à fait comme les plus connus tels que Wordpress ou Drupal se différenciant par son système de stockage des données via XML et non SQL. Cela lui permet d'offrir une portabilité et une facilité d'installation enfantine.

Du fait qu'il soit différent, PluXml n'est pas destiné à tout projet, loin de là, mais est néanmoins une solution, de mon point de vue, idéale pour des blogs ou sites vitrines par exemple. Vouloir l'utiliser pour une boutique de e-commerce ou un projet de 100 pages est loin d'être la solution ultime. A chacun son terrain comme on dit ! Malheureusement, PluXml est souvent laissé de côté suite à des critiques remontant parfois à plusieurs années, bref, je ne critique pas, mais je pense que le tester est une bonne solution pour, qui sais, changer d'avis.

Une prise en main simple et rapide

Ce que j'aime le plus dans PluXml est certainement la simplicité avec laquelle quiconque avec un minimum de connaissances : upload sur un serveur, peut utiliser en moins de 30 secondes l'outil, en effet l'installation se déroule en une seule et unique étape ( voir ci-dessous ), vous accédez ensuite directement à votre site, sans plus de conneries inutiles à remplir.

i Phase d'installation de PluXml

Voilà vous avez désormais accès à votre site, le point noir à cette étape de votre progression est sans aucun doute le fait que l'administration est dépourvue de certaines options, en effet, pour le néophyte, ne pas avoir d'éditeur de texte de base peut-être un gros frein, malgré le fait que plusieurs plugins sont désormais disponibles et très faciles à mettre en place, c'est déroutant. La partie administration a été récemment revue afin d'être ( beaucoup ) plus intuitive, il est désormais relativement simple, après un état des lieux de trouver les différents outils mis à votre disposition pour vous aider a éditer les pages de votre site.

Pour celui ayant un petit vécu avec d'autres CMS la prise en main est, encore une fois de mon point de vue, à la portée de tous.

Une méthode pour l'affiche et la modification simplifiée

Pour beaucoup de personnes, le choix d'un outil se fait sur une liste de critères ( logique non ? ), celui dont je vais vous parler est essentiel pour beaucoup d'intégrateurs : la méthode disponible pour l'affiche / personnalisation des éléments dans une page. PluXml dispose donc d'une méthode nommée plxShow, cette dernière permet d'appeler des éléments dans votre structure de manière relativement simple ( voir ci-dessous ).

Ceci est un exemple parmi tant d'autres vous permettant d'automatiser l'entrée des données via votre administration. La liste complète des méthodes disponibles à l'heure actuelle est dans la documentation du développeur. Je ne vais pas pousser ce sujet trop loin, le but étant de ne pas s'endormir sur une partie avant la fin de l'article.

Depuis la version 5.0 du projet, il est désormais possible d'utiliser des extensions ou plugins : ceux-ci sont là pour vous éviter de mettre les mains dans le cambouis et ainsi facilitent encore la tâche aux personnes découvrant ce genre d'outils, actuellement seuls quelques plugins sont disponibles mais arrivent de plus en plus nombreux et forts utiles pour prouver que PluXml ce n'est pas JUSTE un moteur de blog, il devient désormais aisé de réaliser son portfolio par exemple ( tiens, ça donne une idée d'atelier / article ça ).

Le mot de la fin

PluXml est encore un jeune CMS, néanmoins je ne décampe pas du fait qu'utiliser Joomla ou Wordpress pour une vcard est juste ridicule, bon ok, utiliser un CMS pour une vcard est limite, mais il faut penser que tout le monde ne connais pas forcement HTML, CSS, PHP ou Javascript, donc bon. Je pense que le projet a encore de l'avenir contrairement à ce que pensent les gens face à l'évolution des plus grands, comme je l'ai dit plus haut, chacun à sa place !

T'es pas content ? Dit-le moi ( sans m'insulter si possible ). Allez à bientôt !

Note à moi-même se paye un lifting : nettoyage de structure, peinture fraîche et ajouts divers

Benjamin — Thu, 15 Sep 2011 00:24:00 +0200

i Source photo : HTML basic structure by sedmikrasky84

J'ai bien fais le ménage, enfin j'espère du coup, car parti d'un coup de plumeau, c'est un gros coup de peinture que j'ai entamé, puis une démolition complète avant de tout recommencer. De quoi je parle ? Du journal tiens fiston !

Oui oui je sais, on dirait le même qu'avant, mais non, la structure xHTML a été complètement refondue afin d'être plus logique et plus propre surtout, j'ai mis une bonne surcouche de CSS3, mais pas vulgaire de mon point de vue, il faut simplement utiliser un navigateur récent car je ne me suis pas cassé la tête avec la rétro-compatibilité ( mais alors pas du tout ) juste un peu avec les préfixes prioritaires mais vraiment le strict minimum ( histoire de ne pas enfonce que Internet Explorer ).

Est-ce que cela était vraiment nécessaire ? Je pense que oui, nous allons faire le tour des nouveautés et le pourquoi du comment de ce qui m'a poussé à le faire.

Une structure et une peinture qu'ils sont plus propres

Ah si si, j'ai bien fait attention à faire ça du mieux que possible, j'imagine que cela n'est pas parfait, néanmoins elle a été faite, puis refaite, puis rerefaite, enfin bon, j'y ai passé un peu de temps quand même.

Si tu y regarde de plus près, je n'ai pas révolutionné ce qui existe déjà, c'est du HTML5, propre à mon goût. Le plus chiant dans cette histoire a certainement été de bien contrôler mes travaux par rapport aux normes en vigueur à l'heure actuelle.

Est-ce que le code est parfait aux yeux du validateur ? Je ne vais pas te mentir, je n'ai pas vérifié, utilisant des technologies encore en phase de développement et essayant de les exploiter un peu, je laisse donc de côté notre cher outil de validation pour ce petit projet.

De même pour ce qui est de la partie CSS, il faut bien avouer qu'envisager l'utilisation de CSS3 avec quelques préfixes prioritaires et vouloir valider son code serait tout simplement complètement con comme idée. J'ai donc choisi d'être mon propre validateur ! J'ai vérifié ce site avec les dernières versions stables à l'heure d'aujourd'hui des navigateurs les plus utilisés :

Firefox 6
Internet Explorer 9
Chrome 14
Opera 11.51
Safari 5

C'est pour moi la façon la plus simple de savoir si mon site est valide, il passe partout, en règle générale je ne fonctionne pas comme ça mais bon, disons que cela m'arrange bien pour une fois.

Quelques ajouts à PluXml

Une mise à jour du bébé s'imposait et dans la foulée une bonne reprise de certains plugins qui me laissaient une source qui n'était pas des plus propres.

Une bonne mise au point niveau sécurité : j'ai demandé conseil à un de mes following sur twitter qui ma dit qu'Akismet était une solution vraiment fiable, voilà donc qui est fait, un plugin pour PluXml devrait être bientôt à ta disposition, ne t'inquiète pas. J'espère que cela sera en mesure de contrer les gentil robot spameur qui m'ont bien pourris il y a peu.

J'utilise toujours le plugin mis à disposition par Stéphane pour la coloration syntaxique, aussi vieux soit-il ( le plugin hein ), il est toujours très simple d'utilisation et fonctionne très bien pour ma part.

J'ai ajouté quelques informations à la suite de l'article, un bloc de présentation de l'auteur ainsi qu'une liste de suggestion de lecture, j'ai modifié quelque-peu l'apparence du formulaire d'ajout de commentaire et pis c'est tout !

N'oublie pas jeune ( ou vieux ) internaute, la critique est toujours la chose la plus importante pour moi.

Nota : je fais toujours autant de fautes, ne t'inquiètes pas c'est normal.

Des liens d'évitements ( presque ) bien pensés

Benjamin — Mon, 29 Aug 2011 21:42:00 +0200

i Source photo : Clavier de l’Oliver 6 par zigazou76

En cette fin de soirée, je viens te parler d'accessibilité, enfin un petit peu, car il faut bien avouer que dans le domaine je ne suis pas très connaisseur, il n'empêche que j'aime critiquer, en bien comme en mal et nous allons avoir les deux aspects ce soir !

As-tu déjà entendu parler des liens d'évitement ? Ils sont aussi appelés liens de navigation interne; ils ont pour objectif de vous permettre par la simple utilisation de la touche tabulation de vous déplacer vers un emplacement sur la page en cours et sont censés, dans la logique des choses, être placés au tout début de votre structure afin de les appeler en premier.

C'est suite à la découverte du compte Twitter a11yWin que j'ai visité un site : European Accessibility Forum Frankfurt. Entrons donc dans le vif du sujet !

Des liens foutrement bien pensés

Non mais si, si tu regardes un poil plus haut, j'ai bel et bien annoncé que la critique serais aussi positive. Bref ( copyright canal+ ), je vous invite donc à aller sur le dit site cité au-dessus et de naviguer à la tabulation, il faut dire ce qui est, c'est quand même une idée de génie : les liens sont là pour aider les gens, autant faire en sorte de voir la zone vers laquelle ce dernier peut nous emmener, je ne me suis pas amusé à faire le test sur beaucoup de navigateur ( un seul : Firefox 9.0a1 ) mais je pense que ça passe partout, avoue c'est quand même une idée qu'elle est bien bonne hein !

Dans la même lignée, je t'invite à visiter ( si ce n'est pas déjà fait ) le site Alsacréations et, encore une fois, de naviguer à coup de tabulation, au premier appui, tout le menu apparaît, pas bête, certains trouve cette liste de liens "disgracieuse", voilà donc la bonne idée.

N'ayant pas pris le temps de fouiner la toile pour trouver d'autres exemples je vais me contenter de ces derniers, mais cela est suffisant pour construire ma critique je pense.

L'envers du décor

La première question qui me viens à l'esprit : Pourquoi les gens éprouvent le besoin de "cacher" ces liens pourtant si utiles, il ne faut que peu pour les faire apparaître, mais la première impression quand on arrive est qu'il n'y en a pas, je trouve ça tout simplement bête. Ce n'est que mon avis et cela importe peu finalement.

La seconde remarque risque de faire "jazzer" quelque-uns, mais bon, ça me pèse : Pourquoi que j'ai trouvé du javascript pour l'effet d'affichage souhaité dans les DEUX sites ? Oui oui je sais, même en désactivant javascript, les liens d'évitement fonctionnent quand même, mais c'est contradictoire de mettre en place des effets pour aider les gens si ce derniers ne sont pas en mesure de pouvoir les voir, non ? Je te vois venir au galop, oui javascript est activé partout aujourd'hui, mais bon, c'est une critique, il faut bien que j'argumente.

Le mot ( positif ) de la fin

Je tiens à préciser que lors de la rédaction de ce billet, j'ai eu une longue hésitation quand au fait de le publier, mais je tiens aussi à préciser que je n'attaque pas personnellement ces deux sites, je suis même admiratif face au code, aux auteurs respectifs et au contenu. Simplement je tenais à exprimer mon sentiment quand à l'utilisation de certaines méthodes dans des cas précis.

Si tu te sens d'humeur critique, surtout, n'hésite pas, ça fait du bien !

Je m'excuse aussi quand aux fautes qu'il m'arrive de faire, merci.

Fait divers : Un intégrateur HTML décède suite à une overdose de
, l'enquête est ouverte !

Benjamin — Sun, 21 Aug 2011 19:33:00 +0200

i Source photo : El Super Endive par Angélique Kerval

Non parce-que bon, faut pas exagérer, je veux bien que le web évolue, que l'on utilise de nouvelles technologies pour nos sites, mais n'est-on pas rendus dans l'excès ? Je vous le demande !

Ce triste constat je l'ai fait il y a 2 ( ans ? ) jours environ, voilà que je me paye un peu de lecture, je tombe sur un générateur de formes utilisant quelques règles CSS3 assez sympatoches vois-tu, je me dis, allez, je teste, ça à l'air assez sympa. Et là, bim, j'ai pris une ( grosse ) claque dans la tronche.

Je me suis alors penché sur le dossier et ai décidé de mener ma propre enquête, qui est le coupable du meurtre ? Viens je vais t'expliquer.

Le suspect idéal : CSS

Oui parce-qu'avec CSS, on est obligé de mettre une cascade de <div> si on veut obtenir le résultat souhaité, tout le monde fait comme ça, si il y avait d'autres solutions ça se saurait quand même, bah oui enfin.

Si tu savais à quel point je suis las d'entendre ce genre de conneries, explique moi comment un mec peut ( en utilisant un peu de logique ) utiliser ça : Ribbon-generator par CSS3D.net, fais un test, et regarde. Mais vous allez où les gars là ? C'est ça le futur avec CSS3 ? Pauvre guignol ! Je ne vois que ça à te dire ( enfin pas toi spécialement, tu comprends ). Nous allons quand même examiner notre "beau" ruban :

Et une salade d'en<div>es pour la 12, UNE ! Mais là ou je me poile le plus, c'est en voyant la CSS ( je ne met pas tout, trop long ) :

Du CSS comme on l'aime fait par des gens bien hein, bah faut savoir que CSS3 aujourd'hui c'est bien, mais c'est chiant à écrire ces règles super trop longues, donc on trouve un générateur et pis ça fait tout tout seul, comme ça on est pas fatigué, on utilise un gros de m***e mais ça ne nous a pas pris beaucoup de temps, donc ça va. ( voir ci-dessous pourquoi )

Et si c'était un empoisonnement dû à ?

Suis-je bête, j'aurais dû y penser que le coupable des <div> était en fait Internet Explorer, suis-je bête ! Ah on me susurre à l'oreille que le rendu est bel et bien "moyen" sous IE, mais, mais, je ne comprends pas, je ne comprends plus.

On met des <div> pour ne pas utiliser :before et :after parce-que ça ne passe pas sous Internet Explorer, bon jusque-là c'est ridicule, mais continuons, pourquoi utiliser les préfixes propriétaires CSS3 sans même mettre ensuite la règle sans préfixes ? Mais pire encore, pourquoi laisser ne pas donner sa chance au petit e bleu alors ?

Je te vois venir de loin, je ne défend pas toujours ce dernier, mais bon, arrêtons les dégâts, c'est uniquement de la mauvaise volonté là, tu le sais ?

Mais alors, si ce n'est ni le vénérable maître CSS, ni le résistant E bleu, alors, qui est donc l'auteur du meurtre ??

C'est toi, c'est moi, c'est nous, car si tu relis bien ce que j'ai écris ci-dessus, tu noteras que ce sont des ressources que l'on trouves sur le web sans chercher bien longtemps. Moi ça m'attriste de voir à quel point le web est sale ( je ne parle pas de sites pour adultes mais bien des sources ). Tu veux que je te le prouve par A+B avec un exemple flagrant ? Allez !

Parce-que soi-disant il est obligatoire pour IE d'avoir un conteneur pour pouvoir centrer du contenu, il faudrait m'expliquer pourquoi avec IEtester je n'ai aucun souci avec ce morceau de code ? ( je pense que certains vont réagir à cela, merci d'être explicite si j'ai fait une ( des ) erreur ).

Tout cela pour dire, une <div> ce n'est rien c'est vrai, mais partant de ce point là, on fini par faire des rubans comme des cochons avec une bonne salade bien grasse et une feuille de style plus qu'incomplète ...

A bientôt ! Et n'oublie pas de critiquer surtout, c'est le plus important.

Quand text-align positionne ( aussi ) des ... blocs !

Benjamin — Mon, 27 Jun 2011 18:49:00 +0200

i Source photo : Did you say text-ure ? par Frel

Aujourd'hui nous allons voir, enfin revoir une propriété très connue : text-align. En effet, beaucoup d'entre vous connaisse cette propriété pour simplement aligner le contenu en ligne d'un bloc et finalement faisant très bien son travail, il est difficile d'écrire un article entier là dessus penses-tu, je vais te prouver le contraire.

Suite à une lecture récente d'un article sur Smashing Magazine: The Future Of CSS: Experimental CSS Properties, je suis tombé sur le cul en découvrant que la propriété text-align pouvait aussi bien aligner des éléments de type block aussi bien que des éléments de type inline.

Les différentes valeurs

Comme j'expliquais plus haut, nous connaissons tous ( enfin j'espère ) les valeurs dites classiques permettant d'aligner du texte dans un bloc :

Puis lorsque nous désirons centrer un élément, nous utilisons dans la majorité des cas des marges auto lorsque l'élément dispose d'une largeur définie :

Ce qui ma laissé sur le cul c'est de voir que les moteurs de rendu Gecko et Webkit intègre des valeurs surprenantes permettant d'aligner ( le terme positionnement dans le titre n'est pas tout à fait juste ) le bloc conteneur avec text-align de la manière suivante :

A noter: Il est possible d'utiliser les valeurs left et right aussi. Ces dernières valeurs permettent donc d'aligner les éléments en ligne ainsi que le bloc conteneur. Vous pouvez néanmoins aligner un bloc au centre mais son texte à droite par exemple comme ceci :

LA question que je me pose est : A quoi cela sert-il ? Je n'ai pas fait beaucoup d'expérimentations, mais j'ai du mal à voir l’intérêt de la bête ... Si vous avez une idée lumineuse permettant d'utiliser ces valeurs de manière logique, je ne parle pas de bidouille qui peuvent être réalisés simplement avec du css2 ! Je vous en serais fort reconnaissant !

Sources photos et articles:

Pourquoi je n'aime pas HTML 5

al.jes — Thu, 23 Jun 2011 21:09:00 +0200

Cet article a été écrit par al.jes et a été conjointement publié sur son blog.
Copyleft: cet article est libre, vous pouvez le copier, le diffuser et le modifier selon les termes de la Licence Art Libre

C'était il y a bientôt huit ans – un dimanche matin d'octobre 2003 – que j'ai fait ma première rencontre avec HTML. Je venais de pousser la porte d'une association ayant vocation de partager le goût des sciences pour participer à une activité de création de sites web.
Quelques années plus tard, j'ai appris que j'utilisais la quatrième version du langage HTML et qu'il en existait une évolution nommée xHTML (x pour extensible). Avec xHTML 1.0, puis 1.1, j'ai appris de nouveaux concepts comme la séparation du contenu et de la présentation, la sémantique d'un code ; j'ai appris un nouveau langage (CSS, pour la présentation) ; ma syntaxe est devenue plus rigoureuse et j'ai désappris de nombreuses mauvaises pratiques, même si je ne comprenais pas toujours pourquoi c'en était (fort heureusement, j'ai eu l'occasion d'y repenser, et de comprendre mon erreur).

Quelques années ont encore passé, et j'ai découvert que le W3C – World Wide Web Consortium, l'organisme qui gère (x)HTML et quelques autres standards en vigueur sur le web – préparait HTML 5, originellement un projet de différents éditeurs de navigateurs web, et xHTML 2, plus tard abandonné au profit du premier. Je ne m'y suis pas intéressé tout de suite, ces deux évolutions possibles n'étant ni finalisées ni implémentées dans la plupart des navigateurs, a fortiori dans les navigateurs les plus utilisés. Mais cela fait un an ou deux que la donne a changé : les navigateurs mettent fortement en avant HTML 5, présenté comme le futur du web. J'ai alors été un temps très enthousiaste, HTML 5 laissant de superbes perspectives pour l'avenir…
Pourtant, HTML 5 me hérisse le poil. Pourquoi ?

HTML ?

Tout d'abord, HTML signifie « hypertext markup language » soit, dans la merveilleuse langue de Rabelais, « langage hypertexte à balisage » ; chaque mot a son importance :

« langage » : c'est un langage informatique, avec sa syntaxe, son vocabulaire, sa logique…
« à balisage » : c'est un langage dont la syntaxe fait appel au concept de balise, c'est à dire (d'après cette chère Wikipédia) « un caractère, ou une série de caractères, utilisé pour la structuration d'un document et qui sera invisible par le lecteur final »
« hypertexte » : ce langage traite d'hypertexte, c'est à dire qu'il s'occupe de texte et de liens.

« Qu'il s'occupe de texte et de liens »… Tiens, tiens, certaines des grosses nouveautés d'HTML 5 ne serait-elle pas la gestion de l'audio et de la vidéo, des formulaires plus poussés ? Ça ne serait pas hors sujet par hasard ? Je vous entends déjà…

Ouais, mais c'est cool, parce que du coup on a tout en un !

Ouais, mais non. Paf !

Bon, d'accord, c'est pas très argumenté comme réponse, alors voici : quand on définit un objectif, il serait bon de s'y tenir. C'est pour cette raison que l'on a pris l'habitude de distinguer le contenu de la présentation, limitant xHTML à la structuration d'un texte accompagné de liens (et, on y reviendra, de quelques autres choses ayant une valeur sémantique) et faisant appel au CSS, un autre langage, pour gérer l'affichage plus ou moins esthétique de notre contenu. En quelque sorte, ce que je demande ici, c'est de reprendre cette habitude unixienne de l'application qui ne fait qu'une chose mais qui la fait bien. Les informaticiens appellent cela le principe KISS (pour « keep it stupid simple », « garde ça stupidement simple »).

Ouais, mais on va pas non plus apprendre trouze mille langages différents !

Oui et non…
De un, on apprend déjà plusieurs langages, voyez plutôt : (x)HTML pour le contenu, CSS pour la présentation, PHP pour les automatismes côté serveur, MySQL pour la gestion de bases de données, JavaScript pour les automatismes côté navigateur, etc.. Ça ne nous dérange pourtant pas tant que ça… Certes, c'est un peu plus compliqué au début, parce qu'il faut apprendre, mais ça ne nous empêche pas de trouver au final que ce nouveau langage est bien plus adapté à l'usage que l'on en a qu'un fourre-tout infâme, non ?
De deux, xHTML (1.0, 1.1 et 2) est un dialecte XML, c'est-à-dire un langage ayant son vocabulaire propre mais utilisant la syntaxe XML, et il y a des dialectes XML pour à peu près tout. Donc si l'apprentissage d'une nouvelle syntaxe vous fait peur, pas d'inquiétude, il suffit de prendre un autre dialecte XML ! et si c'est le nouveau vocabulaire qui vous fait peur, alors l'ajout de vocabulaire au sein du même langage aura exactement le même effet… De trois, XML, qui veut dire « extensible markup language » (« langage de balisage extensible »), permet parfaitement d'utiliser plusieurs de ses dialectes au sein d'un même document, ce qui nous laisse un potentiel infini, donc bien plus grand que d'avoir un nombre de possibilité finies au sein du même « dialecte »…

Ouais, mais, de toute façon, (x)HTML ne se limitait déjà pas à l'hypertexte !

En effet, mais ça veut pas dire que c'est une bonne chose, non ? D'ailleurs, si on en est à utiliser ce genre d'arguments, ça fait tout de même un moment que le W3C cherche à « épurer » (x)HTML, non ? Je veux dire, xHTML 1.0 a viré tout ce qui s'occupait de la présentation, xHTML 1.1 a viré les « frames », xHTML 2 virait les formulaires… Pour sûr, xHTML 2 n'était pas parfait sur ce point non plus, mais il y avait un progrès notable.

Mais alors… Que faire ?

xHTML 2 me semble être un bon point de départ, notamment pour l'universalisation de l'attribut href (tout peut être lien) et la création de l'attribut universel role (tout est sémantique). Ensuite, on peut enlever la balise <img> au profit de <object>, voire supprimer ces deux éléments au profit d'un dialecte XML spécialisé dans l'intégration de fichiers (qui pourrait alors aller plus loin que la balise <object>…). On peut également supprimer l'élément <a>, qui ne sert plus à rien (tout peut être ancre grâce à l'attribut universel id et tout peut être lien comme dit ci-avant). Pour finir, on peut supprimer les éléments <h1>, <h2>, <h3>, etc. au profit de la nouvelle structure proposée par xHTML 2, structure qui fonctionne par imbrication de <h> et de<section> (n'utiliser qu'une seule structure me paraît plus simple, et cette nouvelle structure d'une part ne se limite pas à six niveaux de titre et d'autre part est clairement structurelle (alors que l'on pouvait penser en terme de présentation avec l'ancienne structure)).

XML ?

HTML 5 n'est pas, on l'a vu, un dialecte XML. Cependant il existe x/HTML 5, qui se veut être une implémentation XML de HTML 5. Ah, on est sauvés alors ! Eh bien allons-y, commençons notre code comme tout document XML qui se respecte : par la déclaration XML.

Cette ligne de code veut tout simplement dire la prase suivante :

Hé, toi, l'agent utilisateur ! Oui, toi ! Ce document, là, tu vas me l'interpréter selon la syntaxe XML, dans sa version 1.0. Et tant que j'y suis, le texte est en Unicode (UTF-8).

À noter que dans votre cas, l'agent utilisateur sera certainement votre navigateur…

Voilà, on rajoute un peu de x/HTML 5, pour obtenir le code suivant :

On envoie le tout à Unicorn, le service de validation du W3C, pour vérification. Pour info, le W3C a créé XML, donc on peut supposer qu'un code XML correctement rédigé devrait passer. Il y a quelques mois ça ne passait pas, mais d'une part Unicorn était en test (avant, le W3C utilisait d'autres services similaires) et d'autre part les travaux sur HTML 5 (qui n'est, je le rappelle, toujours pas finalisé) étaient moins avancés. Le test est concluant puisque Unicorn nous dit ça :

This Page Is Valid HTML5!

Traduction : « T'es un bon garçon, ton code est correct ».

Maintenant, le W3C étant un organisme indépendant et pour diverses raisons concernant le doctype (voir partie suivante), nous pouvons douter que notre navigateur lira correctement ce code. Comme je suis un garçon retors, on ne va pas se contenter d'afficher ça sous différents navigateurs : on va plutôt faire appel à un autre service de validation. Mais pas n'importe lequel : validator.nu, le service de validation du WHAT Working Group (un groupe de ~~pression~~ travail fondé et soutenu par différents éditeurs de navigateurs ou acteurs du « cloud computing » (expression barbare qu'il convient de traduire par « tu donnes toutes tes données, on les revend à des publicitaires, des entreprises douteuses et des états à tendance dictatoriale (surtout si vous y habitez), et tu dis adieu à ta vie privée »), c'est l'initiateur de HTML 5). Là, le test nous donne ceci :

Error: Saw <?. Probable cause: Attempt to use an XML processing instruction in HTML. (XML processing instructions are not supported in HTML.)

Traduction : « Toi, t'as confondu x/HTML 5 avec un dialecte XML. Faudrait pas trop en demander mon garçon ! »

Warning: Comments seen before doctype. Internet Explorer will go into the quirks mode.

Ah. Je savais pas que le rôle d'un service de validation était de nous demander de garder nos mauvaises pratiques pour encourager les navigateurs indignes de ce nom dans leurs erreurs… Je prends note.

Error: When the attribute xml:lang in no namespace is specified, the element must also have the attribute lang present with the same value.

Je confirme, ne pas confondre x/HTML 5 avec un dialecte XML, c'est juste de la poudre aux yeux pour faire croire qu'on écoute un peu le W3C. Note à moi-même : le W3C est mort, WHAT Working Group l'a remplacé.

Là, la solution est très simple : utiliser un vrai dialecte XML, ou ne pas prétendre faire du XML. Un peu d'honnêteté, quoi… Dans mon cas, ça sera très simple : je ne veux pas (plus) utiliser HTML 5.

Doctype ?

Quand je codais encore en HTML 4, je n'utilisais pas de doctype. Ça marchait tout aussi bien (vu que le non respect des standard était à l'époque la norme sur les navigateurs) et j'avais pas à me prendre la tête. Quand je suis passé au xHTML, je trouvais que c'était compliqué, mais c'était nécessaire d'avoir un doctype, et le bon. Donc je copiais-collais le doctype que me conseillais le service de validation xHTML du W3C. Pour info, un doctype en xHTML, ça ressemble à ça :

Puis est arrivé HTML 5 et son doctype simplifié, qui ressemble à ça :

Sur le coup, j'étais super content : enfin un doctype que je pouvais retenir ! Et puis je me suis demandé à quoi servait le doctype, et pourquoi il était si compliqué… Et quand je suis tombé sur le doctype du xHTML 2, ressemblant fortement à ceux des xHTML 1.0 puis 1.1, j'ai décidé de le décortiquer.

Nous avons donc :

!DOCTYPE, qui indique que l'on déclare un type de document.
html, qui est le nom du type de document. Ça peut être n'importe quoi, c'est surtout une information pour le cas où l'on utiliserait plusieurs types de documents (je vous avais déjà dis qu'en XML on peut utiliser plusieurs dialectes au sein d'un même document ; il sera alors de bon ton de déclarer autant de types de documents que de dialecte employé).
PUBLIC, qui indique que le fichier décrivant le type de document sera sur un serveur web distant. S'il était sur le même serveur, on devrait entrer SYSTEM à la place.
Une série d'indications entre guillemets anglais doubles :
- un identifiant officiel (ici, le tiret nous signale qu'il n'y en a pas),
- le propriétaire du fichier (ici le W3C),
- le nom exact du fichier (ici « DTD XHTML 2.0 »),
- la langue du fichier (à distinguer de la langue de votre document : ici le type de document est en anglais, mais ça n'empêche pas votre document d'être en français !).
Et enfin l'URL du document.

À savoir, les déclarations de type de document (DTD) ont été créées pour SGML, l'ancêtre de XML. Un autre outil a été développé pour XML : les schémas XML, plus complexes, mais plus puissants. En revanche, pour en appeler un, il suffit d'employer un espace de nom au sein de l'élément racine du document, comme ceci :

J'ai mis ici une balise d'ouverture de l'élément racine de xHTML 2, avec un espace de nom (xmlns) principal renvoyant vers le schéma XML du xHTML et un espace de nom secondaire que j'ai nommé « xsi » et renvoyant vers le schéma XML de XMLSchema-instance. L'utilité de ce dernier est de préciser exactement l'emplacement du schéma XML, puisque xHTML 2 n'étant pas finalisé son schéma n'est pas celui par défaut pour xHTML. J'ai donc précisé l'emplacement du schéma grâce à l'attribut schemaLocation placé dans l'espace de nom « xsi », puis j'ai spécifié la langue de mon document (l'espace de nom « xml » est implicite et existe dans tout document XML, il n'y a donc pas besoin de le déclarer).

Les schémas XML peuvent aussi bien être une alternative à la DTD qu'en être complémentaire, cela dépendra du dialecte employé.
Petit détail pour les plus curieux, une DTD utilisera une syntaxe spécifique aux DTD, alors qu'un schéma XML est… un dialecte XML !

Mais en HTML 5, point de schéma. On en trouve un tout petit en x/HTML 5, mais qui ne fait qu'adapter deux trois détails pour la syntaxe XML (oui, je suis de mauvaise foi, et j'assume). Donc le tout est dans le doctype.

Ah oui, mais t'avais pas dit que le doctype de HTML 5 il ressemblait à ça ?

Gagné ! On a strictement aucune information sur l'emplacement de la DTD, absolument rien, si ce n'est son nom !

Petit rappel historique maintenant : si la dernière décennie a vu le respect des standards se généraliser sur le web (essentiellement grâce à la rigueur de la syntaxe XML et aux efforts de la fondation Mozilla), ça n'était pas le cas des années 90, qui ont connu ce qu'on a appelé par la suite la « guerre des navigateurs ». Et cette guerre n'avait rien d'épique : les éditeurs de navigateurs, visant clairement le monopole, se battaient à coup d'éléments non standards spécifiques à leurs navigateurs. Les plus anciens se souviendront sans doute de cette balise que je n'ose nommer qui fait clignoter du texte (bon goût s'abstenir, mais il faut croire qu'en cette décennie-là bien peu étaient ceux à avoir du goût… si vous voyez certains des sites que j'ai développé à l'époque !), spécifique à IE… Mais il y en avait d'autres, des balises spécifiques à Netscape, à Mosaic, à IE… Et tout ça était rendu possible par l'absence de DTD unique dont l'emplacement est clairement spécifié.

Vous voyez un peu l'idée ? On n'a plus d'appel à une DTD, juste un doctype fantoche… Vous voulez revenir à l'époque des balises spécifiques ? À l'époque où l'on code des sites accessibles pour 100% des visiteurs potentiels, vous voulez vous retrouver avec des sites faits exprès pour tel navigateur couvrant 50% de vos visiteurs potentiels tout au plus (ne pas se fier aux parts de marchés, qui ne prennent en compte que les navigateurs « ordinaires », et non les navigateurs spécifiques à tel ou tel handicap) ? Personnellement, mon choix est fait, et c'est clairement non.

Et j'entends déjà ceux qui me dirons qu'on a pas forcément besoin qu'un site soit accessible à tous, à quoi je répondrai que si : il n'y a pas de raison pour qu'un handicapé, en plus de son handicap, doive subir que l'on ne l'ignorât. Et ce sont souvent les premiers oubliés quand on ne pense pas un code en terme d'accessibilité.

Pour finir sur ce point, l'absence de DTD unique pose déjà problème : les services de validation ont pour rôle de dire si l'on respecte ou non les spécifications du langage ou dialecte employé. Pour ce faire, ils s'appuient sur les DTD et les schémas XML. Quand ces derniers sont absents, ils se doivent de faire de la rétro-ingénieurie. Le résultat est donc forcément imparfait. C'est pour cela que dans la partie précédente on ne s'était pas contentés d'un seul service de validation pour vérifier la conformité du code.

Avenir ?

Nous venons donc de voir que HTML 5, présenté comme l'avenir du web, revient sur de très nombreuses avancées, comme la simplification du langage, XML et son énorme potentiel, la mise en conformité avec une DTD unique permettant de simplifier le travail des développeurs, etc..
D'ailleurs, si l'on revient sur ce dernier point, la simplification du code aurait permis un accès pour tous à la programmation, ce qui consisterait tout de même à une révolution au moins aussi majeure que la popularisation de l'accès à Internet, qui donnait à tous la possibilité de publier ! Je pense donc sincèrement que les professionnels du « cloud computing » et les éditeurs de navigateurs ont sauté sur l'occasion pour pérenniser leur statut d'experts, un peu comme Microsoft, qui il n'y a pas si longtemps traitait le Logiciel Libre de « cancer »… Après tout, il ne faut pas oublier que le code est leur gagne-pain, et s'ils ne sont pas forcément malhonnêtes, loin de là, ils ne voient pas forcément d'un bon œil que M. Tout-le-monde puisse se mettre à coder.

Mais revenons-en à notre propos : HTML 5 revenant sur de nombreuses avancées. HTML 5 revient également sur un point cher à de très nombreux développeurs : le concept de séparation entre le contenu et la présentation. Ce concept, à première vue un peu abstrait, est en fait très simple : lorsque l'on rédige une page on se concentre sur le sens de ce que l'on code, sans se préoccuper de l'apparence que notre contenu aura. Cela permet entre autre de pouvoir modifier l'apparence sans modifier le contenu, d'avoir plusieurs contenus avec la même présentation (sans la re-coder intégralement) ou, lorsque l'on veut modifier l'apparence de plusieurs contenus ayant la même apparence, de ne la modifier qu'une fois et pas autant de fois que le nombre de contenus. En bref, c'est extrêmement pratique.

Comment revenir sur ce point, après tout les gens peuvent continuer d'utiliser CSS pour leur présentation ?

Eh bien c'est assez insidieux : on reprend les éléments de HTML 4 conçus pour la présentation (et qui avaient disparus avec xHTML 1.0), et on les présente sous un nouveau jour, en leur prétendant une valeur sémantique.

Je vais ici prendre l'exemple de l'un de ces éléments, <i>, mais l'idée est la même pour <b>, <small> ou encore <font> (oui, <font> !).

En HTML 4, un texte placé entre <i> et </i> était affiché en italique. En HTML 5, voici ce que le W3C nous dit :

The i element now represents a span of text in an alternate voice or mood, or otherwise offset from the normal prose in a manner indicating a different quality of text, such as a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, or a ship name in Western texts.

Ce que xhtml.com traduit par :

L'élément i sert à identifier du texte que l'on peut prononcer d'une voix ou d'un ton différent, ou du texte qui est de quelque façon que ce soit distinct du texte ordinaire, tels une désignation taxonomique, un terme technique, une expression idiomatique tirée d'une autre langue, une pensée, le nom d'un navire, ou du texte dont la présentation typographique est composée de lettres italiques.

Analysons maintenant.

« du texte que l'on peut prononcer d'une voix ou d'un ton différent »… Hum, ne serait-ce pas là la façon usuelle de montrer l'emphase quand on parle ? Ah, ben si… Bon, alors l'élément <em> signalant l'emphase devrait suffire…
« du texte qui est de quelque façon que ce soit distinct du texte ordinaire »… En bref, c'est un texte dont l'usage nécessite l'emphase : <em>. Et les exemples employés (que je ne vais pas re-citer un par un, il ne faut pas exagérer) ne font que confirmer l'emphase et non l'italique.

Ce sont donc certes un ensemble de choses que l'on aurait tendance à écrire en italique, mais l'italique n'est pas obligatoire, c'est seulement une façon comme une autre d'exprimer l'emphase. Merci de ne pas confondre sens et présentation habituelle de tel ou tel sens.

Mais, mais… Pourquoi revenir sur ce concept, alors qu'il semblait si pratique ?

Eh bien c'est un mystère… Je ne m'explique vraiment pas ça, d'autant plus que la séparation entre contenu et présentation peut sembler à première vue compliquée, et donc rebuter, et donc renforcer le statut d'experts des auteurs de ce langage…
L'explication officielle c'est de permettre la rétro-compatibilité avec HTML 4, mais d'une part la rétro-compatibilité ne serait réelle que si les définitions des éléments étaient inchangées, ça n'est pas le cas, et d'autre part c'est aux agents utilisateurs, et non aux spécifications elles-même, d'assurer la rétro-compatibilité, par exemple en interprétant plusieurs spécifications.

W3C ?

Il y a encore deux ou trois ans, le W3C travaillait sur xHTML 2, contre l'avis des éditeurs de navigateurs qui trouvaient le changement trop grand. Des critiques ont également été formulées à l'encontre du processus de développement de xHTML 2 qui était, et j'approuve, bien trop fermé. Seulement, là où le changement m'enthousiasmait (voire me semblait insuffisant) et où une ouverture du processus de développement m'aurait suffit, Apple Inc., la fondation Mozilla et Opera Software ASA. ont préféré créer un groupe de travail informel (le WHAT Working Group n'a pas d'existence juridique) et développer une nouvelle technologie complètement timorée et rétrograde. Chacun sa méthode.

Par la suite, le W3C a cédé aux pressions du WHAT Working Group – ou plutôt de ses membres (je rappelle et insiste : ce groupe n'a pas d'existence juridique) – et a créé un groupe de travail interne pour participer au développement de HTML 5. Puis le W3C a cessé le développement de xHTML 2. Un regroupement d'éditeurs de navigateurs – vite rejoint par d'autres éditeurs de navigateurs et par des acteurs du « cloud computing » – venait de court-circuiter le vénérable W3C.

Une idée a commencé à germer en moi il y a quelques mois. Il existe un autre groupe, informel, sans existence juridique, qui a de l'importance sur Internet. Ce dernier ne se contente pas du web, mais l'englobe. Ce dernier est entre autres responsable de protocoles allant de IP (pour internet protocol, c'est ce qui permet d'identifier une machine connectée à Internet) à XMPP (pour extensible messaging and presence protocol, un protocole permettant entre autres de faire de la messagerie instantanée, de gérer un micro-blog…) en passant par oAuth (un protocole permettant une connexion sécurisée à tel ou tel service). Bref, ce dernier pourrait parfaitement prendre en charge ce qui ne va plus chez le W3C. Ce dernier, c'est l'IETF. Cependant, ça n'aura aucun impact si je suis seul à leur réclamer l'ouverture d'un groupe de travail pour développer xHTML 2 (et je n'ai ni le temps ni les compétences pour développer moi-même la spécification et un agent utilisateur l'interprétant…).
Du coup, je sens que ça va rester à l'état de vœu pieu…

En attendant, je peux toujours continuer à utiliser xHTML 1.1, et je ne m'en priverai pas.

Pour aller plus loin…

Vous pouvez trouver mes sources ainsi que quelques ressources supplémentaires dans la liste qui suit :

les spécifications de xHTML 1.0, 1.1 et 2, de HTML 5 et les différences entre HTML 4 et 5 sur le site du W3C ;
les articles de Wikipédia sur xHTML et HTML 5, sur le WHAT Working Group, le W3C et l'IETF, et aussi sur le principe KISS ;
le cours de XML de la Wikiversité ;
les services de validation Unicorn et validator.nu ;
« X/HTML 5 Versus XHTML 2 », un article sur xhtml.com ;
l'article « Les égyptiens ont civilisés l’alphabet » et l'extraordinaire conférence qu'il rediffuse ;
les sites du W3C, du WHAT Working Group et de l'IETF.

Voilà ! J'en profite pour remercier Ti-Pierre de m'avoir proposé d'écrire cet article, ainsi que Poupi et Dhoko qui m'ont inspirés – grâce aux débats que j'ai déjà eu avec eux sur le sujet.