CSSLint - ein Ansatz zum CSS-Qualitätscheck
Nicole Sullivan hat zusammen mit Nicholas Zakas (beide sind ehemalige Yahoo!-Angestellte) auf der Velocity-Konferenz das Tool "CSS-Lint" vorgestellt. Es ist über github als OpenSource veröffentlicht. Genau wie das legendäre JSLint soll CSSLint die Syntax auf Fehler und Verbesserungsmöglichkeiten untersuchen. Doch da werden sich schnell die Geister scheiden. Nicole ist mit ihrem Ansatz des "objektorientierten CSS" (OOCSS) bekannt geworden. Sie hat darauf aufbauend sich mit Performance und CSS beschäftigt, genau wie Nicholas Zakas sich mit Performance und Javascript beschäftigte.
Herausgekommen ist nun also ein Tool, mit dem ich mein CSS durchchecken lassen kann. Abseits der möglicherweise gefundenen Fehler geht CSSLint nach einigen Regeln vor, die ich nicht komplett glücklich finde. Für mich wird das Tool, wenn überhaupt, erst sinnvoll nutzbar, wenn ich einzelne Regeln von der Überprüfung ausschliessen kann. Zakas fasst die Regeln kurz zusammen (zur besseren Orientierung habe ich die ungeordnete in eine geordnete Liste geändert):
- Parsing errors should be fixed
- Don’t use adjoining classes
- Remove empty rules
- Use correct properties for a display
- Don’t use too many floats
- Don’t use too many web fonts
- Don’t use too may font-size declarations
- Don’t use IDs in selectors
- Don’t qualify headings
- Heading styles should only be defined once
- Be careful using width: 100%
- Zero values don’t need units
- Vendor prefixed properties should also have the standard
- CSS gradients require all browser prefixes
- Avoid selectors that look like regular expressions
- Beware of broken box models
Regel 8 beispielsweise finde ich nicht sinnvoll. Wenn es nur ein Element gibt, auf das eine bestimmte Regel zutrifft, dann kann ich diesem Element auch eine ID geben. Ich sollte vorsichtig damit umgehen, aber es zu "verbieten" ist wenig sinnvoll. IDs nutze ich im Wesentlichen für den grundlegenden Seitenaufbau und für Navigationen.
Regel Nr. 4 würde in meinen Styles häufiger anschlagen, denn ich schreibe immer "float: left; display: inline;", um den Doubled-Margin-Bug des IE6 zu umgehen. Ich verlagere diese Regeln nie in ein IE6-Stylesheet, weil sich dadurch die Pflege verkompliziert.
Was sind denn laut Regel 5 zuviele Floats? Ist ein Float pro 50 Zeilen Code okay?
Auch mit den Regeln 9 und 10 habe ich so meine Probleme. Das liegt aber daran, dass ich den OOCSS-Ansatz nicht nutze. In den meisten Projekten kann ich froh sein, wenn ich eine halbwegs sinnvolle Semantik mit den unterschiedlichen Überschriftentypen zusammenbringen kann. Nicole hat jahrelang bei Yahoo gearbeitet. Dabei handelt es sich um einen ganz speziellen Typ Seite, bei dem es vielleicht noch möglich ist, sich auf zwei oder drei Überschriftentypen zu einigen. Bei meinen Projekten kommt mir das eher nicht vor. Und so gehe ich immer modulweise vor und zeichne Überschriften auch meist modulweise aus. Eine Überprüfung dieses Punktes würde mir also nichts bringen.
Der Sinn von Regel 16 erschliesst sich mir nicht. Welches kaputte Boxmodell meinen die beiden? Das des IE6, wenn er im Quirksmode ist? Ich wünschte, genau das wäre das Standardmodell. Das W3C-Boxmodell hingegen ist in keinem aktuellen Browser kaputt. Man muss nur damit umgehen und die Addition nicht vergessen.
Auch wenn sich jetzt wieder überall ein Sturm von "awesome" und ähnlich platten Lobeshymnen erheben werden: alles in allem ist CSSLint in meinen Augen eine nette Idee, für meine Praxis aber etwa zur Hälfte untauglich.
- ← Previous
Rezension: Barrierefreiheit verstehen und umsetzen - Next →
Videoeinbindung