Ich spreche aus Erfahrung! Interpretieren Sie die Missverständnisse der Div+CSS-Webseitenproduktion

Der Frühlingswind des „Wiederaufbaus“ weht im ganzen Land und das Internet ist seit einiger Zeit in Aufruhr. „div+CSS“ ist zur „Mode“ geworden. Allerdings bringt das Öffnen des Quellcodes dieser verschiedenen Websites die Leute oft zum Lachen –

Wir sehen div-Layouts mit 6 oder 7 verschachtelten Ebenen, Tabellen ohne Tabellen, Seiten, die aus reinem div+a bestehen, und Hunderte von Präsentationsebenenklassen ... Heutzutage gibt es immer mehr Bücher über Standards, mit Ausnahme einiger weniger Bücher, die Werbung machen „Fortgeschrittene Techniken“, nur wenige Menschen würden einen solchen Satz nicht in den ersten Kapiteln ihrer Bücher hervorheben – „Trennung von Struktur und Ausdruck“. Doch wie viele Leser dieser Bücher haben die ersten Kapitel ernsthaft gelesen? Oder überspringen Sie lieber die langweiligen Strukturerklärungen und stürzen sich lieber in die scheinbar fortgeschrittenen Layout-Techniken und Hacks?

Tatsächlich hat der Begriff div+CSS von Anfang an zu viele Menschen in die Irre geführt, und die Mentalität des Strebens nach schnellem Erfolg ist der Schuldige dieses Phänomens. Der erste Schritt für jemanden, der mit der Erstellung von Tabellenlayouts auf Webseiten vertraut ist, um mit Standards in Kontakt zu kommen, sollte nicht darin bestehen, blind nach CSS-Techniken zu suchen, um verschiedene Layouts zu implementieren, sondern sich darum zu bemühen, seine Denkweise zu ändern.

Im Folgenden werde ich auf der Grundlage meiner persönlichen Erfahrungen über die Denkweise in Bezug auf Standards sprechen. Ich hoffe, dass dies für XDJMs hilfreich ist, die gerade mit Standards in Berührung gekommen sind:

1. „Code speichern“ ist ein Marketinginstrument, kein Zweck

„Mit dem Div-Layout kann mehr Code gespart werden als mit dem Tabellenlayout“, diesen Satz habe ich in vielen Büchern und auf Websites gesehen. Dieser Satz selbst ist richtig. „Code sparen“ ist tatsächlich einer der Vorteile der Webseitenstandardisierung. Bedenken Sie jedoch, dass es sich nur um „einen der Vorteile“ handelt, nicht um den „einzigen Nutzen“ und nicht um den Zweck. „Code speichern“ ist häufiger ein Marketingtrick, mit dem wir hartnäckige Chefs überzeugen wollen. Der einzige Zweck der Webseitenstandardisierung ist die „Trennung von Struktur und Leistung“, und es geht nie darum, Code zu speichern, um Code zu speichern. Ich habe einmal eine einheitliche Klasse verwendet, weil die Seitenleiste und sogar der Hauptinhalt der Website die gleiche Präsentationsform haben (es gibt immer noch einige Bücher, die dies lehren). Dies spart zwar mehr Code, als die IDs separat zu benennen Der Grund dafür ist, dass der Code seine gute Struktur verliert. Die Folgen des Verlusts einer guten Struktur sind: 1. Der Quellcode ist nicht mehr lesbar; 2. Die Website erhöht unbekannte Wartungskosten. Stellen Sie sich vor, wenn ein bestimmter Inhalt aufgrund von Anforderungen seine Darstellung ändert, z. B. die Farbe eines Links usw., müssen wir die Seitenquelldatei ändern und zusätzliche Klassen hinzufügen. Der Arbeitsaufwand ist viel größer als nur die Anpassung der ID Gruppierung. Und wenn es so weitergeht, wird die Struktur immer schlimmer und es entsteht ein Teufelskreis, der nur schwer umzukehren ist.

Bei der Benennung von IDs tritt noch eine weitere Situation auf, bei der es sich ebenfalls um einen Fehler handelt, den ich gemacht habe. Um „Code zu sparen“, wurde damals das Hauptmenü „mm“, das Nebenmenü „m2“ und das Menü der dritten Ebene „m3“ genannt Die Webseite wurde stark reduziert, was es für andere Kollegen schwierig machte, sie zu übernehmen. Ich versuchte, mir Ärger zu ersparen, ermüdete mich aber. Ebenso ist es nicht ratsam, die Benennung von Dateien und Ordnern zu vereinfachen. Beispielsweise empfiehlt „Website Reconstruction“, alle Bilder im Verzeichnis „i“ zu speichern. Ich persönlich halte es nicht für ratsam, es sei denn, Sie können dafür schreiben eine stark verkürzte Verzeichnisstruktur. Erklären Sie es ausführlich und stellen Sie sicher, dass alle Beteiligten, einschließlich anderer Produktionsmitarbeiter, Entwickler und sogar sachkundiger Chefs, es verstehen und umsetzen können, da es Ihnen sonst nur unnötige Probleme bereitet.

2. ID ist ein Scharfschützengewehr, Klasse ist ein zweischneidiges Schwert

Wenn Sie eine gute Webseitenstruktur haben möchten, müssen sowohl ID als auch Klasse gekonnt beherrscht werden. Das sogenannte „Greifen mit beiden Händen, beide Hände müssen stark sein“. ID ist wie ein Scharfschützengewehr, das uns helfen kann, die Elemente, die wir laden möchten, genau zu lokalisieren; und Klasse ist das Schwert des Ritters, das leichter und flexibler in der Hand ist. Durch die Kombination der beiden kann eine Seite mit guter Struktur erzielt werden und satte Leistung. Es gibt jedoch eine falsche Ansicht, dass die ID vollständig durch eine Klasse ersetzt werden kann. Tatsächlich trifft dies auf viele Webseiten-Quellcodes zu. Wenn Sie die gesamte Klasse öffnen, können Sie keine ID finden. Es gibt viele Gründe für dieses Phänomen, aber das tief verwurzelte Konzept von „class=CSS“, das aus der Tabellenära stammt, ist die Hauptursache. Zwar ist die Klasse vielseitiger und flexibler als die ID, aber es muss auch berücksichtigt werden, dass die Klasse beim Aufbau einer guten Webseitenstruktur weitaus weniger effektiv ist als die ID. Die obligatorische Eindeutigkeit von id macht es uns leicht, jedes benötigte Modul über id abzurufen, während class diesen Vorteil nicht hat. Obwohl wir einen eindeutigen Klassennamen für das Modul definieren können, gilt die Voraussetzung, dass nur der Hersteller selbst den Webseitenstil ändern kann. Ansonsten suchen wir nach einem etwas faulen Typ, der die vorherige Klasse direkt anwendet. Das Ergebnis ist, dass die Webseite mehr als ein Dutzend Module mit dem Namen „gonggao“ oder „xinwen“ enthält ", so dass es schwierig ist, sie zu unterscheiden. Ohne viele HTML-Kommentare hinzuzufügen, ist dieses Ergebnis offensichtlich nicht das, was wir wollen. Darüber hinaus muss, wie bereits erwähnt, der durch universelle Klassen eingesparte Code in jeder individuell definierten Klasse verschwendet werden.

ID ist ein Scharfschützengewehr und Klasse ist ein zweischneidiges Schwert. Gemeinsam profitieren wir beide, und getrennt verlieren wir beide.

3. Nicht alle Inhalte erfordern div als „Container“

Soll ich