J'ai commencé à apprendre les standards du Web au début de l'année dernière et j'ai acquis une certaine expérience au cours des deux dernières années. J'ai récemment changé de travail et je suis juste libre à la maison, alors j'ai écrit quelque chose à partager avec tout le monde.
1. Compréhension des standards du Web et des spécifications XHTML du W3C
Selon l'entendement habituel, ces deux concepts semblent faire référence à la même chose (ces « théories avancées » dont nous discutons dans cette édition^_^). Mais je pense qu’en fait, d’un point de vue technique, ces deux choses n’ont pratiquement aucune corrélation. En bref, les standards du Web consistent à implémenter de manière indépendante la structure, les performances et le comportement de la page. Plus communément, il s'agit du langage populaire « div+css » dans le recrutement d'aujourd'hui. Cependant, aucune version du W3C XHTML n'impose de restrictions sur le concept de standards Web. Évidemment, nous pouvons utiliser xhtml 1.1 pour écrire une page Web positionnée dans un tableau. À ce stade, vous penserez peut-être que je dis beaucoup de bêtises. Mais avec n’importe quelle technologie, vous ne pouvez l’utiliser correctement que si vous comprenez suffisamment clairement les concepts de base. Permettez-moi de parler des deux voies erronées dans l'application actuelle des standards du Web sous les deux aspects suivants :
Le premier cas est simple. Je pense que tant que XHTML+CSS est utilisé, c'est un standard du Web. La page est pleine de classes et d'identifiants. N'hésitez pas à définir des classes distinctes pour chaque détail. La différence entre une telle page et le HTML traditionnel est qu'il y a un "/" supplémentaire dans la balise img. En fait, il vaut mieux revenir au HTML traditionnel. Au moins, je peux utiliser facilement les polices sans avoir à rechercher la feuille de style comme un dictionnaire. Une autre utilisation plus subtile et décontractée du CSS dont je parlerai plus tard.
Je pense que la deuxième situation est plus difficile à comprendre, c'est-à-dire essayer d'utiliser diverses instructions compliquées d'imbrication div et css pour obtenir les performances souhaitées. Un exemple très simple est dans un article que je viens de voir "Coins arrondis de la page sans couper l'image". Tout d'abord, je veux être sûr que cette idée est vraiment bonne, utiliser la fonction CSS pour "dessiner" les coins arrondis. Pour ce faire, le concepteur doit ajouter une grande section de code comme suit à l'emplacement correspondant :
| Voici le contenu cité : Exemple de code source [www.52css.com] <b class="b1"></b><b class="b2"></b><b class="b3"></b><b class="b4"></b> <b class="b4"></b><b class="b3"></b><b class="b2"></b><b class="b1"></b> |
Cependant, cela viole sérieusement le concept de base des standards du Web, à savoir la séparation entre structure et présentation. Parce qu'il place le code utilisé pour contrôler les performances de la page Web dans le document structurel. Peut-être diriez-vous que cela met réellement le vrai code de performance en CSS. Mais je pense que c'est un concept volé. Parce que les balises b ci-dessus n’ont rien à voir avec la structure de la page Web, ce sont toutes des balises vides. Autrement dit, il n'existe pas de placer quelque chose là où la structure du document l'exige. Ce ne sont donc que du code indésirable pour la structure des documents.
Un autre exemple est peut-être plus subtil. J'ai déjà vu un article sur alistapart.com sur la façon d'implémenter des colonnes à trois voies sur une page Web. Le principe est probablement d'utiliser trois ou quatre divs pour s'emboîter. Je pense que c'est aussi une violation des standards du Web. Parce que l’ordre dans lequel ces balises div sont placées dans le code ne répond pas simplement à des besoins structurels, mais à la performance de la page Web.
Bien sûr, j'admets que le point de vue ci-dessus est dans une certaine mesure exagéré (mais d'un autre côté, si vous devez implémenter des coins arrondis sans image, n'est-ce pas aussi exagéré, haha). Parfois, structure et performances ne sont pas si facilement séparées. Afin d'obtenir des performances riches, nous devons laisser la structure s'adapter (pensez à l'utilisation de <div style="clear:both" />). Mais il est important de savoir ce qui est bien et ce qui ne va pas. Même si nous devons parfois faire quelque chose de mal.
Enfin, je tiens à préciser que je ne dis pas que les "coins arrondis sans image" n'ont aucun sens ou sont faux. J'admire également l'intelligence et l'inspiration de l'auteur. Je pense que ce type de recherche technique revient à utiliser CSS pour dessiner le drapeau national auparavant, et c'est très utile pour maîtriser la technologie CSS. Cependant, son utilisation devrait être aussi limitée que l'indicateur CSS et ne devrait pas être adoptée dans des applications pratiques. Parce que cela viole les principes de base des standards du Web.
2. La sémantique des balises HTML
Les normes Web actuelles sont communément appelées « div+css » ou « layout en couches ». Je ne m'oppose pas à cette opportunité. Mais cela conduira à un malentendu : utiliser un grand nombre de balises div comme éléments structurels. En fait, il s'agit d'une forme plus avancée d'abus de div (mentionnée par Jeffrey Zeldman dans le livre "Website Refactoring").
HTML nous offre une multitude de balises, chacune ayant sa propre signification. Je pense que lors de la conception, en plus de suivre la syntaxe HTML, nous devons utiliser pleinement et respecter la « sémantique » de chaque balise. Par exemple, le texte du titre doit être inclus entre h1 et h6, les grands paragraphes du contenu du texte doivent être segmentés par <p> au lieu de <br />, les éléments de la liste doivent être placés dans ul, ol ou dl et les données sous forme de tableau. devrait toujours être la disposition de la table.
Pourquoi faire ça ? Une raison très convaincante est de garantir que lorsque l'utilisateur supprime l'affichage CSS, la page Web puisse afficher la hiérarchie structurelle du contenu aussi efficacement que possible. Si tous les div sont utilisés, lorsque le CSS est supprimé, la page Web entière perdra sa hiérarchie, ne laissant que quelques fragments de texte désordonnés. Cela ne répond pas aux exigences de la norme Web en matière de compatibilité avec une faible configuration.
Permettez-moi d'énumérer en détail ma compréhension de la sémantique de certaines balises :
p fr
Parlons d’abord du plus simple. Utilisez des balises p au lieu de br (même deux <br /> consécutives) pour les paragraphes. Cela semble aller de soi. Mais il faut parfois renoncer à ce principe. Un exemple courant est un message sur un forum. Si je souhaite le segmenter, j'appuie sur Entrée. Ce qui est transmis en arrière-plan et affiché de cette manière est évidemment segmenté à l'aide de <br />.
tableau e
En raison de la promotion vigoureuse de div+css, il semble que quiconque utilise la disposition des tableaux soit un natif non civilisé. Mais je pense que cette vision est incorrecte. La signification de tableau est un tableau, donc toutes les données qui doivent apparaître sous forme de tableau doivent toujours être présentées dans un tableau. Un exemple simple est la liste des camarades de classe, comprenant les noms, les cartes d'identité des étudiants, les sexes, etc. Il s'agit évidemment de données sous forme de tableau, donc la disposition en tableau doit être utilisée. Un autre exemple à explorer est la navigation dans le calendrier du blog. J'ai vu une fois un programme de blog. Les dates dans sa navigation dans le calendrier sont toutes entourées de divs du 1er au 30, puis le style float:left est utilisé pour organiser le calendrier du mois en cours dans une rangée de 7. Lorsque j'annule l'affichage CSS du navigateur, la partie du calendrier est disposée verticalement du n°1 au n°30. Je pense que c'est faux. Étant donné que le calendrier doit être constitué de données sous forme de tableau, la disposition en tableau doit toujours être utilisée. Après avoir annulé le CSS, ils doivent toujours être regroupés dans un tableau avec 7 d'affilée.
c'est une autre balise qui sera ignorée. En raison de la toute-puissance du CSS, toutes les cellules du tableau peuvent être créées à l'aide de td et d'un attribut de classe. Mais sémantiquement, certaines cellules du tableau doivent être étiquetées avec th. Par exemple, dans le tableau du calendrier mentionné ci-dessus, les unités "MON TUE WED... SUN" qui identifient la semaine doivent utiliser th au lieu de td.
h1-h6
Pour les balises h1-h6, sémantiquement, elles devraient fonctionner pour tout le texte du titre. Par conséquent, certaines méthodes d'écriture telles que <div class="diary-title> sont redondantes. Écrivez-le directement sous la forme <h1>, puis définissez directement CSS pour h1 au lieu de .diary-title. Cela n'aurait-il pas le même effet ? Bien sûr, cette règle I ne peut pas être trop rigide, car parfois les éléments structurels de la partie titre ne peuvent pas être résolus simplement en utilisant un h1, mais tout au plus j'utilise une méthode comme <h1><span></ span></h1> pour changer le titre. La structure est imbriquée de manière plus complexe pour répondre aux besoins de performances.
Mais un désaccord sémantique surgit ici. Faut-il comprendre h1 comme un titre de premier niveau ou comme un titre avec une taille de police de taille 1 ? Je le comprends généralement comme un titre de premier niveau, et s'il y a des sous-titres sous le titre de premier niveau, utilisez h2. Mais en fait, si l’on revient au début de la conception HTML, les nombres après h1-h6 sont davantage compris comme contrôlant la taille du texte du titre. h3 peut être utilisé uniquement pour utiliser une police de taille trois, et non pas qu'il s'agisse d'un en-tête de troisième niveau. Sinon, tous les titres de premier niveau utilisent h1, et tous sont de très grandes polices, et vous devez utiliser CSS pour contrôler la taille de la police, ce qui semble très fastidieux. C'est donc une question à débattre.
ul ol
Chaque fois que vous avez besoin de lister des termes, vous devez utiliser ul ou ol au lieu de p. Par exemple, les exigences du poste dans les annonces de recrutement, telles que les précautions, telles que les instructions sur les étapes de l'opération. De plus, une utilisation courante consiste à utiliser ulli pour répertorier le menu de navigation de la page Web, puis à utiliser CSS pour contrôler sa disposition.
Il faut ajouter qu'il ne faut pas oublier que ul ou ol peuvent être utilisés dans li pour former une liste de deuxième niveau.
dl dt jj
Il s'agit d'un ensemble de balises presque oublié, mais Jeffrey Zeldman promeut fortement leur utilisation dans le "Website Refactoring". dl devrait être le nom complet de "liste de définitions (ou liste de définitions ? Si quelqu'un le sait, dites-le moi)". Une utilisation typique est une entrée de dictionnaire. Le nom du mot est placé en dt et l'explication du mot est placée en dd. Le site alistapart.com est encore plus astucieux, définissant toute la colonne de droite comme dl, en utilisant dt pour le titre de chaque unité, et dd pour le contenu de l'unité.
img
La balise img elle-même n'a pas grand chose à dire. Je veux juste parler d'un lieu commun, c'est-à-dire utiliser img uniquement lorsque cet élément est effectivement une image nécessaire dans le contenu, sinon il devrait être défini comme un style utilisant CSS. Comme les illustrations, les avatars, les émoticônes, ce sont des images qui doivent apparaître dans le contenu, utilisez img. D'autres, comme l'image d'arrière-plan du titre et la petite icône devant l'élément de liste, ne doivent pas utiliser la balise img.
portée
span est désormais aussi populaire que div. Mais en fait je pense qu’il faut s’en tenir à son usage initial. Ma compréhension personnelle est que le span était à l'origine utilisé pour porter des attributs de classe ou de style. En soi, il n’a pas de sémantique claire. Par conséquent, dans le flux de texte, si nous devons apporter des modifications de style à un texte, nous utilisons span pour le délimiter. Par exemple, si certains mots doivent être ajoutés en rouge, j'utilise <span class="red">.
Cependant, il convient de noter que cela peut provoquer les problèmes mentionnés précédemment au point h1. Étant donné que certains styles de texte ont en fait des balises prêtes à l'emploi, telles que <strong>, <sub>, etc., nous devrions également leur donner certaines opportunités de manière appropriée.
un
a est l'étiquette qui contrôle l'hyperconnexion. Mais il existe des cas particuliers dans lesquels nous n’aimerons peut-être pas l’utiliser. Par exemple, une petite fenêtre doit apparaître. Je n'y ai pas prêté beaucoup d'attention, mais je pense que certains concepteurs définiront onclick directement dans la balise <img> de l'icône "play". Personnellement, je pense que nous devrions ajouter un a en dehors de l'img, puis définir onclick à l'intérieur de a, et n'oubliez pas d'écrire return false à la fin de la fonction js. Si possible, l'attribut href de la balise a doit également être écrit avec l'URL de la fenêtre contextuelle pour garantir que les utilisateurs peuvent toujours ouvrir efficacement la page même si JS est désactivé.
C'est tout ce que je vais énumérer pour l'instant.
Enfin, résumons l’importance de suivre la sémantique des balises HTML. L'une des exigences des standards du Web est la compatibilité low-profile : lorsqu'un utilisateur désactive les images, désactive CSS ou désactive JS, nous pouvons toujours lui permettre de parcourir efficacement le contenu Web. Comme nous le savons tous, l'attribut alt obligatoire consiste à prendre en compte la compatibilité lors de la désactivation des images. Suivre correctement la sémantique des balises HTML garantit la compatibilité lorsque CSS est désactivé. Ce n'est que lorsque les balises HTML sont utilisées correctement et que notre page Web est en « strie CSS » que les gens pourront toujours voir où se trouve le menu de navigation, où se trouve le titre de l'article, et le tableau du calendrier ne s'effondrera pas.