CSSLint – ein Ansatz zum CSS-Qualitätscheck

Nicole Sullivan hat zusammen mit Nicholas Zakas (beide sind ehemalige Yahoo!-Angestellte) auf der Velocity-Konferenz das ToolCSS-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):

  1. Parsing errors should be fixed
  2. Don’t use adjoining classes
  3. Remove empty rules
  4. Use correct properties for a display
  5. Don’t use too many floats
  6. Don’t use too many web fonts
  7. Don’t use too may font-size declarations
  8. Don’t use IDs in selectors
  9. Don’t qualify headings
  10. Heading styles should only be defined once
  11. Be careful using width: 100%
  12. Zero values don’t need units
  13. Vendor prefixed properties should also have the standard
  14. CSS gradients require all browser prefixes
  15. Avoid selectors that look like regular expressions
  16. 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.

6 Kommentare

  1. Der 1. Teil des Programms – Syntaxcheck – klingt – ohne es selbst ausprobiert zu haben – ganz nett.
    Über den Praxiswert kann man sich hier schon streiten: ein Programm anzuwerfen, dass mein CSS validiert, ist auch ein Browser.

    Der 2. Teil des Programms ist Murks.
    Das mag theoretisch alles hinkommen und stimmen, zu vielen Punkten der Optimierungsliste habe ich aber praktische Einwände … die anderen paar Punkte bekomme ich ohne ein gesondertes Programm hin.

    Die Zielgruppe für dieses Programm sind m.E. nur riesige Projekte – wie Yahoo – , auf die CSS-Skalierung überhaupt einen messbaren Einfluss hat.

    Die Idee ist nett.

  2. Der entscheidende Punkt ist doch, dass CSS Lint quasi modular ist („pluggable“ im Originalartikel bei Nicole). Du kannst also die Regeln, die Du nicht sinnvoll findest, einfach rauslassen (keine Ahnung, wie das praktisch geht) oder eigene hinzufügen.

    Über den Sinn der Sache kann man sicherlich trotzdem herrlich streiten. 🙂

  3. CSS Lint braucht Optionen wie JSLint. Letzteres kann ja auch weniger streng eingestellt werden, was oft sinnvoller ist als die ganz harte Keule zu schwingen.

    Wie Florian schon angesprochen hat, ist das Tool für größere (nicht bloß für riesige) Projekte vielleicht deshalb gut geeignet, weil es sich ja auch lokal installieren lässt. Wenn man dann eigene Regeln definieren und es in einen Build-Prozess integrieren kann, lassen sich zumindest grobe Syntaxfehler u.ä. schon relativ früh abfangen.

  4. Einige Regeln finde ich auch eher seltsam. Alles in allem jedoch ein recht nützliches Tool. Mehrere 100 Zeilen CSS durchgecheckt und einen übersichtlichen Fehler- bzw. Warnungskatalog ausgespuckt zu bekommen ist schon ganz praktisch.

  5. Was für ein Quatsch. Web-Coding ist kein Schrebergarten, der Regeln braucht. Und wenn dann sinnvolle, und nicht irgendwelche ausgedachten. 80% der oben genannten Regeln sind komplett Praxisfremd. Wichtig war, ist und bleibt was funktioniert.

  6. Ich finde die Umsetzung von CSSLint momentan eher zweifelhaft, denn nützlich. Die ausgegebenen Warnungen haben mehrheitlich keinen nachvollziehbaren Hintergrund und Behauptungen wie Regel Nr. 8, eine ID verhindere die Wiederverwendung sind in dieser Form aus meiner Sicht einfach nur grober Unfug.