Webkrauts Logo

Webkrauts Webkrauts Schriftzug

- für mehr Qualität im Web

Don’t use ids in selectors!? – Ein Web-Mythos

id vs. class

Don’t use ids in selectors!? – Ein Web-Mythos

Gelegentlich hört oder lest ihr die Empfehlung, doch bitte keine ids im CSS zu verwenden. Als Gründe werden die Wiederverwertbarkeit, Performance oder der schwierige Umgang mit der Spezifität genannt. Dabei kommt es nur darauf an, ids richtig zu verwenden!

Im Netz findet ihr diverse Artikel, die sich entschieden gegen den Gebrauch von ids in CSS wenden – teils mit harschen Worten, etwa:

Die wiederkehrenden Argumente lauten:

  • ids sind nicht wiederverwendbar
  • ids sind langsam
  • ids wirken so stark auf HTML-Elemente, dass ihr nur schwer entgegengewirkt könnt

Einsatz von id und class beim W3C

Grundlegende Informationen über den Einsatz von id- und class-Attributen findet ihr in den Spezifikationen des W3C:

Das id-Attribut kann für verschiedene Zwecke verwendet werden [...] und ist eine Möglichkeit, ein spezielles Element über CSS zu stylen
(frei übersetzt, W3C: the-id-attribute).

Werden einem Element class-Attribute hinzugefügt, wird darüber ein Bezug zum Selektor im CSS hergestellt
(frei übersetzt, W3C: classes).

Sprich: Die Spezifikationen des W3C sehen sowohl id- als auch class-Attribute für den Einsatz im CSS vor. Der Einsatz des class-Attributs ist vielen ausschließlich im Zusammenhang mit CSS vertraut, da class zumeist für nichts anderes verwendet wird. Aber ebenso wie ids sind Klassen nicht ausschließlich auf Layout/CSS beschränkt; class-Attribute können auch zu anderen Zwecken verwendet werden: zum Beispiel als eine "is-open"- und "is-closed"-class in einem Akkordeon – was an der Stelle als Darstellungsstatus verstanden werden kann und nicht als Style-Anweisung.

Die Spezifikationen sehen also beides vor. Und: Es wird keine Empfehlung darüber ausgesprochen, wann eine id und eine class einzusetzen sind. Auch ein Verbot der Verwendung von ids ist nicht zu finden.

CSS LINT – Der Ursprung des Mythos?

CSS LINT ist eine Webseite/ein Testtool, das CSS-Code überprüft. Dabei werden Fehlermeldungen, Warnungen und Hinweise ausgegeben, die für einen besseren Code dienen sollen. Einer der Hinweise lautet: »Don’t use ids in selectors.« Warum Webentwickler das nicht tun sollen, wird an dieser Stelle nicht erklärt.

Auf der About-Seite von CSS LINT ist dann die Erklärung zu finden: »ids shouldn’t be used in selectors because these rules are too tightly coupled with the HTML and have no possibility of reuse. It’s much preferred to use classes in selectors and then apply a class to an element in the page.«

Frei übersetzt: ids sollten nicht verwendet werden, da die Regeln zu eng ans HTML geknüpft sind und keine Möglichkeit der Wiederverwendung haben. Stattdessen ist deutlich zu bevorzugen, class-Attribute in Selektoren zu verwenden und die class dem HTML-Element hinzuzufügen.

ids sind nicht wieder verwendbar

Das in oben genannten Blogbeiträgen genannte Argument taucht hier wieder auf. Und diese Aussage ist verwirrend. Natürlich ist eine id nicht wiederverwendbar. Genau das ist das Wesen einer id, sie ist immer eindeutig. Das ist ihr Zweck, wie zum Beispiel als Anker für einen bestimmten Bereich einer Seite, um diesen mit einem Link anspringen zu können, oder als Verbindung zum for-Attribut eines Labels, wenn Webentwickler ein Label eindeutig mit einem Eingabefeld verknüpfen möchten.

Was aber genau ist jetzt das Kritische, wenn eine id im CSS nicht wiederverwendbar ist? Es drängt sich der Eindruck auf, dass es nicht um die böse id geht, sondern schlicht um falsch eingesetzte ids. Ein Quelltext wie der Folgende könnte zu diesem Schluss führen:

  1. <ul>
  2.   <li><a href="#" id="link-1">Link 1</a></li>
  3.   <li><a href="#" id="link-2">Link 2</a></li>
  4.   <li><a href="#" id="link-3">Link 2</a></li>
  5. </ul>

Um die Links über ids zu steuern, werden im CSS drei Regeln benötigt. In der Tat, hier greift das Argument, dass ids nicht wieder verwendbar sind. Der bessere Quelltext sähe sicher so aus:

  1. <ul>
  2.   <li><a href="#" class="link">Link 1</a></li>
  3.   <li><a href="#" class="link">Link 2</a></li>
  4.   <li><a href="#" class="link">Link 2</a></li>
  5. </ul>

Damit wäre für die Steuerung des Aussehens der Links nur noch eine CSS-Regel notwendig. Aber: Hier geht es nicht um böse oder gute ids, sondern um den zielgerichteten Einsatz dieses Attributs.

Der obige HTML-Code mag albern aussehen, ist jedoch so oder vergleichbar im HTML diverser Webseiten zu finden. Es stellt sich eher die Frage, ob jedem einzelnen Element eine Klasse zugewiesen oder eher die Klasse einem darüber liegenden Element hinzugefügt wird, um das HTML einfacher und übersichtlicher zu halten:

  1. <ul class="link-liste">
  2.   <li><a href="#">Link 1</a></li>
  3.   <li><a href="#">Link 2</a></li>
  4.   <li><a href="#">Link 3</a></li>
  5. </ul>

So können die Links über einen Kombinationsselektor gesteuert werden:

  1. .link-liste a {
  2.   color: red;
  3. }

Es geht in diesen Beispielen darum, wie effektiv oder elegant ein gut lesbarer und schlichter HTML-Code geschrieben werden kann und weicht von der eigentlichen Frage, warum keine ids verwendet werden sollen, ab. Also: zurück zum Thema ids.

ids haben eine unberechenbare Wirkung

Harry Roberts schreibt in seinem Artikel , dass der Einfluss einer id unberechenbar sei und man Kopfschmerzen bekomme, wenn die Anweisung einer id überschrieben werden soll. Er vergleicht ids sogar mit !important. Eine Aussage, die nicht haltbar ist.

Einen Blick auf sein jsfiddle-Beispiel erklärt, wie Roberts zu seiner Aussage kommt: Er setzt ids lediglich falsch ein; falsch wie in den Beispielen oben auf dieser Seite. Er verwendet ids als seien es class-Attribute und ist sich der unterschiedlichen Spezifität der verschiedenen Attribute nicht bewusst. (Oder genauer: Er wird das Beispiel absichtlich so gebaut haben, um es als Argument gegen ids zu nutzen.)

Das, was er als böse verpönt, ist genau das Gegenteil: Es ist die Kraft einer id, und eine sinnvoll eingesetzte id ist genau das, was CSS ausmacht. Folgende CSS-Regeln sind beispielhaft dafür, wie ids sinnvoll und zielgerichtet eingesetzt werden können:

  1. a {
  2.   color: red;
  3.   text-decoration: underline;
  4. }
  5. #footer a {
  6.   color: #999999;
  7. }

