Lässt sich verhindern, dass Spezifität die CSS-Kaskade beeinflusst?

Spezifität in CSS: eine Notwendigkeit?
Keine Kommentare

Für die Gestaltung einer Website kommt man um eine mehr oder minder große Menge an CSS-Code nicht herum. Ein dabei häufig auftretendes Problem ist die Spezifität – also das Mittel, anhand dem der Browser entscheidet, welche CSS-Property-Werte für ein Element am relevantesten sind und darum darauf angewandt werden. Die Frage, die sich dabei stellt, ist oft folgende: braucht man diese Spezifität überhaupt oder lässt sich verhindern, dass sie die CSS-Kaskade beeinflusst?

Dass an einem gewissen Maß an CSS-Spezifität kein Weg vorbeiführt, ist angesichts des aktuellen Technologiestandes eigentlich klar, denn würde man plötzlich komplett darauf verzichten, dürfte das für einiges Chaos und zahlreiche kaputte Websites sorgen. Darum ist es vor allem ratsam, die CSS-Spezifität so gering wie möglich zu halten. Trotzdem, so erklärt Philip Walton, ist es durchaus möglich, zu verhindern, dass die Spezifität die Kaskade beeinflusst. Wie das gehen könnte, zeigt er in seinem Artikel Do We Actually Need Specificity in CSS?

CSS-Spezifität: ein unvorhersehbarer Faktor

Das Problem mit der Spezifität ist vor allem, dass die Funktionalität unzähliger Websites davon abhängt. Würden Browser plötzlich von heute auf morgen die gegebene Spezifität ignorieren, dürfte das für viele nicht mehr funktionierende Websites sorgen. Es ist also weniger eine Frage, ob Spezifität tatsächlich genutzt wird – denn das wird sie eindeutig. Stattdessen sollte die Frage eher lauten, ob sich der ganze Rattenschwanz an Komplikationen, die Spezifität mit sich bringt, tatsächlich lohnt.

So sorgt Spezifität nicht nur bei vielen Entwicklern für Verwirrung, sie ist in vielen Fällen auch unvorhersehbar. Dabei folgt CSS-Spezifität eigentlich der logischen Schlussfolgerung, die eindeutigere Regel zu einem späteren Zeitpunkt im Code unterzubringen, als die CSS-Regel, die damit außer Kraft gesetzt werden soll. Dazu sagt Walton:

If I want rule Y to override rule X, I put it later in the source order. Period. Which means any time I have a specificity conflict, it’s always an accident.

Dementsprechend wird bereits erwartet, dass später in der Reihenfolge im Quellcode folgende Regeln immer früher auftretende Regeln außer Kraft setzen – und das könnte man sich, so überlegt Walton, auch ohne die tatsächliche Spezifität der jeweiligen Regeln zu Nutze machen.

Wichtigkeit und Source-Anordnung

Gäbe es keine Spezifität in CSS, würde die Kaskade sowohl durch die Reihenfolge der Regeln im Quellcode als auch durch die Wichtigkeit bestimmt. Das heißt, wenn Regel X und Regel Y beide auf ein Element angewandt werden sollen und Regel Y dabei im Code erst nach Regel X kommt, wird immer Regel Y bevorzugt – es sei denn Properties in Regel X würden mit einer höheren Wichtigkeit versehen.

Dazu sagt Walton:

If specificity didn’t exist, you could ensure state classes trumped others classes by simply including them last in the source order. But as it is today, you have to use !important to solve the problem.

Doch würde das zu einem vorhersehbareren und vor allem leichter zu maintainenden und skalierbaren Code führen? Eine eindeutige Antwort darauf gibt es nicht, schon alleine, weil es bisher kaum eine Möglichkeit gibt, die Anwendung der Spezifität einer CSS-Regel zu umgehen.

Und wenn es keine CSS-Spezifität gäbe?

Genau hier wird es aber erst richtig interessant. So kann zwar nicht einfach dafür gesorgt werden, dass der Browser die CSS-Spezifität ignoriert, es ist jedoch möglich die Beeinflussung der CSS-Kaskade für eine oder mehrere bestimmte CSS-Dateien zu verhindern – und zwar indem Spezifität und Reihenfolge angeglichen werden.

Im Prinzip sollen dabei alle Regeln von der am wenigsten spezifischen zur höchstspezifischen CSS-Regel angeordnet werden, wodurch die Spezifität aufgehoben wird. Das Problem dabei: niemand schreibt seinen CSS-Code auf diese Art und Weise. Abhilfe schaffen könnte, so überlegt Walton, ein Transpiler, der nach dem Schreiben des Codes selbigen so modifiziert, dass sämtliche Selektoren in einer absteigenden Spezifitäts-Ordnung vorhanden sind.

Dank der Art und Weise wie CSS-Selektoren funktionieren, ist es sogar möglich eine solche Modifizierung durchzuführen, ohne dass die von den Selektoren angesprochenen Elemente beeinflusst werden. Das liegt vor allem daran, dass sämtliche HTML-Dokumente ein :root-Element haben; darum kann Selektoren problemlos eine :root-Pseudo-Klasse hinzugefügt werden ohne dass auf das Element Einfluss genommen wird. Auch mit einer :not()-Pseudo-Klasse lässt sich ein ähnlicher Effekt erzielen.

Ein wenig komplizierter wird es da bei ID-Selektoren und Selektoren, die mit Modernizr erstellt wurden. Doch auch dafür stellt Walton einen Lösungsansatz vor; er kann im oben genannten Artikel nachgelesen werden.

Bisher gibt es einen solchen Transpiler allerdings noch nicht; am einfachsten dürfte sich dieser als PostCSS-Plugin umsetzen lassen. Trotzdem gibt es natürlich auch einige Schattenseiten dabei. So steigt einerseits die Größe der CSS-Datei an, was im Zweifelsfall auf die Performance drücken kann. Andererseits kann es zu Problemen beim Referenzieren von externen Styles kommen, weil dabei etwa ein Selektor-Set neu geschrieben wird, während das andere Set in seinem Ursprungszustand bestehen bleibt.

Fazit

Walton betont in seinem Artikel, dass der von ihm vorgestellte Lösungsansatz keinesfalls als Best Practice anzusehen ist, sondern eher zum Nachdenken anregen soll. Denn während er zwar zeigt, dass sich durchaus auch ohne Spezifität arbeiten lässt, heißt das noch lange nicht, dass diese Lösung auch „in the wild“ funktioniert. Denn, so sagt Walton abschließend:

I suspect it would vastly simplify things, but it also might uncover how much we truly depend on specifity.

webinale – the holistic web conference

Diversity matters – Onlinemarketing 2020

mit Astrid Kramer (Astrid Kramer Consulting)

Das Recht auf Privatsphäre – eine Chance für UX

mit Lutz Schmitt (Lutz Schmitt Design & Consulting)

The Revenge of Structured Data

mit Stephan Cifka (Performics Germany GmbH)

IT Security Summit 2020

Zero Trust – why are we having this conversation?

mit Victoria Almazova (Microsoft)

Digitaler Ersthelfer

mit Martin Wundram (DigiTrace GmbH)

Aufmacherbild: A long line of dominoes going into the distance starting to fall over cascade. von Shutterstock / Urheberrecht: Christos Georghiou

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -