De nombreux amis m'ont dit qu'il souffrait de mysophobie du code, c'est-à-dire que si on lui demande d'écrire du XHTML, il n'est jamais disposé à ajouter des balises supplémentaires. Pour donner un exemple simple, je pense que beaucoup de gens l’ont vu de nombreux endroits :
| Voici le contenu cité : <div id="nav"> <ul> <li></li> <li></li> ... </ul> </div> |
De nombreuses personnes, y compris de nombreux experts du secteur, vous suggèrent d'écrire simplement comme ceci :
| Voici le contenu cité : <ul id="nav"> <li></li> <li></li> ... </ul> |
Bien sûr, j’apprécie personnellement la deuxième façon d’écrire. Oui, elle est concise, claire et sémantique. Mais attendez, lequel offre plus de contrôle si vous avez besoin de le styliser, évidemment le premier ?
Alors, cette question devient un peu exaspérante. En un mot : Donnez-vous la priorité à la structure (balisage) ou à la présentation (présentation) ? Je crois que dans les moments difficiles d'aujourd'hui, la performance est la première règle. Pour beaucoup de personnes ayant des idéaux, dont moi, en fin de compte, afin d'atteindre les besoins de performance, la soupe aux tags est en fait inévitable.
Cela ne peut donc être qu’une question de degré. N'en abusez pas. Cela n’est pas considéré comme un abus et il n’existe aucune directive. Ma règle générale personnelle est la suivante : si vous utilisez plus de trois niveaux de wrappers (wrappers ?) pour atteindre une exigence de performance, vous devriez vous arrêter et y réfléchir. Même si c'est un peu ancien, je vous recommande de jeter un œil à quelques discussions intéressantes sur SimpleQuiz.
Pourquoi cela se produit-il ? Parce que rien n'est parfait. Imaginez, si CSS pouvait fournir plus de règles pour contrôler les éléments de la page, cela ne serait peut-être pas si embarrassant. Par exemple, si background-image prend en charge les images avec quatre directions différentes de trlb (haut, droite, bas, gauche), nous n'avons pas à nous creuser la tête pour gérer les coins arrondis s'il prend en charge la génération d'éléments à partir de la page, comme ; en tant que contenu, alors il peut également être considérablement réduit. L'utilisation de balises...
XHTML ? blague. En fait, peu de gens utilisent XHTML jusqu’à présent, et tout n’est qu’illusion. XHTML est mort ! XHTML est XML et présente tous les avantages de XML, mais ce que nous voyons maintenant, c'est du texte. Si le texte est traité au format XML, cela est nuisible (l'envoi de XHTML au format text/html est considéré comme nuisible).
Bien que nous indiquions tous sur Doctype que nous utilisons XHTML, en fait nous utilisons tous HTML. C'est la réalité. Sinon, comment ces pages mal formées et pleines d'erreurs pourraient-elles s'afficher dans des navigateurs modernes et tolérants... Pas étonnant, XHTML 1 n'est qu'une amélioration de HTML 4. Cependant, le futur XHTML 2 n'est pas rétrocompatible, et je ne sais pas pourquoi nous devons utiliser XHTML 1. Ne discutez pas non plus avec moi de l'accessibilité, HTML 4, qui sépare la structure et la présentation, n'est pas différent de XHTML 1.
Alors peut-être que l’intérêt d’utiliser XHTML 1 est de dire que nous avons déjà cette idée et que nous sommes prêts pour XHTML 2 dans le futur.
C'est pourquoi je recommande fortement d'utiliser le HTML 4.01 Strict Doctype. Du point de vue de l'entreprise, il n'est pas facile d'exiger que toute l'équipe ait l'idée des standards du Web et mette en œuvre les principes pertinents. Diverses idées héritées du siècle dernier résistent encore obstinément. Si vous utilisez vraiment XHTML 1, de nombreux scripts JavaScript uniquement compatibles avec HTML échoueront, la modification par inadvertance d'un caractère non échappé entraînera une erreur sur la page entière (erreur d'analyse XML), et ainsi de suite. Pour éviter les problèmes, HTML 4.01 Strict Doctype est peut-être le meilleur choix actuellement.