Diese zwei Regeln steuern das Aussehen von Links. Die erste Regel definiert die Farbe aller Links und fügt einen Unterstrich hinzu. Die zweite definiert die Linkfarbe für den Fuß der Webseite.

Das Argument einer nicht möglichen Wiederverwendbarkeit von ids greift hier nicht. Denn: Alle Webseiten haben nur einen Footer, und der Einsatz einer id für diesen ist legitim. Viele Webworker würden dies sogar als guten Stil bezeichnen.

Mit diesen CSS-Regeln wird die höhere Spezifität der id genutzt: Das #footer a stellt sicher, dass die Links im Seitenfuß grau sind. Er ist zwar ebenfalls möglich, dem Footer eine class="footer" zuzuweisen und dann über .footer a die CSS-Regel aufbauen – in dem Fall besteht jedoch die Gefahr, durch den Einsatz einer anderen class im Footer und einer anderen CSS-Regel genau diese Regel zu überschreiben. Mit einer id wird dies hingegen nicht passieren.

Die Diskussion um das Verbot von ids kann mit persönlichen Vorlieben erklärt werden. Einige empfinden die höhere Spezifität als Nachteil, andere als Vorteil. Besser als ids generell zu verbieten ist es, sich ihrer Spezifität zu widmen, um sie dann gezielt einzusetzen (Bestimmung der Spezifität). Diese Gewichtung bzw. Spezifität ist nichts Zufälliges, sondern ist explizit in den Spezifikationen des W3C vorgesehen. Das elegante Spielen mit Gewichtungen, um auch ohne !important auszukommen, ist das, was CSS ausmacht.

ids im CSS auszulassen ist, wie ein Auto ausschließlich im 1. Gang zu fahren, und das damit zu begründen, dass man im 4. Gang nicht anfahren kann.

ids sind langsam

Oli Studholme hat die Performance von ids und class-Attributen getestet und ist bei 1.000 Elementen zu einem Unterschied von 12.7 Millisekunden gekommen! Also dem Bruchteil einer Lidschlags. Auch wenn Studholme den Verzicht von ids befürwortet, trifft er in Bezug auf die Geschwindigkeit eine wichtige Aussage: »The performance difference between classes and ids is irrelevant.« (Der Geschwindigkeitsunterschied spielt keine Rolle)

JS und CSS-Dateien können minifiziert werden, Grafiken sollten immer fürs Web optimiert sein; im HTML-Code kann auf Kommentare verzichtet werden und es kann geprüft werden, ob wirklich alle JavaScript-Dateien benötigt werden, die beim Aufsetzen einer Webseite »einfach mal so« eingebunden werden, um eine Webseite und damit die Ladezeit zu optimieren. Jedoch für gerade einmal 12.7 Millisekunden Zeitersparnis ids zu verbieten (den 4. Gang im Auto zu verbieten) wäre absurd.

id-Verbot als Coding-Guidelines

Ein Verbot von ids kann weder mit dem W3C-Standard noch aus technischen Gesichtspunkten begründet werden. Allerdings kann sich ein Team darauf einigen, keine ids für das CSS zu verwenden. Coding-Guidelines haben eine Berechtigung und verbessern mit Sicherheit die Qualität von Quelltexten. Allerdings ist und bleibt es Geschmackssache, ob ids verwendet werden oder nicht. Aus technischer Sicht ist es genauso irrelevant wie beispielsweise, ob ihr bei CSS-Regeln die Klammern hinter oder in der Zeile nach dem Selektor schreibt.

Fazit

»Don’t use ids in selectors« ist ein Mythos der Webentwicklung. Auf ids im CSS zu verzichten ist nicht sinnvoll. Im Gegenteil. Wer auf ids verzichtet, der beraubt sich einer großartigen Möglichkeit, die CSS genauso vorgesehen hat und die CSS ausmacht.

Kommentare

Calvin
am 14.12.2014 - 11:15

Yep, that's true. Danke für den Artikel.

Permanenter Link

nk
am 14.12.2014 - 14:03

> Es drängt sich der Eindruck auf, dass es nicht um die böse id geht, sondern schlicht um falsch eingesetzte ids.
Mir drängt sich auf, dass der Autor die Aussage falsch verstanden hat.
> da die Regeln zu eng ans HTML geknüpft sind und keine Möglichkeit der Wiederverwendung haben.
die Regeln! Es geht also nicht um die Wiederverwendung der Id's, sondern um die des Markups. Folglich hat die Aussage auch nichts mit generischen Id's zu tun.

Genau um diese Klasse geht es. Stünde hier eine Id, wäre die gesamte Liste nur einmal einsetzbar und bei Mehrfachverwendung müsste CSS dupliziert werden.

Ich persönlich halte es so, dass ich Id's nur für sehr spezifische Seitenelemente einsetze. Grob kann man sich hier an den neuen HTML5 Elementen orientieren. Und selbst da stellt sich die Frage, ob nicht bspw. sinnvoll ist, Inhaltsbereiche wie Header für eine Doppelverwendung frei zu halten. Man denke an einen Sub-Content in der Seitenleiste, die Darstellung einer 2. Seite in einem div-Overlay und ähnliches. Einziges Problem: Je unspezfischer der "Identifier", desto länger werden CSS-Selektoren spezifischer Styles.

Permanenter Link

Gunnar Bittersmann
am 14.12.2014 - 23:09

…bei Mehrfachverwendung müsste CSS dupliziert werden.

Nein, muss nicht. Denn statt zu duplizieren

  1. #foo { /* haufenweise Deklarationen */ }
  2. #bar { /* nochmal dieselben Deklarationen */ }

kann man ja Selektoren aufzählen

  1. #foo, #bar { /* haufenweise Deklarationen */ }

Auf der From the Front dieses Jahr habe ich erzählt, wie man sich CSS-Präpozessoren dazu zunutze machen kann. Die Folien kann man sich ansehen; Video kommt erst noch.

Permanenter Link

Dirk
am 15.12.2014 - 11:43

Abgesehen von Spezifität: Nach deiner Aufzählung hat man allerdings Zeug an einer Stelle gesammelt, das man normalerweise fein säuberlich modular trennen würde.

Permanenter Link

Michael Gerstmann
am 15.12.2014 - 12:23

Danke für den Artikel. Schön das die böse Seite der Macht mal beleuchtet wird und aufgeräumt wird mit Vorurteilen. Dennoch bin auch ich kein Fan von id´s, die Beispielartikel zeigen auch auf warum.
@Gunnar Bittersmann zum Thema Aufzählung: #foo, #bar, diese Beispiel zeigt doch aber auf das hier eine dynamische Klasse weitaus mehr Sinn macht. Warum #foo, #bar, statt .foo-bar. Meiner Meinung nach eine der möglichen falschen Verwendungen einer ID.

Wir nutzen generell id´s nur für Javascript, das ist aber eine Reine Coding-Guideline aufgrund der potenziellen Fehlnutzung von IDs und dem Mehraufwand, diese im Nachgang zu korrigieren.

@Dirk "...Nach deiner Aufzählung hat man allerdings Zeug an einer Stelle gesammelt, das man normalerweise fein säuberlich modular trennen würde...." Sofern man die Module aufdröselt und diese erst beim deployen oder speichern kompiliert, hätte man trotzdem noch seine Modulare Trennung.

Permanenter Link

Gunnar Bittersmann
am 16.12.2014 - 00:02

