Parlant d'expérience! Interpréter les malentendus de la production de pages Web Div+CSS

Auteur：Eve Cole Date de mise à jour：2009-05-31 01:04:51

La brise printanière de la « reconstruction » souffle sur tout le pays, et Internet est en pleine tourmente depuis un certain temps. « div+CSS » est devenu une « mode ». D'innombrables sites Web ont invariablement commencé leur propre « reconstruction ». Cependant, ouvrir le code source de ces différents sites fait souvent rire——

Nous voyons des mises en page div avec 6 ou 7 couches d'imbrication, des tableaux sans tableaux, des pages composées de pur div+a, et des centaines de classes de couches de présentation... Il existe de nos jours de plus en plus de livres sur les standards à l'exception de quelques livres qui font de la publicité. "techniques avancées", peu de gens n'insisteraient pas sur une telle phrase dans les premiers chapitres de leurs livres - "séparation de la structure et de l'expression". Cependant, combien de lecteurs de ces livres ont lu sérieusement les premiers chapitres ? Ou préférez-vous ignorer les explications ennuyeuses de la structure et vous plonger dans les techniques de mise en page et les hacks apparemment avancés ?

En fait, le terme div+CSS a induit trop de gens en erreur depuis le début, et la mentalité avide de succès rapide est la coupable de ce phénomène. La première étape pour qu'une personne habituée à la production de pages Web avec mise en page de tableaux entre en contact avec les normes ne devrait pas être de rechercher aveuglément des techniques CSS pour mettre en œuvre diverses mises en page, mais de s'efforcer de changer sa façon de penser.

Ci-dessous, je parlerai de la façon de penser dans le respect des normes en fonction de mon expérience personnelle. Beaucoup d'entre eux sont des détours que j'ai faits, j'espère que cela sera utile aux XDJM qui viennent d'entrer en contact avec les normes :

1. « Enregistrer le code » est un outil marketing, pas un objectif

