Haftpflicht Blogger
Virtual Server von Host Europe

Problematik: CSS Wildwuchs

| 11. Februar 2016 | Keine Kommentare

Als Webentwickler arbeite und kämpfe ich mit CSS-Stylesheets. Warum ich das Wort „kämpfen“ verwende, das können Sie in diesem Artikel lesen.

Wildwuchs bei Stylesheets

SEO -Wenn man sich den Quellcode einer Internetseite ansieht, dann staunt man teilweise nicht schlecht. Oft werden im besten Fall 5 bis 10 verschiedene Stylesheets eingebunden, teilweise sind es aber auch mal an die zwanzig CSS-Dateien.

Das ist nicht nur schlecht für die Ladezeit der Seite (Performance, Google Page Speed), sondern auch für die Qualität der Seite, da durch das gegenseitige Überschreiben der Stylesheet-Befehle teilweise ungewünschte Resultate entstehen (z.B. ein Plugin funktioniert nicht/nicht mehr wie gewünscht)  

Ursache des Wildwuchs

Um die eigene Funktionalität zu gewährleisten, bringen insbesondere drei Komponenten ihre eigenen Stylesheets mit:

  • das WordPress Theme selbst
  • Frameworks wie Bootstrap
  • die Mehrheit der Plugins

1.) #id- und .class-Bezeichner

Bei Smartphones hat man sich inzwischen glücklicherweise bezüglich der Ladegeräte auf einen Standard geeinigt. Bei den id- und class-Bezeichnern innerhalb der Stylesheets wäre es jedoch Utopie anzunehmen, dass dies irgendwann einmal geschieht. Die CSS-Klasse für den Hauptinhaltsbereich heißt dann bei dem einen #container, beim anderen #main-container, dann wieder #page, u.s.w. 

Insbesondere, wenn man mehrere Domains besitzt oder als Webagentur, heißt es dann jedes Mal wieder aufs Neue die css-Bezeichner z.B. für das Menü anzupassen.

2.) Browser Kompatibilität

Schwierig wird es, wenn die Themes und Frameworks CSS-Grundinitialisierungen (CSS-Resets) vornehmen [1].

Die Absicht dahinter ist zunächst einmal gut und nachvollziehbar. Man möchte, dass Browser Inkompatibilitäten vermieden werden, damit sichergestellt werden kann, das ein responsives Design in den gängigen Browsern auch gleich dargestellt wird. Aber die Autoren der Themes und Frameworks haben verschiedene Meinungen was Basis eines Stylesheets sein müßte und kochen bei verschiedenen Punkten ihre eigenen Süppchen. 

Nun könnte man sich zwar für die eine oder andere CSS-Reset vorgehensweise entscheiden und die andere deaktivieren, aber so einfach ist dies dann doch nicht, wenn das Theme oder das Framework auf gerade den eigenen, mitgelieferten Resetanweisungen beruht.

3.) Namensraum

Ein drittes Problem bei den Stylesheetdateien ist die Namensgebung.

Was liegt näher, als bei einem Plugin, welches spezielle Buttons zur Verfügung stellt, nicht auch eine Klasse mit .button zu bezeichnen. Installiert man dann ein anderes Plugin, wobei es nicht unbedingt ein zweites Button-Plugin sein muss, sondern  z.B. ein Shortcode Plugin (uuups, auch hier werden immer Buttons-Shortcodes mitgeliefert), dann ist die Wahrscheinlichkeit sehr groß, dass auch dieser Entwickler eine seiner CSS-Klassen mit .button bezeichnet hat. 

Namenskonflikte sind bei so  wenig Kreativität unvermeidlich.

Leider arbeiten die wenigsten Pluginentwickler mit eigenen Namensräumen und liefern damit einen rebusteren, qualitativ besseren Code.

Erkannte Problematik (Reglementierung)

Der aufmerksame Leser dieses Artikels mag nun einwenden, dass ich mich im ersten Punkt für  genormte Bezeichner ausgesprochen habe, um dann im dritten Punkt genau das Gegenteil zu fordern, nähmlich individuelle Bezeichner. 

Dies ist nur scheinbar ein Widerspruch. Die Namensgebung für die #id-Selektoren sollte geregelt sein, die für die .class-Selektoren hingegen nicht.

Links, die sie interessieren könnten:

[1] Initialisierung von Browsern: Normalize.css von Nicolas Gallagher und Jonathan Neal

 

 

Stichworte: , , , ,

Kategorie: CSS, Internet

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.