Nicht, wenn man sich – wie gesagt – einen Präprozessor zunutze macht. Mit

  1. %quz { /* haufenweise Deklarationen */ }
  2. #foo { @extend %quz; }
  3. #bar { @extend %quz; }

hat man den Code modularisiert und trotzdem die Deklarationen nicht dupliziert.

Permanenter Link

Dirk
am 16.12.2014 - 12:12

Ja, damit wird es deutlich modularer. Allerdings halte ich @extend für ein vergleichsweise schwer verständliches Konzept — Komplexität ist zu vermeiden! —, das zudem sehr anfällig und wenig robust ist (Media queries, Verschachtelung, Reihenfolge der Sourcen, foobar).
Ich kann mir nur schwer vorstellen, warum man sich als Frontend-Dev freiwillig in eine solche Hölle begeben möchte, wenn es doch andere (bessere) Konzepte gibt.

Permanenter Link

Gunnar Bittersmann
am 18.12.2014 - 11:15

Hölle? Hölle!

Permanenter Link

Gunnar Bittersmann
am 20.12.2014 - 11:41

Allerdings halte ich @extend für ein vergleichsweise schwer verständliches Konzept

Hm, ich nicht. YMMV.

das zudem sehr anfällig und wenig robust ist (Media queries, Verschachtelung, Reihenfolge der Sourcen, foobar).

Ja, man kann leider Extends (noch?) nicht innerhalb von Media-Queries einsetzen. Da bin ich mal gespannt, was die Zukunft von Sass bringt. Gegenwärtig sieht meine Lösung dieses Problems so aus, wiederverwendbare Codeschnipsel so vorzusehen, dass sie sowohl als Mixin als auch als Extend eingesetzt werden können, wie auf Folie 83 gezeigt.

Permanenter Link
Stephan Heller

Stephan Heller (Autor)
am 15.12.2014 - 18:58

Hi Gunnar,

ja, das ist schon klar, dass man Selektoren kombinieren kann - mir lag es auf der Tastatur, aber ich wollte nicht über optimiertes CSS schreiben, sondern darüber, dass ids durchaus im CSS bzw. HTML verwendbar sind.

Zumindest scheinst Du ids nicht auszuschließen. Und mit class-Attributen kann man es dann noch etwas knapper halten (man stelle sich eine Liste mit 20 Einträgen vor, in der jeder Listenpunkt eine id hätte...). Hier wären ids sicher nicht angebracht.

Viele Grüße, Stephan

Permanenter Link

nk
am 14.12.2014 - 14:05

PS:

> Alle Webseiten haben nur einen Footer, und der Einsatz einer id für diesen ist legitim.

