CSS-Regeln und ihr Gewicht

Freunde, Bekannte, Kollegen rufen mich gerne mal zu sich an den Arbeitsplatz, präsentieren einen Schnipsel aus einem CSS und schauen mich dann mit einem großen Fragezeichen im Gesicht an und die Frage lautet: »Warum wird das nicht so dargestellt, wie ich das will?« Mal davon ausgegangen, das HTML– und CSS-Code formal richtig sind, kann es ja schon einmal passieren, dass die eine CSS-Regel die andere überschreibt. Nach welchem Muster dies geschieht, das ist leider Gottes für so manchen der an CSS herumschraubt ein böhmisches Dorf, obwohl ich mir fast sicher bin, dass selbst in »CSS für Dummies« etwas darüber gesagt wurde.

OK, wir wollen ja nicht dumm sterben, deswegen hier nochmal die goldenen Regeln der Spezifität von CSS-Selektoren. Und das geht so: je nach ihrer Spezialität sind CSS-Selektoren von unterschiedlichem Wert oder Gewicht. Ein Beispiel:

[syntax,specificity1.html,html]

Ein passendes CSS dazu könnte so aussehen:

[syntax,specificity1.css,css]

Preisfrage: ist »Hier steht Text« nun grün oder rot? Antwort: rot. Denn #number1 .red p wiegt schwerer als #number1 p. Anders sieht es aus, würde folgendes CSS benutzt:

[syntax,specificity2.css,css]

Nun wird der Text grün gerendert. Das ist kein Hexenwerk, sondern beruht auf einer einigermassen einfachen Berechnung. Je nachdem wie oft ein CSS-Selektor mit IDs, mit Klassen oder mit HTML-Tags ausgezeichnet ist, werden ihm unterschiedliche Werte zugeschrieben. IDs zählen dabei 100, Klassen 10 und HTML-Tags 1, jeweils multipliziert mit der Anzahl des Auftretens. Die obigen Beispiele mal ausgerechnet:

Beispiel1: #number1 p = 1 x 100 + 1 x 1 = 101
#number1 .red p = 1 x 100 + 1 x 10 + 1 x 1 = 111

Beispiel2: #number1 p = 1 x 100 + 1 x 1 = 101
.red p = 1 x 10 + 1 x 1 = 11

Unnötig komplizierter Code wie body #id #subid p span.card hat dann schon ein Gewicht von: 1 + 100 + 100 + 1 + 1+ 10 = 213.

Wer das nicht im Kopf ausrechnen kann oder will, es gibt dann noch eine nette Eselsbrücke. Man zähle zuerst die IDs, dann die Klassen und dann die Tags und schreibe die jeweiligen Werte einfach in dieser Reihenfolge nebeneinander:
body #id #subid p span.card {color: red} /* IDs=2 Klassen=1 Tags=3 = 213 */
[Gefunden in der guten alten WDG HTML Help.]

Damit kann man dann schon ein wenig Spass haben und mit ein wenig Hirnschmalz sein CSS doch einigermassen planen und auch ein Stückweit sprechend gestalten. In meinen aktuelle CSS heisst ein sehr hohes Gewicht immer: diese Regel ist wichtig, sie steht fest, wahrscheinlich im Styleguide, bitte nicht überschreiben. Was für Kollegen die später mit dem Code hantieren schonmal ein Hinweis ist… da könnten sie nun natürlich immer noch mit einem beherzten !important drüber bügeln, aber das müssen sie sich auch erstmal trauen. 😉

Holy Grail, found again!

Alan Pearce lives in the Chicago area and is a UI engineer for Orbitz. He has a love for web development, hockey, and a good pint of ale.

Hihi. Wohl kaum unter der Einfluss von Ale hat Alan Pearce einige sehr gute Ideen zum Thema »The Holy Grail of Webdesign«, also zu mehrspaltigen, vornehmlich elastischen Layouts zu Web gebracht. Sein Artikel bei A List Apart: Multi-Column Layouts Climb Out of the Box zeigt einige neu kompilierte Methoden, rock solid Layouts zu zimmern. Ich bewundere sowas: eine 1a-Transferleistung aus vorgegebenen Ideen zimmern, testen und zu Papier bringen, um sie mit der restlichen Welt zu teilen. Thumbs up!

Flash einbetten, aber richtig?

Manchmal bekommt man Angst, sich ein wenig selbst zu disqualifizieren, aber…, trotzdem…, sorry, was mich hier bei ALA langweilt: »Flash Embedding Cage Match by Bobby van der Sluis« ist der typische Fall von Standardismen as Totalism. Es ist der Offenbarungseid für Organisationen wie das W3C, den darin vertretenen Firmen (beispielweise die Hersteller properitärer Formate, bspw. Flash) und den Browserherstellern. Mal im Ernst, Flash ist jetzt nicht wirklich neu und irgendwie ziemlich verbreitet, und es gibt keine standardkonforme Methode, es vernünftig, browserkompatibel, inklusive alternativen Content, in eine Website einzubetten, ohne auf DOM-Scripting und andere Hilfsmethoden zurückzugreifen??? Die Erkenntnis ist nicht neu, aber immer wieder abschreckend.

Im vorigen Artikel habe ich ein You-Tube-Video eingebaut, und das möchte selbst ich, Webdeveloper etc. pp., einfach nur per copy & paste in mein Blog knallen. Weiter nichts. Fasst Euch mal alle an den Kopf bitte!

dojo.query

Kurze Zusammenfassung: Dojo kann jetzt auch Queries. Der Rest: die üblichen Anfeindungen mit der mangelhaften Dojo-Dokumentation. 😉

Einer der Gründe, warum beispielsweise jQuery in letzte Zeit so ausgesprochene Erfolge zu verzeichnen hat, dürfte deren eingebaute Query-Language sein, also die Möglichkeit, über CSS- und/oder XPath-Queries auf DOM-Elemente zuzugreifen. Es kommt einfach ziemlich handy, wenn man mal eben in einem Rutsch alle <a> mit der Klasse .popup beispielsweise mit einem prima Klick-Ererignis verknüpfen kann. In jQuery sieht das ungefähr so einfach aus: $('a.popup').click(function(){alert('So einfach ist das!')});. Das macht die Zugriffe aufs DOM einierseits zu alles anderem als Hexenwerk und kommt anderseits ziemlich handy daher (zumal man speziell bei jQuery nun noch beliebig viele andere Methoden mit weiteren ‚.‘ an die Geschichte anhängen kann).

Das ist eine sinnvolle Sache, haben sich die Dojo-Entwickler gedacht, und prompt etwas ähnliches eingebaut: dojo.query. Buh, billig kopiert könnte man jetzt anmerken, oder: »Jungs, dokumentiert die Codemassen, die ihr so ausspuckt, doch erst mal richtig, eh‘ ihr mit neuen Features prahlt«. Letzteres hätte sicherlich durchaus seine Berechtigung, anderseits, wie gesagt: es ist einfach ein cooles Feature. Ob man nun damit angeben muss, dass Dojo diese Queries auf jeden Fall viel schneller ausführt, als alle anderen JS-Toolkits, ist eine müßige Angelegenheit und zeigt nur, dass die Entwickler der unterschiedlichen Frameworks tatsächlich irgendwie mitinander in Konkurrenz stehen, oder sich selbst setzen. Was eigentlich unnütz und kontraproduktiv ist, denn mir gefiele es besser, man besinne sich der Vorzüge des jeweiligen Frameworks, bei Dojo dürften das die Widgets sein. Stattdessen lernen wir, das Dojo über »div span span« in IE7 4mal so schnell iteriert, als jQuery. Schön…