Je voudrais réagir à la news qu'à poster Eris Daspet concernant son choix de l'HTML 4.0 au lieu de l'XHTML 1.0 (ou 1.1).
Il accuse - et de bon droit - les webmasters d'être atteints de versionite aigüe, et de toujours pousser les versions en utilisant les derniers outils existants sans réellement se soucier de leur réelle utilité.
À ceci, je répondrais deux choses fort simples, les deux raisons me poussant à faire de l'XHTML 1.1 sur ces pages :
La versionnite est un syndrome très répandu parmis les codeurs, et parfois, ce n'est pas si mal. Comment les outils pourraient-ils évoluer s'ils n'étaient pas utilisés dans des projets réels.
Je pense que peu de personnes me contrediront lorsque je dis qu'un outil ne peut atteindre une pleine maturité qu'après avoir « essuyé quelques plâtres ».
On voit d'ailleurs ce phénomène se reproduire dans le monde des cartes graphiques. Les programmeurs utilisent de plus en plus les derniers effets, et les fabricants mettent au point des cartes capables de les reproduire de manière plus rapide... Et la boucle est bouclée !
Au final, l'utilisateur s'en trouve un peu perdu, mais dispose d'outils performants et ayant prouvé leur validité.
L'XHTML est un format de fichier structuré contrairement à l'HTML. Me trouvant hébergé sur un serveur ne disposant pas de base de données, j'ai vite renoncé à mettre en place un stockage des mes news.
C'est à ce moment que Darken m'a fait la remarque tout à fait pertinente :
Mais ton site, c'est de l'XHTML ? C'est donc déjà une base de données !
.Et oui, pas besoin de base de données, le fait de respecter les règles de sémantiques dans mon fichier XHTML font que ce fichier est lui-même ma base de données de news !
Je voulais donner mon point de vue, et j'espère mettre en place rapidement les commentaires, pour que vous puissiez réagir ;-)
1 De Batmat -
>qu'à poster Eris Daspet c
qu'a posté Eric
2 De Eric Daspet -
rohh, vieux mais toujours d'actualité ce billet d'humeur. Je me permet juste de rajouter ce qui était clair à l'époque et qui ne l'est peut être plus autant avec le changement de contexte : c'était un billet pour expliquer mes choix, pas vraiment pour essayer d'inciter les autres à faire les mêmes.
Sur le fait que certains doivent essuyer les platres, je ne le dirai pas comme ça, mais je dirai simplement "je n'ai aucun intérêt à le faire moi", je laisse donc ceux qui en ont besoin le faire à ma place. C'est un peu comme si demain le site de la SNCF perdait en compatibilité et que le service te disait "il faut bien que quelqu'un essuie les platres". Si c'est nécessaire essuyons les, mais ne le faisons pas par pure versionnite. L'exception c'est si bidouiller et essayer est votre plaisir, le plaisir ça ne se discute pas.
Pour le coup du structuré je vais me permettre un "QUOI ?" assez fort. Le HTML (SGML) est tout aussi structuré que le XHTML (XML). La structure générale est la même, les règles de gestion et possibilités sont les mêmes. En fait non d'ailleurs, SGML est plus complet que XML ;) Le SGML est tout aussi structuré que le XML, d'ailleurs le milieu bibliothécaire n'a pas attendu XML pour gérer ses fichiers et ses structures. Pour le coup ça c'est vraiment un "on dit" basé sur rien. Tu peux faire ton fichier structuré dans un format ou dans l'autre, ça ne changera rien. D'ailleurs tu peux très bien faire une conversion automatique sans perte de l'un à l'autre. C'est la preuve s'il en était besoin que c'est totalement équivalent au niveau possibilité de structure.
En apparté, j'aimerai pousser un "Mouais" quand j'entend l'association XML - base de données. Oui c'est structuré, mais ça remplace autant mon serveur de base de données qu'un fichier excel, qu'un fichier cvs ou que mon bête fichier texte plat dans mon format à moi. XML est un format d'échange (simple à interpréter, base commune implémentée dans la plupart des langages de programmation). C'est déjà moyennement efficace comme format de stockage (inutilement verbeux), mais c'est totalement contre-productif comme format d'exploitation (ce dont on a besoin pour une base de données). Un fichier XML comme source de donnée interne c'est cumuler tous les désavantages sans aucun des avantages. c'est excessivement verbeux (stockage trop grand et interprétations inutiles à la relecture), c'est à taille variable (pas de possibilité de lecture transversale ou de passer directement à l'enregistrement suivant), et c'est surtout non indexé (pas de possibilité de recherche à part en lisant séquentiellement le fichier). Je ne dis pas que ce n'est pas possible ou que le XML ne sert à rien, mais ça ne rentre pas plus en concurrence avec le SGBD qu'un bête fichier CSV (qui lui a au moins la bonté d'être peu verbeux). Ne mélangeons pas tout, là c'est comparer une application et un format de données, c'est forcé qu'on ne remplacera jamais l'un par l'autre.
(restez en ligne, dans quelques mois une suite à blog.dreams4net.com risque de fleurir, avec des vraies fautes d'orthographes dedans, comme avant)
3 De Vincent -
Tu es décidément toujours aussi prolixe, il va te falloir de nouveau un blog :D
Bon passons les plaisanteries, cela fait plaisir d'avoir de tes nouvelles, surtout pour une telle réaction ;-)
Comme tu t'en doutes, je me dois (encore) de te répondre, sinon ça ne serait pas marrant. C'est partie pour une petite joute (amicale) comme on en voyait plus depuis longtemps dans la blogosphère ;-)
- Essuyer les platres, bof bof
Mais si ! C'est marrrant ! Bon je ne dit pas qu'il faut mettre en place ces choses sur de gros serveurs de production (et encore).
Mais regardons la chose de plus près et plus sérieusement. Un site en XHTML 1.1 fonctionne sur Firefox puisqu'envoyé en application/xhtml+xml. Un site en XHTML 1.1 fonctionnouille sur IE s'il est envoyé en text/html mais ce n'est pas conforme à la norme.
Bah moi je dis bof, et alors ? Je n'ai encore jamais vu de navigateur qui ne supportais pas le XHTML 1.1 envoyé en text/html. L'expérience montre que ça fonctionne. Bon ok ce n'est pas valide, mais envoyer une page à IE sans lui mettre l'en-têtes XML, ce n'est pas bien non plus, et tout le monde le fait pourtant (pour une bonne raison).
La fin justifie parfois les moyens, et moi, je veux que les normes se voient, alors je les montre :-)
- Le HTML est tout aussi structuré que l'XHTML.
Bah il va falloir définir le mot structuré avant, je pense que c'est sur ce point que porte l'ambiguïté. Alors oui, il est tout aussi possible de construire un arbre DOM avec de l'HTML qu'avec de l'XHTML, mais tu avoueras que c'est rudement plus complexe pour le parseur de le faire à partir de l'HTML.
Le SGML est un format à balisage, c'est à dire que l'on place des balises linéairement et qu'elles vont changer l'état du parseur. Pour un format propriétaire, pas trop de problèmes, mais imagine la taille de la machine à état avec le nombre de balises disponibles en HTML 4.01.
Le XHTML est tout simplement plus facile à parser puisqu'il permet directement de définir un arbre. On peut donc facilement y appliquer des transformations, s'y balader, utiliser XSL ou XPath.
- Le XML n'est pas une base de données
Je ne voulais pas dire qu'XML était une base de données, ce que j'énonçais était qu'utiliser XML me permettait de me passer de base de données ;-)
Je suis tout à fait d'accord avec toi sur le principe qu'XML ne peut sûrement pas remplacer une base de données, il est juste très pratique pour stocker facilement et simplement de petites données structurées, et surtout (surtout !) pour en garantir l'accessibilité.
4 De Eric Daspet -
Non non, HTML est aussi un format pour définir un arbre de données, autant que XML. La seule différence c'est que la fermeture des balise peut être implicite et devinée par la DTD (en gros dans <p><i>hello<p> le moteur sait que <i> et <p> ne peuvent pas contenir de <p> et se ferment donc automatiquement). C'est effectivement plus complexe à manipuler, même si les moteurs SGML existent depuis longtemps (donc ne devraient pas être en soit un blocage). Mais c'est aussi structuré ou hiérarchique que le HTML, c'est vraiment juste une différence de syntaxe.
Même chose, je peux utiliser XSL pour générer du HTML, je peux même utiliser XSL ou XPATH sur du HTML pour peu que mon moteur sache lire la syntaxe SGML en entrée. Pour exemple mon javascript sait utiliser XPATH sur HTML, mon PHP sait utiliser XSL sur HTML, et là on ne parle pas d'outils très complexes ou réservés à une élite hein.
La question c'est, vu que ce que tu pensais réservé au xhtml marche aussi sur du html, as tu besoin du xhtml ? Une fois les préjugés sortis tu n'en as probablement pas "besoin". Maintenant que c'est établi reste à choisir, là on prend en compte les gouts et les envies, donc tous les choix sont bons.