Genau. Und alle Postleitzahlen sind 5-stellig und alle Tage haben exakt 24 Stunden. :(

Permanenter Link

rusty
am 14.12.2014 - 14:58

Das wesentliche Kriterium für den Einsatz von IDs im Markup ist doch, ob es sich um ein absolut singuläres Element handelt, das niemals mehrfach innerhalb einer Seite verwendet wird.
Beispiel Formulare: Ich kann Kontakt-, Newsletter-, Feedback-, Bestell- , Login-Formulare etc. haben. Möglicherweise habe ich nur ein einziges Login-Formular. Wenn das klar ist, bekommt es eine ID. Die kann ich später nutzen, um abweichende Eigenschaften festzulegen, die nicht auf andere Formulare angewendet werden. Und zwar am besten nur diese abweichenden Eigenschaften.
Mit der ID wird also die Einzigartigkeit deutlich gekennzeichnet.

Permanenter Link
Stephan Heller

Stephan Heller (Autor)
am 15.12.2014 - 19:03

Hi Rusty,

Genauso sehe ich das! ids kann man in der Tat als »Schalter« verstehen, über die man dann das Feintuning macht - und gleichzeitig die hohe Spzifität nutzt. So würde ich es auch tun!

Viele Grüße, Stephan

Permanenter Link

Olaf Gleba
am 14.12.2014 - 16:50

Erstmal danke für den Artikel, der die wesentlichen Argumente gut zusammen fasst. Auch wenn ich die Aussage des Artikel nicht teile.

Weder die Tatsache, dass die Specs den Einsatz von IDs zum stylen nicht verbieten, noch die sonstigen Mythen mit den "aufgeräumt" wird (und letztlich nur darauf hinauslaufen, dass die Meinung vertreten wird, das IDs bei richtigen Einsatz maximal keine Nachteile haben), beantwortet nicht die Frage warum ich IDs zum Stylen einsetzen sollte, bzw. welche konkreten Vorteile dies gegenüber einer Klassenvergabe hat.

Er ist zwar ebenfalls möglich, dem Footer eine class="footer" zuzuweisen und dann über .footer a die CSS-Regel aufbauen – in dem Fall besteht jedoch die Gefahr, durch den Einsatz einer anderen class im Footer und einer anderen CSS-Regel genau diese Regel zu überschreiben. Mit einer id wird dies hingegen nicht passieren.

Wenn Klassen sich gegenseitig (ungewollt) überschreiben, ist das Konzept der Klassenvergabe schlicht falsch. Man löst dieses nicht, in dem man Elemente/Container (und die CSS Struktur) ihrer natürlichen Modularität beraubt (ID auf Elternelement setzen) sondern seinen konzeptionellen Ansatz überdenkt.

Die Grundhaltung in den zitierten Artikeln wird von ID-Befürwortung oft falsch gelesen. Es geht nicht um Dämonisierung von irgendetwas, sondern um pragmatisches Beurteilen der Vorteile/Nachteile will man wiederverwendbares Markup/CSS schreiben. Die höhere Spezifität von IDs dafür zu nutzen, aus Bequemlichkeit gekapseltes Insel-CSS zu schreiben, ist IMO kein wirklich überzeugendes Argument für den Einsatz von IDs.

Natürlich kann ich ein Bild mit Sekundenkleber (ID) an der Wand befestigen; fällt garantiert nicht ab bevor das Haus abgerissen wird. Mittel- und langfristig ist es allerdings von Vorteil, wenn ich die Bilder mit einer Methode befestige, die es erlaubt, die Bilder jederzeit neu arrangieren zu können, auszutauschen und/oder Halterungen frei zu lassen (Klassen). Ohne neu tapezieren zu müssen, ein Bild zu beschädigen oder eine gänzlich neue Mauer hochziehen zu müssen.

Permanenter Link
Stephan Heller

Stephan Heller (Autor)
am 15.12.2014 - 20:18

Hallo Olaf, vielen Dank für Dein Feedback.

Also, Vorteil einer id ist die höhere Spezifität! Wie oft sehe ich Kollegen, die mit class-Attributen nicht weiter kommen. Weil sich irgendwas irgendwie überschreibt. Ja, plane ich auf der grünen Wiese, kann ich ein sauberes Klassen-Konzept aufziehen. 80% der Projekte sind jedoch Bestandsprojekte, in denen CSS über Jahre gewachsen ist und unterschiedliche Strategien eingesetzt wurden. Mit id hat man eben einen guten Hebel, der legitim ist, aber nicht mit der Brechstange wie ein !important.

Ich bin mir nicht sicher, ob Du mich richtig verstehst. Ich möchte nicht alle class durch id ersetzen, sondern ids dort einsetzen, wo es keine Modularität gibt, wie:

  • #kopf
  • #inhalt
  • #fuss

Klar, für Wände sollte alles modular und neu arragnierbar sein. Da bin ich bei Dir. Aber einen Keller und ein Dachgeschoss wird wahrscheinlich immer seinen Platz behalten - warum muss man hier modular sein?

Du sprichst wie selbstverständlich von einem Klassen-Konzept. Wenn ich an CSS denke und an die Strukturierung von Styles, besteht das bei mir immer aus einem ID-Klassen-Konzept. Modular wo notwendig, festgelegt, wo Eindeutigkeiten vorhanden sind? Man kann sich entscheiden, nur Klassen zu verwenden. Ein eindeutiges, schlagkräftiges Argument gegen ids sehe ich allerdings in Deiner Antwort nicht. Wahrscheinlich kommt es auf den konzeptionellen Ansatz an, oder eben auf die Geschmacksfrage. Die Nachteile der ids sehe ich auf jeden Fall nicht (Natürlich vorrausgesetzt, man setzt id zielgerichtet ein).

Viele Grüße, Stephan

Permanenter Link

Dirk
am 15.12.2014 - 23:15

Ich bin mir nicht sicher, ob Du mich richtig verstehst. Ich möchte nicht alle class durch id ersetzen, sondern ids dort einsetzen, wo es keine Modularität gibt, wie:

#kopf
#inhalt
#fuss

Ich finde die Argumentation nicht schlüssig. Nur, weil ein Element nur einmal auf einer Seite vorkommt, darf/soll man eine ID verwenden? Warum nur? Es erhöht schlagartig sämtliche Spezifität, obwohl es per se keinen Grund dafür gibt.

Ich baue mal ein imaginäres Szenario: Statische Website mit allen Freiheiten, die wir wollen. Als Basis hat jemand Bootstrap eingebracht. Verschiedene Inhaltsmodule wurden danach möglichst global/unspezifisch gebaut. Ein Modul heißt Linkliste, und dessen Links sind rot, inline-block und mit kleinem Icon davor.

Sobald du dieses Modul in deinen #footer mit grauer Linkfarbe (Beispiel aus deinem Artikel) hängst, ist auch unsere Linkliste grau. Soll nun die Linkliste aber gefälligst rot bleiben, weil es nunmal eine Corporate-Heititi-rote-Linkliste ist, bist du von nun an gezwungen, mit schweren Geschützen zu schießen, nämlich mit IDs. Und zwar entweder an deinem Footer, oder an der Linkliste. Du implizierst also Kontext und schaffst Abhängigkeiten, brichst damit die vorher sauber abgesteckte Modularität auf und fängst an, ein komplexes Umfeld zu schaffen.

Weiter gesponnen: Leider machst du auch das ein oder andere Bootstrap-Element kaputt, das ebenso wie unsere Linkliste sehr lose angelegt wurde, nun aber in einem überspezifischen Kontext steht, der vielleicht nicht nur eine rote Linkfarbe, sondern auch einen Inline-Block-Kontext mitbringt. Inline-Block deshalb, weil der Entwickler vor dir nur eine Handvoll schlichter Links im Footer gesehen hatte, die stumpf nebeneinander stehen. Und jetzt wird es richtig unangenehm, denn du fängst an, externe Komponenten glattbügeln zu müssen. Und eine ehemals sauber abgetrennte Modulsammlung beginnt nun, an mehreren Stellen ineinanderzufließen.

Ich übertreibe jetzt, aber: Du steckst schlagartig in einem tiefen Spezifitätensumpf und fängst an zu schimpfen. Und warum? Zurecht. Weil die IDs vollkommen unnötig waren und es scheißegal ist, ob ein Footer nur 1x auf einer Seite vorkommt oder mehrfach.

Permanenter Link
Olaf Gleba

Olaf Gleba (Webkraut)
am 16.12.2014 - 12:15

1+ !
Permanenter Link

Gunnar Bittersmann
am 17.12.2014 - 18:52

Nur, weil ein Element nur einmal auf einer Seite vorkommt, darf/soll man eine ID verwenden?

Nein. Nicht, wenn ein der Bezeichnung entsprechendes Element nur einmal vorkommt, sondern wenn es nur einmal vorkommen kann.

Beispiel: eine Gruppe von Menschen, in der es genau einen Union-Fan gibt. „Union-Fan“ wäre dennoch eine Klassifizierung; es könnten ja auch noch weitere Union-Fans zu der Gruppe hinzukommen. Eine Identifizierung dieser Person wäre bspw. ihr (eindeutiger) Nutzername „unionfan12345“.

Irgendwann hatte ich dazu mal was geschrieben.

Es erhöht schlagartig sämtliche Spezifität, obwohl es per se keinen Grund dafür gibt.

Wenn die Spezifität wirklich ein Grund sein sollte: Man kann Elemente anhand ihrer ID auch mit dem Attributselektor [id="myID"] selektieren, der dieselbe Spezifität wie ein Klassenselektor hat. (Ein Klassenselektor .myClass ist aus CSS-Sicht ja auch nichts anderes als eine Kurzschreibweise für [class~="myClass"].)

Statische Website mit allen Freiheiten, die wir wollen. Als Basis hat jemand Bootstrap eingebracht.

Das ist ein Widerspruch in sich. Bootstrap ist ein Baukasten, der einem Freiheiten beraubt. (Oder wie der Erklärbär so schön sagte: „Bootstrap ist das Ikea der Webentwicklung.“) Wenn man die Freiheiten wiedererlangen wollte, müsste man gegen das Framework arbeiten; dann ist es aber unsinnig, Bootstrap überhaupt erst einzubinden.

Permanenter Link

Dirk
am 18.12.2014 - 09:30

Beispiel: eine Gruppe von Menschen, in der es genau einen Union-Fan gibt. „Union-Fan“ wäre dennoch eine Klassifizierung; es könnten ja auch noch weitere Union-Fans zu der Gruppe hinzukommen. Eine Identifizierung dieser Person wäre bspw. ihr (eindeutiger) Nutzername „unionfan12345“.

Ich verstehe, was du meinst, aber warum nur sollte man dies im Kontext von HTML und CSS tun: Union-Fans eindeutig aus der Masse hervorzuheben, um ihre Individualität zu unterstreichen? Alle sind doch vom selben Typ, sind rot-weiß angezogen und agieren als Gruppe. Und auch wenn ein einzelner Union-Fan nach dem Spiel alleine nach Hause läuft, muss man das doch nicht gleich überspezifizieren.

Konzepte wie BEM, SMACSS, OOCSS und Konsorten zielen auf Modularität/Wiederverwertbarkeit. In diesem Umfeld gibt es nichts, was ausschließlich einmal existiert. Alles kann potentiell immer auch mehrmals existieren. Und es kommt noch besser: Alle Module können potentiell andere Module beinhalten, die ebenso andere Module beinhalten können, die weitere Modu…

Menschen sind cognitiv nicht in der Lage, Spezifität und Vererbung über mehrere Ebenen sicher zu beherrschen. Sie verstehen das Prinzip, benötigen aber schon zu einem sehr frühen Zeitpunkt Hilfsmittel, um zu validieren, was sie tun.
Konzepte, die dabei helfen, Spezifität und Vererbung möglichst gering zu halten, können deshalb ungemein nützlich sein, denn sie verringern die Komplexität.

IDs — und darum ging es hier mal? — brechen diese Konzepte auf.

Man kann Elemente anhand ihrer ID auch mit dem Attributselektor [id="myID"] selektieren

Nette Idee, wäre ich nicht drauf gekommen. Allerdings irgendwie auch hässlich, nicht?

Bootstrap ist ein Baukasten, der einem Freiheiten beraubt. (Oder wie der Erklärbär so schön sagte: „Bootstrap ist das Ikea der Webentwicklung.“)

Whatever.

Permanenter Link

Gunnar Bittersmann
am 18.12.2014 - 11:35

Ich verstehe, was du meinst, aber warum nur sollte man dies im Kontext von HTML und CSS tun: Union-Fans eindeutig aus der Masse hervorzuheben, um ihre Individualität zu unterstreichen? Alle sind doch vom selben Typ, sind rot-weiß angezogen und agieren als Gruppe. Und auch wenn ein einzelner Union-Fan nach dem Spiel alleine nach Hause läuft, muss man das doch nicht gleich überspezifizieren.

Wenn du genau diesem einzelnen einen rot-weißen Schal umhängen willst, kann es durchaus sinnvoller sein, dies per

<div class="unionfan" id="unionfan12345">
und #unionfan12345 { schal: rot-weiß }

zu tun als per

<div class="unionfan unionfan--deralleinenachhauseläuft">
und .unionfan--deralleinenachhauseläuft { schal: rot-weiß }

Man kann Elemente anhand ihrer ID auch mit dem Attributselektor [id="myID"] selektieren

Nette Idee, wäre ich nicht drauf gekommen. Allerdings irgendwie auch hässlich, nicht?

Warum hässlich? Und die Schönheit liegt sowieso im Auge des Betrachters.

Permanenter Link

Dirk
am 18.12.2014 - 19:57

Wenn du genau diesem einzelnen einen rot-weißen Schal umhängen willst, kann es durchaus sinnvoller sein, […ID verwenden…]

Ich habe eine andere Sicht als du: Nein, es ist genau niemals sinnvoller, eine ID zu verwenden. Denn aus deinem einzigartigen Element könnten zu einem späteren Zeitpunkt mehrere werden, und der CSS-Kontext, den du dir dafür angelegt hast, ist unnötig spezifisch, weniger modular und komplexer als er sein müsste.

Du hast den BEM-Weg aufgezeigt. Ich kenne aktuell keinen besseren.

Permanenter Link

Gunnar Bittersmann
am 23.12.2014 - 01:33

Denn aus deinem einzigartigen Element könnten zu einem späteren Zeitpunkt mehrere werden

Der einzigartige „unionfan12345“ bleibt immer einzigartig; das ist das Wesen einer ID.

Aus dem einen, der einen Schal trägt, können mehrere werden. Die könnten aufgezählt werden: #unionfan12345, #unionfan56789, …

Die könnten aber auch klassifiziert werden. Und das wohl sinnvollerweise nicht als „unionfan--mitschal“, sondern als „mitschal“, denn es mag auch Hertha-Fans mit Schal geben, die auch dieser Klasse angehören (aber natürlich nicht der Klasse „unionfan“).
Im HTML:

  1. <div class="unionfan"></div>
  2. <div class="unionfan mitschal"></div>
  3. <div class="herthafan mitschal"></div>

Im CSS:
  1. .unionfan {}
  2. .unionfan.mitschal {}
  3. .herthafan {}
  4. .herthafan.mitschal {}

Permanenter Link

Dirk
am 23.12.2014 - 12:20

Der einzigartige „unionfan12345“ bleibt immer einzigartig; das ist das Wesen einer ID.

In der Theorie. In der Praxis entsteht Bedarf für einen weiteren dieser einzigartigen Union-Fans, und dann werden Klassen verwendet. Ein sinnvolles Konzept hätte sowas vorhergesehen.

Anders: Deine Annahme, ein Element oder eine Elementgruppe sei einzigartig, steht jederzeit auf wackligen Beinen. Es gibt weder eine technische Beschränkung, mehrere gleiche IDs zu verhindern (Java-Entwickler klonen und modularisieren dein HTML schneller als du zucken kannst), noch konzeptionelle, wirtschaftliche oder sonstige Einwände dagegen. Irgendetwas oder irgendjemand lässt Bedarf entstehen, dein ID-Element mehrfach zu benutzen, und dann passiert es so.

Permanenter Link
Olaf Gleba

Olaf Gleba (Webkraut)
am 16.12.2014 - 12:13

Moin Stephan,

es ist, wie du sagst, einfach Geschmacksache, eine Frage des konzeptionellen Ansatzes und Art des Projektes (Frischling oder Bestandsprojekt). Mir geht es generell nicht um ein Gut/Böse, sondern eher um die Zwischentöne. Falls das anders rübergekommen ist, sorry ;-)

[...] Ich möchte nicht alle class durch id ersetzen, sondern ids dort einsetzen, wo es keine Modularität gibt, wie #kopf, #inhalt, #fuss

Modularität kann für mich auch in diesen einmaligen/statischen Bereichen stattfinden, bzw. diese Bereiche beinhalten oft verschiedene modulare Elemente, die seitenübergreifend eingesetzt werden. Bspw. Listen (Navigation etc.) sind bei mir i.d.R. modulare Objekte, die bereichsunabhängig funktionieren sollen. Deren ggf. unterschiedliches Aussehen ich über Modifier auf der Objektebene beeinflusse, um im CSS in Objektnähe zu arbeiten. Ich vermeide u.a. dadurch, dass an ggf. einer Vielzahl an Positionen im Stylesheet das Styling eines Element verändert wird (ausgehend davon, dass sowas wie #kopf ul.nav an anderer Stelle wie bspw. #fuss ul.nav steht). Einfach eine Frage der persönlichen Vorliebe ;-)

Ein eindeutiges, schlagkräftiges Argument gegen ids sehe ich allerdings in Deiner Antwort nicht

Konnte man durchaus so lesen,- mir geht aber nicht darum IDs zu verteufeln (wie du sagst, oft hat man kaum eine Wahl), sondern um die Frage, ob es für mich Sinn macht, sie zu nutzen (wenn ich frei entscheiden kann, bzw. die Kontrolle habe). Ich ziehe keine Vorteile aus der höheren Spezifität einer ID in meiner Art CSS zu schreiben, bzw. bewerte die Nachteile als deutlich höher.

gruss in die Innenstadt
Olaf

Permanenter Link

Karsten
am 14.12.2014 - 19:28

Ist es guter Stil HTML-Elemente (wo möglich) direkt im externen CSS-Stylesheet zu formatieren.

Bspws:

Anstelle: < footer class="footer" > einfach < footer >bla bla bla< /footer >

und dann im CSS:

footer {
....
}

Kann man das so machen bei HTML-Elementen bei denen es sich anbietet oder ist das verpönt?

Und was ist da dann der Unterschied zu IDs?

Permanenter Link

Olaf Gleba
am 15.12.2014 - 00:27

Es ist nicht verpönt (guter Stil ebenfalls nicht), aber du beraubst dich der Möglichkeit das HTML-Element footer mehrfach einzusetzen (mit der Unterstellung, dass sich die Formatierung jeweils unterscheiden würde). Insofern gibt es eine Ähnlichkeit zu IDs. Zumindest, was in dem was es bewirkt.

Permanenter Link

Sven
am 15.12.2014 - 15:56

Und ich war schon irritiert...

  1. <!DOCTYPE html>
  2. <html>
  3. <head><title>Kleiner Test</title></head>
  4. <body>
  5. <header>Meine Webseite hat einen Kopf</header>
  6.  
  7. <article>
  8.   <header>Mein Inhalt ist kopflastig</header>
  9.   <section>Mein Inhalt ist ein Abschnitt</section>
  10.   <footer>Mein Inhalt riecht nach Käse</footer>
  11. </article>
  12.  
  13. <footer>Meine Webseite hat einen Rumpf</footer>
  14. </body>
  15. </html>

ist absolut valide und benutzt header und footer gleich mehrfach.

da könnte man auch mit

  1. footer {
  2.    ... hier könnte deine Werbung stehen
  3. }
  4.  
  5. article footer {
  6.    ... hier könnte deine Werbung stehen
  7. }

formatiert werden, aber ich würde dann wohl auch eher dieses Gerüst bevorzugen:

  1. <!DOCTYPE html>
  2. <html>
  3. <head><title>Kleiner Test</title></head>
  4. <body>
  5. <header id="Header oder slogan oder banner oder logo">Meine Webseite hat einen Kopf</header>
  6.  
  7. <article id="content">
  8.   <header>Mein Inhalt ist kopflastig</header>
  9.   <section>Mein Inhalt ist ein Abschnitt</section>
  10.   <footer>Mein Inhalt riecht nach Käse</footer>
  11. </article>
  12.  
  13. <footer id="footer oder copyright oder ... ">Meine Webseite hat einen Rumpf</footer>
  14. </body>
  15. </html>

Permanenter Link

Ben
am 15.12.2014 - 18:18

Das erste HTML-Beispiel ist viel besser als das zweite (auch wenn die Invalidität des zweiten einzig an den „Dummy“-IDs liegt), weil es kürzer ist. Wozu IDs erfinden, wenn man sie nicht benötigt? (Benötigen würdest du sie nur, wenn du den header oder den article eigens verlinken und mit eigener URL versehen willst: …/foo.html#Header%20oder%20slogan%20oder%20banner%20oder%20logo.) Und wenn man Phantomschmerzen hat, ist ein <header role=…> immer noch (semantisch) aussagekräftiger, als wenn man eine ID oder class erfindet. – Also: Bevorzuge bitte mal das erste „Gerüst“ und nicht das zweite. Denn das erste ist 100 % HTML-Standard pur, das zweite enthält Schnickschnack.

Permanenter Link

Ben
am 15.12.2014 - 17:59

Klare Antwort: Es ist guter Stil, und zwar weil du weniger HTML und weniger CSS schreibst. Wenn du footer-Elemente in unterschiedlichen Kontexten unterschiedlich gestalten willst, ist ebenfalls eine Selektion via Kontext vorzugswürdig gegenüber zusätzlich eingefügten @class-Attributen. Du könntest zum Beispiel von vornherein body>footer anders als article footer gestalten; oder an ein ohnehin vorhandenes Attribut anknüpfen, zum Beispiel: footer:not([role="contentinfo"]) versus footer[role="contentinfo"]. – Jedenfalls: <footer class="footer"> im HTML und footer.footer {…} im CSS zu schreiben ist so „sinnvoll“ wie <p class="p"> und p.p {…} zu schreiben … – Und zu den weiteren Fragen: Es bietet sich bei allen Elementen an; je simpler [dein Markup und dein CSS sind], desto besser [sind sie; desto übersichtlicher, weniger fehleranfällig, leichter wartbar usw.]. – ID’s haben damit nichts zu tun. Nur wer noch nicht auf HTML 5 umsteigt/umsteigen kann, behilft sich mit Krücken wie <div id="footer"> oder <div class="footer">, weil das Element <footer> in HTML 4/XHTML 1 invalide (ungültig) wäre. Ansonsten haben die beiden Themen miteinander nicht zu tun.

Permanenter Link

Dirk
am 15.12.2014 - 19:05

Ich vertrete hier mal die Gegenhaltung: Es ist absolut kein guter Stil, Elemente generisch anhand ihres Kontextes zu stylen. Zwei Hauptgründe:

1) Der Kontext ist längst nicht so robust wie eine eindeutige Referenz (Klasse oder ID). Banales Beispiel: JavaScript-Komponenten, die dein DOM umbauen, oder ein CMS, das eigene Hilfselemente zum Inline-Editing einbringt (Drupal, TYPO3 Neos…), kann in diesem Setup reichlich Chaos verursachen. Und selbst kleinste Anpassungen an der HTML-Struktur müssen meist in den Styles nachgezogen werden.

2) Styles über Kontexte zu bauen ergibt längere und spezifischere Selektoren, als wenn unmittelbare Referenzen verwendet werden. Spezifität ist zu vermeiden, wenn man die Absicht hat, besonders modular und generisch arbeiten zu wollen. Denn Spezifität kann nur mit mehr Spezifität behandelt werden. Vererbung und Spezifität neigen jedoch dazu, Kontexte im Laufe der Zeit/Entwicklung immer komplexer zu machen.