"L'utilisation de la disposition div peut économiser plus de code que la disposition des tableaux", j'ai vu cette phrase dans de nombreux livres et sites Web. Cette phrase elle-même est correcte. « Enregistrer le code » est en effet l'un des avantages de la standardisation des pages Web. Cependant, rappelez-vous qu’il ne s’agit que de « l’un des avantages », et non du « seul avantage », et que ce n’est pas le but. « Enregistrer le code » est le plus souvent un stratagème marketing que nous utilisons pour convaincre les patrons têtus. Le seul objectif de la normalisation des pages Web est de « séparer la structure et les performances », et il ne s'agit jamais de sauvegarder du code pour le simple plaisir de sauvegarder du code. Une fois, j'ai utilisé une classe unifiée car la barre latérale et même le contenu principal du site Web ont la même forme de présentation (il existe encore des livres qui l'enseignent). Cela permet en effet d'économiser davantage de code que de nommer les identifiants séparément. Cependant, le coût est important. c'est que le code perd sa bonne qualité de structure. Les conséquences de la perte d'une bonne structure sont : 1. Le code source n'est plus lisible. 2. Le site Web augmente les coûts de maintenance inconnus ; Imaginez simplement, lorsqu'un certain élément de contenu change de présentation en raison de besoins, tels que la couleur d'un lien, etc., nous devons modifier le fichier source de la page et ajouter des classes supplémentaires. La charge de travail est bien plus importante que le simple ajustement de l'identifiant. regroupement. Et si les choses continuent ainsi, la structure va se détériorer de plus en plus, formant un cercle vicieux difficile à inverser.

Il existe une autre situation qui se produit dans la dénomination des identifiants, qui est également une erreur que j'ai commise. A cette époque, afin de « sauvegarder le code », le menu principal était nommé « mm », le menu secondaire était nommé « m2 » et le menu de troisième niveau était nommé « m3 ». La page Web a été sérieusement réduite, ce qui a rendu difficile la prise de relais par d'autres collègues, essayant d'éviter les ennuis mais me fatiguant. De la même manière, il n'est pas conseillé de simplifier à l'excès la dénomination des fichiers et des dossiers. Par exemple, "Website Reconstruction" recommande de stocker toutes les images dans le répertoire "i". Personnellement, je pense que ce n'est pas conseillé à moins que vous ne puissiez écrire pour cela. une structure de répertoires très abrégée. Expliquez en détail et assurez-vous que toutes les personnes impliquées, y compris les autres membres du personnel de production, les développeurs et même les patrons compétents... peuvent la comprendre et la mettre en œuvre, sinon cela ne fera que vous ajouter des problèmes inutiles.

2. L'identification est un fusil de sniper, la classe est une épée à double tranchant

Si vous voulez avoir une bonne structure de page Web, l'ID et la classe doivent être maîtrisés avec compétence. Ce qu'on appelle « saisir à deux mains, les deux mains doivent être fortes ». L'ID est comme un fusil de sniper, qui peut nous aider à localiser avec précision les éléments que nous voulons charger, et la classe est l'épée du chevalier, qui est plus légère et plus flexible au bout des doigts. La combinaison des deux peut obtenir une page avec une bonne structure. et des performances riches. Cependant, il existe désormais une vision erronée selon laquelle l'identifiant peut être complètement remplacé par la classe. En fait, cela est vrai pour de nombreux codes sources de pages Web. Lorsque vous ouvrez la classe entière, vous ne pouvez pas trouver d'identifiant. Il existe de nombreuses raisons à ce phénomène, mais le concept profondément enraciné de « class=CSS » transmis depuis l'ère des tables en est la cause profonde. Il est vrai que class est plus polyvalent et flexible que id, mais il faut aussi comprendre que class est beaucoup moins efficace que id pour construire une bonne structure de page Web. Le caractère unique obligatoire de id nous permet de récupérer facilement n'importe quel module dont nous avons besoin via id, alors que class n'a pas cet avantage. Bien que nous puissions définir un nom de classe unique pour le module, le principe est que seul le producteur lui-même peut modifier le style de la page Web. Sinon, trouvons un gars un peu paresseux. Voyant que les styles sont les mêmes, il appliquera directement la classe précédente. Le résultat est qu'on constate qu'il y a plus d'une douzaine de modules dans la page web appelés "gonggao" ou "xinwen". ", ce qui fait qu'il est difficile de les distinguer. Sans ajouter beaucoup de commentaires html, ce résultat n'est évidemment pas celui que nous souhaitons. De plus, comme mentionné précédemment, le code enregistré via les classes universelles doit être gaspillé dans chaque classe définie individuellement.

L'identification est un fusil de sniper et la classe est une arme à double tranchant. Ensemble, nous bénéficions tous les deux, et séparément, nous perdons tous les deux.

3. Tous les contenus ne nécessitent pas div comme « conteneur »

Dois-je utiliser

ne contient qu'un seul élément

Cette proposition peut en fait être étendue à : "Tous les contenus n'ont pas besoin d'éléments de bloc comme conteneurs" et "Tous les liens n'ont pas besoin d'autres éléments comme conteneurs", comme "plus" que de nombreuses pages ont. Certaines personnes écrivent "

", tandis que d'autres écrivent

ou . Doivent-ils encore exister lorsque ces "conteneurs" ne contiennent qu'une balise ? L'écriture directe briserait-elle la structure ? Manquera-t-il de sémantique ? Est-ce que cela affectera la mise en page ? Si vous pensez différemment, vous obtiendrez peut-être quelque chose de différent.

4. Parvenir à la « séparation de la structure et de la performance » au travail

Sur ce point, de nombreux experts sur Internet suggèrent ceci, c'est-à-dire ouvrir d'abord l'éditeur, écrire complètement la structure, puis aller en CSS pour écrire la performance, et essayer de ne pas toucher à la structure déjà écrite.

Cependant, il est difficile de comprendre pour les personnes qui utilisent la lecture de livres comme principale méthode d'apprentissage, car la plupart des livres sur les normes enseignent étape par étape, ce qui signifie qu'ils doivent combiner structure et expression étape par étape. Bien que certains livres contiennent des suggestions à cet égard, quelques phrases courtes sont bien inférieures aux effets subtils du processus de lecture. Lorsque le personnel de production peut avoir une bonne compréhension de la structure, la structure d'écriture et les performances en même temps n'auront pas beaucoup d'impact sur les résultats. Mais d'après mon expérience, la méthode de travail consistant à séparer la structure et la présentation est bien plus efficace que d'écrire en même temps la structure et la présentation. En même temps, il n'est pas facile de manquer des éléments sur la page.

Bien entendu, la soi-disant « séparation de la structure et des performances » ne signifie pas que les performances sont complètement ignorées. Si vous souhaitez prendre en compte les performances, vous devez vous assurer que le sélecteur CSS peut sélectionner autant de contenu que possible sans détruire la structure. . Où ajouter des classes, ou quelles étiquettes utiliser pour les distinguer, est une question d'opinion. Je pense que chacun a sa propre expérience. En combinant différentes versions de conception, il est parfois nécessaire d'apporter les modifications correspondantes. Cependant, ces modifications doivent toutes avoir le même principe : ne pas détruire la structure et la lisibilité du code.

De plus, il faut réaliser que tout outil visuel est un diable. Les effets présentés dans leurs interfaces visuelles sont souvent à des milliers de kilomètres de ceux des vrais navigateurs. Ce avec quoi nous voulons vraiment être compatibles, c'est le navigateur, pas l'interface visuelle de l'éditeur.

5. CSS n’est pas une panacée et il n’est pas impossible de vivre sans CSS.

Par rapport à l'ère CSS1.0, CSS peut accomplir plus de choses aujourd'hui. Cependant, la demande est toujours en avance sur la technologie. Parfois, nous devons combiner JS ou d'autres langages pour obtenir certains effets. . D’autres fois, utiliser JS est beaucoup plus simple que de s’appuyer uniquement sur CSS, et le code est plus bien structuré – l’exemple le plus typique est le menu déroulant. Dans ces moments-là, nous devons nous convaincre nous-mêmes, ou convaincre nos patrons et nos clients, d’utiliser des méthodes plus simples et plus raisonnables. Parce que DOM est également un élément important des standards des pages Web, cela ne signifie pas que l'utilisation de JS rendra nos pages Web moins efficaces ou ne seront plus standard. Au contraire, c'est le plus gros malentendu sur JS. Cela dit, je dois mentionner qu'à l'époque actuelle, chaque profession doit posséder des connaissances plus pertinentes que jamais. Ceux qui font du design doivent connaître un peu l'interaction et la production, et ceux qui font de la production doivent également comprendre la conception et la programmation. , en particulier Avec les technologies frontales comme JS, ce n'est qu'ainsi que vous et vos collègues pourrez mieux travailler ensemble et vos perspectives de développement personnel seront plus prometteuses.
Aucun CSS fait référence au moment où notre site Web ne parvient pas à charger le fichier CSS pour diverses raisons inconnues. Ne paniquez pas à cause de cela. C'est le meilleur moment pour tester la qualité de notre code. Si la page Web conserve toujours une bonne lisibilité sans CSS, cette réussite est bien plus digne de notre fierté que de passer la vérification du W3C.