Warum müssen wir divs verwenden?


13

Als ich heute Morgen HTML und Haml schrieb, kam mir der Gedanke, dass die Art und Weise, wie Divs verwendet werden, lächerlich ist. Warum sind Divs nicht impliziert? Stellen Sie sich vor, wenn dies:

<div class="hero-img">
   <img src="http://whatever.com/this.jpg">
</div>

war das:

<hero-img>
   <img src="http://whatever.com/this.jpg">
</hero-img>

Wenn der Teil "div class" des Elements angenommen würde, wäre HTML semantischer und mit den passenden schließenden Tags unendlich besser lesbar!

Dies ist ähnlich wie bei HAML, wo wir haben:

.content Hello, World!

Welches wird:

<div class='content'>Hello, World!</div>

Es scheint mir, dass das Einzige, was passieren müsste, damit dies in Browsern funktioniert, darin besteht, dass die Browser beginnen könnten, jedes Element zu interpretieren, ohne dass eine vorhandene HTML-Elementdefinition dies impliziert <div class="<element name>">.

Dies könnte vollständig abwärtskompatibel sein. Für CSS- und jQuery-Selektoren usw. könnte "div.hero-img" weiterhin funktionieren und die erforderliche Syntax für die Auswahl der Elemente sein.

Ich kenne die neue Webkomponentenspezifikation, aber das ist wesentlich komplizierter als hier vorgeschlagen. Können Sie sich vorstellen, wie angenehm es wäre, auf die Quelle einer Website zu schauen und HTML-Code zu sehen, der so aussieht ?!

Warum müssen wir also divs verwenden?

Wenn Sie sich Mozillas HTML5-Elementliste ansehen , hat jedes Element eine semantische Bedeutung, und dann gehen wir zu <div>und es heißt:

Msgstr "Stellt einen generischen Container ohne besondere Bedeutung dar."

..und dann listen sie die willkürlichen Elemente auf, die sie zu html5 hinzufügen, wie <details>.

Wenn dieses Konzept impliziter Divs zur HTML-Spezifikation hinzugefügt würde, würde es natürlich zehn Jahre dauern, bis es zum Standard wird, was eine Million Jahre Webzeit bedeutet.

Ich denke, es muss einen guten Grund dafür geben, dass dies noch nicht geschehen ist. Bitte erklären Sie es mir!


Es gibt tatsächlich zwei nicht semantische Container: div und span
Lie Ryan

Antworten:


7

Problem 1: Leerzeichen

Ich glaube, das ist im Allgemeinen nicht aufgetaucht. Ein guter Grund, warum dies nicht der Fall ist und wahrscheinlich auch nicht passieren sollte, ist, dass white-spacesin CSS classesmehrere Klassen für das Element definiert werden, während sie in HTML definiert werden attributes.

Erläutern Sie den folgenden Code (oder bitten Sie einen Browser, ihn zu analysieren):

<pet family style=" ... ">
  <img src="my-pets-family.jpg"/>
</pet family>

Ist familydie Definition einer zweiten Klasse oder eines Attributs für das HTML-Element? Wie Sie wahrscheinlich aus dem Parser dieser Site ersehen können, handelt es sich vermutlich um ein Attribut.

Wenn ich also möchte <div class="pet family">, gibt es keine Möglichkeit, zwei Klassen zu definieren. Dies ist einer der beiden Hauptgründe, warum ich sowieso eine Klasse anstelle einer ID verwenden würde.

Problem 2: Aufwärtskompatibilität!

Die derzeitige Verwendung von <div>s zwingt uns (zumindest einige von uns), unseren Code ordnungsgemäß einzurücken und zu kommentieren. Dies ist eine gute Vorgehensweise für alle Programmiersprachen.

Stattdessen würde das Umwandeln von HTML-Blöcken in Variablen neuen Programmierern große Verwirrung darüber bringen, was in HTML etwas Bestimmtes ist und was nicht .

Außerdem führt dies zu dem lustigen Nebeneffekt, dass Sie Ihren alten Code mit neuen HTML5-Tags vergleichen sollten, um sicherzustellen, dass sie nicht den gleichen Namen haben, den Sie für die Klassen Ihres Divs verwendet haben ...

Das gleiche Problem gilt für die variablesVerwendung reserved wordsin einigen Sprachen. PHP löste es mit einem Dollarzeichen, so dass ein ähnlicher Ansatz in HTML nicht viel besser ausfiel als der derzeitige Gebrauch von <div class="something">.


Hätte es Probleme gegeben, <z:name1 attr1=foo attr2=bar> ... <z/name2 attr3=boz ... </z>wenn der Typ, der die "Klasse" erfunden hätte, angegeben hätte , dass dies semantisch äquivalent wäre, <div class="name1" attr1="foo" attr2="bar">...</div><div class="name2" attr1="boz"> ... </div>aber viel weniger Zeit für das Senden über ein 14,4-KB-Modem in Anspruch nehmen würde?
Supercat

Ich denke nicht. Dies wäre jedoch nur eine andere Syntax, um genau dasselbe zu schreiben, ohne das Konzept in <div class="">irgendeiner Weise zu verbessern . Aber warum definieren Sie das z:name1oder z/name2ist es das HTML-Tag classund nicht das HTML-Tag id? Und das Weißraumproblem taucht hier wieder auf. Es müsste also sein z:"name1 name2", zwei Klassen zu deklarieren, was so ziemlich wieder dasselbe wird.
mavrosxristoforos

Es gibt viele Syntaxmöglichkeiten. Mein Punkt war, dass es in einer Zeit, in der viele Leute 14.4K oder langsamere Modems verwendeten, eine Form geben sollte, bei der Bandbreitenprobleme zumindest ein wenig berücksichtigt wurden.
Supercat

Ich verstehe das auf jeden Fall. Als Webentwickler versuche ich immer noch, alles zu minimieren, um schnellere Websites und mehr zu erstellen. Ich glaube jedoch, dass dies in vielerlei Hinsicht ein guter Ansatz ist.
mavrosxristoforos

5

Wir verwenden <div>anstelle dessen, was Sie anspricht, dass die Verarbeitung und das Rendern durch den Browser einfacher sind.

Als Gegenbeispiel können Sie mit XML einen beliebigen Tag-Namen erstellen. Die Möglichkeit, beliebige Tag-Namen zu erstellen, ist mit Verarbeitungskosten verbunden. XML-Parser müssen ein Wörterbuch der in einem Dokument verwendeten Tags erstellen, während das Dokument analysiert wird.

Durch die Verwendung von <div>Browsern wissen Sie, dass sich dort ein Container befindet und dass er den Container ignorieren oder an ein anderes Tool in der Kette weitergeben kann, das möglicherweise etwas mit dem Container zu tun hat.


Ich bin mir ziemlich sicher, dass die Verarbeitungskosten verschwindend gering wären, wenn Browser nur die erwähnte implizite Div-Methode verwenden würden. Und die Vorteile beim Lesen und Beschreiben wären enorm.
Jordan Davis

3
<div>bedeutet weniger Komplexität, was immer gut ist. HTML besteht im Kern aus zwei Arten von Konstrukten: Blockebene und Inline-Markup. Wenn Sie mehr Möglichkeiten haben, das Gleiche auszudrücken, wird das Chaos, das HTML ist, nur noch größer.

" Erleichtert das Verarbeiten und Rendern durch den Browser. " Dies ist nicht wirklich wahr. Browser sind erforderlich, um nicht erkannte Tags zu analysieren, und alle DOM-Methoden und CSS-Selektoren müssen weiterhin wie erwartet mit ihnen arbeiten, und Browser wenden weiterhin CSS auf nicht erkannte Elemente an. Das einzige, was der Browser mit nicht erkannten Tags nicht macht, ist, die Standardstile (Benutzeragentenstile) und -verhalten anzuwenden.
Lie Ryan

3

Sie schlagen vor, Webautoren zu erlauben, HTML beliebige Elementnamen für private (nicht standardisierte) Zwecke hinzuzufügen. Dies hat ein großes Problem: Es wird gefährlich, neue Elemente zum HTML-Standard hinzuzufügen, da verschiedene Autoren möglicherweise bereits denselben Elementnamen für private Zwecke verwenden und dadurch die Semantik der Seite nachträglich ändern. Die Leute werden nicht glücklich, wenn neue Versionen von Browsern bestehende Webseiten beschädigen, so dass dies ein No-Go ist.

Das gleiche Problem tritt bei der Verwendung von beliebigen Attributnamen für private Zwecke auf. Aus diesem Grund schreibt HTML5 das Präfix "data-" für Attribute für den privaten Gebrauch vor, damit sie nicht mit neuen Attributen im Standard kollidieren.

Div und Span sind als semantisch neutrale Elemente definiert, dh Sie können sie für private Zwecke verwenden, ohne befürchten zu müssen, dass sich die Semantik in zukünftigen Browsern ändert. Sicher, es sind einige weitere Zeichen erforderlich, um einen Klassennamen hinzuzufügen, aber die Aufwärtskompatibilität macht es wert.


2

Ihr eigenes Beispiel zeigt eine Eigenschaft, warum Divs nicht so lächerlich sind.