Robustes CSS besteht für mich aus eindeutigen Referenzen für jedes einzelne Element. Und bei der Gelegenheit nochmal: Klassen eignen sich fast immer besser als IDs, weil sie Spezifität verringern und per se modularer sind.
Damit bleiben Styles sehr unspezifisch auf ganz unterer Ebene und produzieren sehr wartbare Module und Kontexte.
--> BEM.

Permanenter Link

Ben
am 15.12.2014 - 19:42

Okay, sehr gute Antwort, das lässt sich alles sehr gut hören. Wahrscheinlich trennen uns beide einfach Welten in der Arbeitsweise: Ich kann mir den grandiosen Luxus leisten, so ziemlich alles von Hand zu schreiben, das ganze JS, alles; wenn ich „CMS“ höre, werde ich schon misstrauisch. Eventuell bin ich da von eher abwegigen Voraussetzungen ausgegangen … Trotzdem ein wenig Detail-Kritik:

Der Kontext ist längst nicht so robust wie […]

Na ja, der Kontext ist so robust, wie ich ihn beherrsche …

[…] kleinste Anpassungen an der HTML-Struktur müssen meist in den Styles nachgezogen werden […]

Definitiv. HTML ist Koch, CSS ist Kellner!

[…] Styles über Kontexte zu bauen ergibt längere und spezifischere Selektoren […]

Stimmt. Aber da liegt meine Hoffnung auf dem any()-Pseudo-Element (oder Pseudo-Class? was weiß ich); das kommt!; „läuft“. Dann kriegst du ne ganze Handvoll mit einem Fingerzeig.
Mein Ansatz ist einfach: das HTML so strikt, klar, pur wie auch nur irgend möglich; CSS wird in seiner Flexibilität und seinen Möglichkeiten schon nachzuckeln; und für die ein oder andere Formatierung kann man sich ja temporär vielleicht auch mit Klassen- (oder sonstiger Attribut-)Zuweisung mittels JavaScript behelfen. Hauptsache, pures, blankes HTML, denn da ist der Inhalt, und das sollte man mit nichts zumüllen. Bin da halt Radikal-Purist … Und drum:

[…] eindeutige[n] Referenzen für jedes einzelne Element […]

Ja, sie sind ja eindeutig. Däs is ja däs. Du brauchst keinen Attribut-Müll, um sie eindeutig zu kriegen. Statt dir dein HTML mit immergleichen @classes usw. zuzumüllen, musst du dann halt im Gegenzug öfter an dein CSS ran. Aber so erscheint es mir richtiger: HTML ist Koch, CSS ist Kellner. Oder?

Permanenter Link

Dirk
am 15.12.2014 - 23:42

