Die Arbeit an komplexen Projekten oder Projekten, die keine gute Übersicht über noch umzusetzende Seitentypen oder -elemente bieten, kann eine defensive Strategie beim Schreiben von Stylesheets erfordern. Solch eine defensive Strategie beinhaltet bestimmte Sicherheitsmaßnahmen, um bessere Wartbarkeit zu gewährleisten, und eine Taktik dafür sind CSS-Pseudo-Namensräume.
Anmerkung: Dieses Namensraumkonzept ähnelt dem in XML nur grob. Es gibt noch keine „echten“ Namensräume in CSS, daher der Name „Pseudo-Namensraum“.
Beispiele für CSS-Pseudo-Namensräume
Spezielle Icons für Links sind ein guter Anfang: Möglicherweise müssen oder wollen bestimmte Links (zum Beispiel die für Dateitypen oder Aktionen) mit unterschiedlichen Symbolen ausgestattet werden. Vorausgesetzt, dass dafür kein stabiler, verlässlicher Kontext vorliegt (wie bei ausschließlich PDF-Links in der projektspezifischen Marginalspalte), können den betroffenen Links dazu spezielle Klassen geschenkt werden:
<a href="" class="doc"></a>
<a href="" class="pdf"></a>
<a href="" class="ppt"></a>
Das ist okay, auch wenn man dies beispielsweise mit zusätzlichen file-Klassen noch etwas „kultivieren“ könnte. Aber angenommen, dass man a) nicht weiß, welche anderen Seitenelemente noch folgen werden, und/oder man b) nicht alleine am entsprechenden Projekt arbeitet oder arbeiten wird, möchte man möglicherweise sichergehen, dass nicht irgendwelche Konflikte auftreten – zum Beispiel wenn irgendwann ein „Dokumentvoransicht-Modul“ mitsamt doc-Klasse eingeführt wird.
Anmerkung: Diese Problematik kann man natürlich auch mit kontextabhängiger Formatierung adressieren (a.doc vs. div.doc), was für gewöhnlich eine ratsame Sache ist. Aber dies kann wiederum in mehr Code resultieren, als notwendig ist, besonders, wenn es um komplexere Projekte geht, in denen man eher bei Dutzenden und zugleich wesentlich längeren Selektoren landet, und es löst auch nicht das Problem, dass man nicht unbedingt weiß, wer als nächster am Code arbeitet.
Nun, „Pseudo-Namensräume“ können Abhilfe schaffen, wie zum Beispiel:
<a href="" class="nf-doc"></a>
<a href="" class="nf-pdf"></a>
<a href="" class="nf-ppt"></a>
Das nf-Präfix ist hier willkürlich gewählt und bedeutet „Namensraum [für das] Format“. Das „n“ stellt dabei sowohl einen Vorschlag für ein Namensraumkürzel als auch eine weitere Sicherheitsmaßnahme dar, in dem Sinne, dass es es noch unwahrscheinlicher macht, dass sich irgendjemand einen so abgekürzten Namen ausdenkt. Da das nf-Präfix auf Links beschränkt werden könnte, sollte man für diesen (und jeden anderen) Namensraum eine Konvention festlegen und dies entsprechend dokumentieren. (Wie zuvor erwähnt ist dies eine Sicherheitsmaßnahme, so dass jeder, der eine weitere doc-Klasse einführt, keine Probleme verursacht; man will aber gleichzeitig auch Inkonsistenzen bezüglich ID- und Klassen-Namen vermeiden. Ein klarer Fall für ein wenig Dokumentation.)
Neben dem reduzierten Risiko späterer Konflikte ist es nun möglich, einfacheren CSS-Code zu schreiben:
.nf-doc {}
.nf-pdf {}
.nf-ppt {}
… und man kann mit den nächsten Elementen fortfahren, zum Beispiel mit bestimmten Maßen für Eingabeeelemente:
.ni-s {}
.ni-m {}
.ni-l {}
… wo ni „Namensraum [für] input[-Elemente]“ bedeuten mag, und wo man ohne Bedenken sehr kurze und prinzipiell gute Klassen-Namen („small“-, „medium“- und „large“-Eingabeelemente, bei denen die Namen eher die Relation der betroffenen Elemente illustrieren sollen als präsentationsbezogen sind – das täuscht hier) einsetzen kann.
Pro und Contra Pseudo-Namensräume
Idealerweise kann hier das Konzept demonstriert werden, ohne zuviel Fokus auf Details zu provozieren (es wird nicht viel Gutes bringen, an dieser Stelle file-Klassen und ähnliches zu diskutieren). Entsprechend folgen nun die Nachteile von CSS-Pseudo-Namensräumen:
- Sie erfordern etwas mehr Code-Konventionen und
- etwas mehr Dokumentation, da ihre (empfohlene) knappe Form neue Projektmitglieder irritieren kann;
- tendentiell gefährden sie die CSS-Code-Konsistenz (jedoch „by design“, da eben beabsichtigt ist, unvorhersehbare Formatierungsprobleme zu verhindern).
Auf der anderen Seite haben diese Namensräume einige entscheidende Vorteile:
- Sie ermöglichen kompaktere und effizientere Stylesheets;
- sie bedeuten mehr Sicherheit bei
- neuen Seitenmodulen,
- Injektionen von fremdem Code und
- neuen Teammitgliedern;
- sie schützen die Semantik von ID- und Klassen-Namen, während
- sie zudem mehr Flexibilität aufgrund von nicht notwendigerweise verwirrender Wiederverwendung von nützlichen ID- und Klassen-Namen erlauben;
- sie sind schlussendlich kostengünstiger, obwohl sie dennoch Qualität sichern.
Als Daumenregel: Je größer und undurchschaubarer das jeweilige Projekt ist oder tendiert, zu werden, desto mehr wird man von diesem Namensraumkonzept profitieren. Auch wenn es mit Bedacht eingesetzt werden sollte.
Dieser Artikel kann im englischsprachigen Original kommentiert werden.
Erstveröffentlichung 30.03.2007