<div class="hero-img">
  <img src="http://whatever.com/this.jpg">
</div>

Sie haben das imgTag nicht korrekt geschlossen . Einige Tags, wie img, br, hrund andere haben keinen Inhalt, und werden daher nicht geschlossen werden. Der Parser weiß das.

Das divTag hingegen soll geschlossen sein, da es Inhalt enthält. Wenn Sie nur Ihr eigenes Tag erstellt hätten, hätte der Parser keine Ahnung, ob er damit rechnen sollte, dass das Tag geschlossen wird oder nicht.

Der Grund, warum einige Elemente geschlossen werden sollen und andere nicht, stammt aus dem SGML-Erbe, das in diesem Blog-Beitrag gut beschrieben wird: http://www.colorglare.com/2014/02/03/to-close-or-not- to-close.html


2

Es ist eine Frage der Bestimmtheit. Wenn Sie XHTML verwenden, also reines XML, das vollständig definiert ist, können Sie Ihren eigenen Namespace verwenden, hier zum Beispiel über ein Präfix q::

<q:hero-img>
    <img src="http://whatever.com/this.jpg">
</q:hero-img>

Wenn Sie XML zur Konvertierung in (X) HTML verwenden würden, wäre es Ihnen völlig freigestellt, aus Ihrem kostenlosen HTML-Code "HTML" echtes HTML mit zu generieren <div class="hero-img">.


In einigen Tags ein Namespace-Attribut mit Ihrer eigenen (Dummy-) URL:

xmlns:q="http://..."

1
+1 für die einfache Lösung. Er muss nicht einmal ein Namespace-Präfix einfügen und kann einfach eine Standard-NS für das gesamte Dokument deklarieren und ein XSLT bereitstellen, um es in (X) HTML umzuwandeln.
DougM

1
XML-Namespace wird nicht durch das Präfix definiert, sondern durch den Wert der xmlns-Deklaration dieses Präfixes. qHierbei handelt es sich um ein völlig bedeutungsloses Präfix (und es handelt sich um ungültiges XML), es sei denn, Sie haben die XMLNS an einer beliebigen Stelle im Dokument deklariert. Sie können denselben Namespace auch mit anderen Präfixen neu deklarieren oder den Standardnamespace für einen bestimmten Abschnitt des Dokuments festlegen. Solange die xmlns-Werte gleich sind, werden diese unterschiedlichen Präfixe beim Anwenden von CSS oder im DOM gleich behandelt.
Lie Ryan

@LieRyan ein guter Punkt. Ich hätte es erwähnen sollen. Vorausgesetzt, die Tatsache war bekannt. Hinzugefügt
Joop Eggen

0

Eines der Schlüsselelemente von HTML ist das Vorhandensein vordefinierter Tag-Elemente. Deshalb.

Die div class = ist ein Weg, um diese "Einschränkung" zu umgehen.

Und deshalb sieht man diese "implizierten" Konstruktionen nicht.


Sagen Sie das all jenen Google-Entwicklern, die die neuen Webkomponentenspezifikationen definieren ... Ich verstehe, was Sie meinen, aber letztendlich wird es in den nächsten Jahren eine Explosion von Elementen geben, die von Entwicklern generiert werden. Meine Idee ist einfach benutzerfreundlicher. Punkt genommen, obwohl.
Jordan Davis

0

Der Zweck eines div-Elements ist allein die Struktur. Sie können Elemente unter einem gemeinsamen Element zusammenfassen. Es hat nichts mit Leerraum, Geschwindigkeit, Rendering, Semantik oder irgendetwas anderem zu tun. Es hilft Ihnen mit CSS in Bezug auf das Styling und Javascript in Bezug auf Selektoren. Wenn Sie es in ein anderes Element ändern, ändern Sie den Zweck.

Das Erstellen eines eigenen benannten Elements hat, wie Sie sehen, das Problem, dass Suchmaschinen und andere Tools nicht wissen, welche Bedeutung Ihre Elemente haben. Was ist ein "Helden-Bild" und wie unterscheidet es sich von meinem "Helden-Bild" und wie sollte meine API damit umgehen, wenn ich Ihre Seite besuche? Wie soll ein Browser mit diesem Element umgehen? Ist es Block Level oder Inline? Zu viele Fragen.


0

Im Allgemeinen sind div-Tags nützlich, um eine Unterteilung oder einen Abschnitt auf einer Webseite anzuwenden. Sie können ein div-Tag als Container verwenden, in dem andere Elemente angewendet werden können. Es hilft auch beim Anwenden von CSS und einigen Skripten auf ein bestimmtes Element.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.