Natürlich kann man problemlos, effizient und sehr erfolgreich so arbeiten, wie du es zuvor beschrieben hast: Indem man sein HTML ausschließlich selbst erstellt und es hütet wie ein kleines Kätzchen. Aber das Ding ist doch: Man will oder kann nicht immer alleine an einer Website arbeiten, sondern irgendwann hat man auch mal eine Band um sich rum. Und wenn im Multiplayer-Modus die Konzepte nicht mehr funktionieren, an die man sich gehalten hat, als man noch alleine war, ist das doch ziemlich kacke.

Ich finde, als Webentwickler sollte man immer auch das Ziel haben, im Team zu funktionieren. Du übst ja auch nicht jahrelang auf deiner Gitarre, ohne damit zu liebäugeln, das Zeug irgendwann mal live und mit Band zu spielen.

Dein Konzept, Elemente in ihrem Kontext zu stylen, ist nun also sehr anfällig und wenig robust. Im Multiplayer-Survival-Modus zumindest. Und deshalb würde ich nicht daran festhalten, auch wenn es aktuell in deinem Singleplayer-Modus funktioniert.

Ja, sie sind ja eindeutig. Däs is ja däs. Du brauchst keinen Attribut-Müll, um sie eindeutig zu kriegen. Statt dir dein HTML mit immergleichen @classes usw. zuzumüllen, musst du dann halt im Gegenzug öfter an dein CSS ran. Aber so erscheint es mir richtiger: HTML ist Koch, CSS ist Kellner. Oder?

Sie sind nur in ihrem Kontext eindeutig. Und damit auch per se nicht in anderen Kontexten wiederverwertbar. Letzteres ist das, was Modularität ausmacht, und was eines der Ziele ist, die es für gewöhnlich zu erreichen gilt.

Um das nochmal klarzustellen: Ich will dir gar nichts ausreden oder madig machen. Ich habe nur gelernt, dass es auf die Art nicht für alle funktioniert. Und deswegen würde ich so nicht arbeiten wollen, sondern lieber nach Konzepten suchen, die es darauf anlegen, im Team und in wechselnden Umgebungen zu funktionieren.

Permanenter Link

Gunnar Bittersmann
am 20.12.2014 - 11:52

Aber das Ding ist doch: Man will oder kann nicht immer alleine an einer Website arbeiten, sondern irgendwann hat man auch mal eine Band um sich rum. Und wenn im Multiplayer-Modus die Konzepte nicht mehr funktionieren, an die man sich gehalten hat, als man noch alleine war, ist das doch ziemlich kacke.

Ein durchaus wichtiger Aspekt, den man nicht vernachlässigen darf.

Allerdings ist es auch Kacke, wenn – um bei deinem Bild zu bleiben – die Band immer nur Marschmusik spielen kann, weil einer in der Band außer 4/4-Takt nichts auf die Reihe kriegt, und da auch 1 und 3 betont und nicht etwa 2 und 4 wie im Swing und im Rock and Roll, von Synkopen oder gar 5/4-Takt ganz zu schweigen.

Permanenter Link

Dirk
am 20.12.2014 - 17:09

Allerdings ist es auch Kacke, wenn – um bei deinem Bild zu bleiben – die Band immer nur Marschmusik spielen kann, weil einer in der Band außer 4/4-Takt nichts auf die Reihe kriegt, und da auch 1 und 3 betont und nicht etwa 2 und 4 wie im Swing und im Rock and Roll, von Synkopen oder gar 5/4-Takt ganz zu schweigen.

Genau. Nun ist die Methodik von CSS allerdings nicht sonderlich kompliziert und damit sehr einfach zu erlernen. Deshalb fehlt es der besagten Band vermutlich nicht unbedingt an Vielseitigkeit und Ausdrucksform, sondern sie läuft vielmehr in Gefahr, dass die beteiligten Musiker kein gemeinsames Konzept (sic!) verfolgen und deshalb klingen wie Guns N'Roses auf Chinese Democracy.

Permanenter Link

Gunnar Bittersmann
am 18.12.2014 - 11:12

Nur wer noch nicht auf HTML 5 umsteigt/umsteigen kann,

Den Fall „nicht umsteigen kann“ gibt es nicht.

Permanenter Link
Stephan Heller

Stephan Heller (Autor)
am 15.12.2014 - 20:31

Hallo Karsten,

Du unterstellst mir subil ;-) dass ich die class="footer" an ein HTML5-Footer-Element packe - das ist so nicht im Beitrag zu finden. Im Kopf hatte ich eher ein DIV. Diese Doppelung macht natürlich keinen Sinn (wobei ich das auch in bestimmt 1/3 aller Projekte sehe).

Wenn man Struktur-Elemente hat, sollte man die auch für die Selektoren verwenden. Im Artikel gehts aber um ein vermeintliches Verbot von ids.
Mea Culpa, leider ein schlechtes Bespiel von mir. Ein #login-form input hätte sicher nicht solche Schlüsse ermöglicht.

Achso, der Unterschied zu einer ID ist massiv. Ein Element-Selektor footer hat noch eine geringer Spezifität als ein Klassenselektor .footer, eine id #footer die höchste von diesen dreien. Den Style über footer zu steuern, ist aus meiner Sicht nicht verpönt, sondern elegant. Stellt sich nur die Frage, wie viele Footer man auf der Seite hat (Seitenfuss an sich, aber auch Footer in Article usw.). Hier könnte der Element-Selektor nicht ausreichend sein, um Unterschiede zwischen unterschiedlichen Footern zu machen.

Viele Grüße, Stephan

Permanenter Link

Mike
am 14.12.2014 - 23:46

Wer Harry Roberts Ansätze und Konzepte auf die im Artikel genannten (und aus dem komplexen Gesamtzusammenhang gerissenen) Aussagen reduziert, hat entweder nicht verstanden was er meint, oder sich schlicht nicht weit genug in die Thematik vertieft.

Permanenter Link

Nikolai
am 15.12.2014 - 09:44

[…] Um die Links über ids zu steuern, werden im CSS drei Regeln benötigt. […]

Nein, nicht mehr: Mit [id^="link-"] kann man alle drei Links aus dem Beispiel gestalten.

Im Übrigen finde ich: Man setzt ein @id, um ein Element „anspringbar“ zu machen und um es verlinken zu können (Beispiel: Abschnitte eines Wikipedia-Artikels). Wenn es daher nun einmal bereits ein @id trägt, stört es den Puristen in mir, dann auch noch ein @class setzen zu müssen; man kann und darf (siehe Artikel) anhand des @id gestalten, und man lässt den Quelltext so kurz wie möglich. (Was aber voraussetzt, dass die @id-Attributwerte „berechenbar“ sind, Gegenbeispiel: Wikipedia-Artikel …).

Permanenter Link

Gunnar Bittersmann
am 18.12.2014 - 11:07

Mit [id^="link-"] kann man alle drei Links aus dem Beispiel gestalten.

Mit [id|="link"] auch – und das auch für ältere Browser.

Permanenter Link

Dirk
am 15.12.2014 - 11:08

Wer besonders spezifisch werden möchte, soll gerne IDs verwenden. Viele Konzepte (etwa BEM) sehen jedoch vor, so unspezifisch wie möglich zu bleiben. Wer diese Konzepte verfolgt, will keine IDs benutzen.
— Ganz einfach und banal, ohne jeglichen Mythos.

Permanenter Link

wortwart
am 15.12.2014 - 15:25

Don't use CSS Lint ...

Ich werde den Eindruck nicht los, dass manche Webdesigner vor allem deshalb auf class schwören, weil sie Spezifität und komplexe Selektoren nicht recht verstehen und weil class so schön presentational ist. Ansonsten halte ich es für eine Geschmacksfrage - mich persönlich stört es, wenn im HTML zu viel Zeug steht, das mit der Dokumentenstruktur nichts zu tun hat.

Permanenter Link
Stephan Heller

Stephan Heller (Autor)
am 15.12.2014 - 20:58

Hallo Wortwart, da teile ich Deinen Eindruck. Spezifität ist nichts einfaches. Und wie geschrieben, was viele als Pest der ids bewerten, sehe ich eben als wertvolles Mittel, gegen das man sich entscheiden kann, ich mir diesen Hebel aber nicht »verbieten« lassen möchte (zumeist wird es oft einfach nur verboten, ohne es auf ein bestimmtes Konzept zu stüzten - dann nämlich fände ich es OK).

Und Du hast recht. Wenn man es sorgfältig macht, kommt man im HTML mit ein paar ids und einer Handvoll Klassen aus, um das CSS zu bauen.

Viele Grüße, Stephan

Permanenter Link
Stephan Heller

Stephan Heller (Autor)
am 15.12.2014 - 21:17

...na, um noch einen ganz anderen Blickwinkel zu schaffen: jQuery empfielt sogar explizit, ids zu verwenden, da diese wesentlich performanter sind.
Stellt sich die Frage: Wenn die ids schon da sind, warum die nichts für's CSS zu verwenden. Und warum nicht die gleichen Selektoren im CSS anwenden, die man auch im JS einsetzt?

Permanenter Link

Dirk
am 16.12.2014 - 00:08

Sorry, dass ich auch hier nochmal einhake, aber du stellst die Frage so verdammt provokant :) Und warum soll immer nur Gunnar hier die QS machen?

Die Empfehlung, Elemente per ID zu selektieren, ist ja inzwischen auch ein bisschen nachgereift und stammt aus einer Zeit, als der Performanceunterschied gegenüber der Klassenselektion noch merklich war. Inzwischen kann man viel besser über data-Attribute selektieren, spart sich sowohl IDs als auch Klassen und sorgt für eine schärfere Trennung.

JavaScript muss also auch nicht zwangsläufig der Grund für die Verwendung von IDs sein.

Permanenter Link

wqdqwddqw
am 19.12.2014 - 10:34

IDs in JS haben mal so gar nichts mit Ids in CSS zu tun. Selbst der größte ID-Ablehner wird zustimmen, dass als JS-Hooks Klassen sehr geeignet sind aufgrund der Geschwindigkeit.

Permanenter Link

Karsten
am 16.12.2014 - 11:37

Hallo Ben,
du hast geschrieben:

Mein Ansatz ist einfach: das HTML so strikt, klar, pur wie auch nur irgend möglich; CSS wird in seiner Flexibilität und seinen Möglichkeiten schon nachzuckeln; und für die ein oder andere Formatierung kann man sich ja temporär vielleicht auch mit Klassen- (oder sonstiger Attribut-)Zuweisung mittels JavaScript behelfen. Hauptsache, pures, blankes HTML, denn da ist der Inhalt, und das sollte man mit nichts zumüllen. Bin da halt Radikal-Purist

so sehe ich das auch und möchte auch so verfahren.

Aber was machst Du bspw. mit einem Element? Einmal möchte man das Bild hierhin floaten, einmal soll es dort sein. Dann wieder diese Umrandung haben oder jene...? Kommst Du hier ohne img class"..." weiter?

Die gleiche Frage zu "p"

Also wie verfährst DU mit diesen "Allerweltselementen" die man eben doch sehr oft unterschiedlich in der eigenen Webseite verwenden will evtl.?

Permanenter Link

Antonia
am 18.12.2014 - 12:54

Wir haben uns im Team von der Verwendung des id-Selektors verabschiedet. Insbesondere im Zusammenhang von Preprozessoren und vielen Beteiligten am Code, führte ein id-Selektor schnell zur Verbreitung und sie tauchten wie Tribbles überall im Code auf, um das ursprüngliche CSS zu überschreiben. Dies ist dabei jedoch keine Abwertung des id-Selektors, sondern den Eigenarten der Entwickler geschuldet, die sich nicht trauen bestehenden Code anzufassen, da die Ausmaße auf das Projekt nicht absehbar waren. Mit dem Attribut-Selektor für IDs arbeiten wir sehr gut und auch bei großen Projekten hat das Fehlen des ID-Selektors noch keine Auswirkungen gehabt und wir sind Tribbel-frei. :-)

Permanenter Link
Stephan Heller

Stephan Heller (Autor)
am 21.12.2014 - 15:44

Wow
Uns war ja im Vorfeld klar, dass der Beitrag polarisiert und sicher auch Feedbacks kommen werden. Aber mit so vielen Kommentaren hab ich nicht gerechnet.

Was ist jetzt draus zu schließen?

Wir haben gelernt, dass man diverse Möglichkeiten hat, das HTML anzusprechen. Neben class und id kamen hier Attribut-Selektoren zur Sprache, auch über die HTML-Elemente ist das CSS aufzubauen. Das ist gut anzusprechen. Was technisch möglich ist, was wer als elegant bewertet, ist spannend. Nichts davon ist ein schlagendes Argument gegen IDs. Schlagend im Sinne von: Das ist falsch. IDs mögen unschön sein, unelegant, zu wenig modular, zu spezifisch sein (wobei letzteres ein Feature von CSS ist und kein Bug).

Hier treffen Puristen auf Modularisten. Und jeder hat sein Setting im Kopf - der eine hat sein HTML zu 100% im Griff - dann kann ich mein CSS anhand meiner HTML-Struktur aufbauen. Umso größer Projekte sind und umso weniger man Änderungen im HTML beeinflussen kann bzw. überhaupt mitbekommt, umso schwieriger wird es, ein puristisches HTML und ein elegantes CSS aufzubauen.

Hinzu kommen Prä-Prozessoren, das Arbeiten im Team, verschiedene Konzepte, die mal mit, mal ohne IDs auskommen. Macht die ganze Geschichte zu einer ziemlich komplexen Sache.

Klar ist, dass beim Verzicht auf IDs die Probleme, die durch IDs entstehen können, erst gar nicht auftreten. Und auch Einsteiger, die die Eigenschaften von IDs und class noch nicht in Gänze verinnerlicht habe, auch durch ein ID-Verbot vorm Fehler-Machen geschützt sind.

Ich selber halte mich für einen puristischen Pragmatiker. Ich halte es schwer aus, wenn pro HTML-Element 10 Klassen vergeben sind. Und Selektoren? Was technisch geht, steht bei mir auf der einen Seite. Gerade bei kleinen Projekte, die man einmal aufbaut und dann nie wieder anpackt, wo auch oft Kunden mit geringem Budget hinter stehen, würde ich schätzen, dass man mit einem ID gestützten Grundaufbau der Seite schneller ans Ziel kommt. Gut, hängt eben auch davon ab, wie jeder persönlich bei seiner täglichen Arbeit arbeitet.

Wie auch immer. Vielen Dank für die vielen Kommentare und die hitzige Diskussion.
Allen ein frohes Fest.

Permanenter Link

Die Kommentare sind geschlossen.