Conditional Comments, Resets, Frameworks

Artikel vom 31. März 2009. ISSN 1614-3124, #41. Schwerpunkt: Webentwicklung (RSS-Feed für alle Themen).

In diesem Artikel ist nicht unbedingt alles falsch, aber er ist dennoch etwas angestaubt. Ich habe alle meine Erfahrung in ein kleines Buch zum Thema geschmissen: Werfen Sie einen Blick auf Das kleine Buch der HTML-/CSS-Frameworks, um mehr über Frameworks zu erfahren.

Unter den schönsten und kontroversesten Themen des Webdesign-Gewerbes ist nicht immer leicht zu wählen: Warum Conditional Comments, Reset-Stylesheets und HTML-/CSS-Frameworks mit Vorsicht zu genießen sind.

Vermeiden Sie Conditional Comments

Conditional Comments (CC) stellen »by design« ein Wartbarkeitsproblem dar. Der Grund ist, dass mindestens ein zusätzliches Stylesheet im HTML eingebunden werden muss, sofern nicht, und das ist in der Regel keine wartbarere Alternative, die gesamte Formatierung via style-Elementen im HTML vorgenommen wird.

CC sind in gewissem Sinne vergleichbar mit font-Elementen: font-Elemente sollten vermieden werden, da sie präsentationsbezogen sind und HTML-Änderungen bedeuten, sobald das Layout, in diesem Fall Schriftzuweisungen, angepasst werden sollen. CC sollten vermieden werden, da sie implementierungsbezogen sind und mit wesentlich höherer Wahrscheinlichkeit HTML-Änderungen bedeuten, sobald eine neue Version des Internet Explorers erscheint, eine alte geht, oder vielleicht »einfach nur« IE-Stylesheets neu arrangiert werden.

Generell will man sich erinnern: HTML-Änderungen sind teuer. Daran ändern weder vorlagenbasierte Systeme noch »Suchen und Ersetzen« etwas; Conditional Comments werden dadurch genauso wenig wartbarer wie es Elemente wie font und center oder Attribute wie align und border werden. Die Inkaufnahme unnötiger HTML-Änderungen ist bestenfalls fragwürdig, selbst wenn man in seltsamer Form auf schmerzvolle Lernprozesse steht.

Anwender von Conditional Comments zahlen einen weiteren Preis: Die Arbeit mit Stylesheets wird oftmals erschwert, vor allem im Team, und dieser Preis birgt in der Regel gleich noch eine Steuer auf die generelle Code-Effizienz.

Vor allem in komplexeren Projekten, die Conditional Comments einsetzen, erschweren IE-Stylesheets die Arbeit, da diese von den beteiligten Webentwicklern immer im Auge behalten werden müssen. Irgendeine Änderung einer Deklaration im »Haupt-Stylesheet«, die bereits im IE-Stylesheet für den Internet Explorer überschrieben wurde, kann andernfalls Konfusion bedeuten (»warum benimmt sich der IE anders«) oder ineffizienten Code (Einsatz von beispielsweise !important bei Beibehaltung der jeweils überschriebenen IE-Deklaration).

Diese Problematik ist logisch, da das »Prinzip der Nähe« verletzt wird, konzeptionell zusammengehörige Regeln mittels CC getrennt werden. Jeder Usability-Test wird belegen, dass der durch CC aufoktroyierte Entwicklungsstil nicht benutzerfreundlich ist. Freunde proprietärer Pseudo-Standards bedenken dabei: Wir beziehen uns hier speziell auf komplexere Projekte; vielleicht nicht auf das Ihre.

Bei Darstellungsproblemen im Internet Explorer bietet sich zumeist an, sicherzustellen, dass man nicht in »hasLayout«-Probleme hineingerannt ist, alternative Lösungen zu prüfen (wie zum Beispiel beim Einsatz von Positionierung anstatt Floats) und notfalls auf bevorzugt valide »Hacks« zurückzugreifen. Die bedeuten in der Regel zumindest keine Wartbarkeitsprobleme.

Modifizieren Sie Reset-Stylesheets

Reset-Stylesheets, und derer gibt es einige, erfreuen sich moderater Beliebtheit, werden selten jedoch richtig eingesetzt; die Ironie ist vielleicht, dass sie richtiger Gebrauch nahezu obsolet macht.

Um Reset-Stylesheets richtig zu verwenden, müssen sie modifiziert und integriert werden.

Die Modifikation und Anpassung ist wichtig, um sicherzustellen, dass der Code im Reset-Stylesheet überhaupt benötigt wird, und wenn er benötigt wird, dass er nicht redundant ist oder überschrieben wird. Nicht benötigter Code, und der turnt in manchen Resets scharenweise herum – in wie vielen Projekten besteht konkreter Bedarf nach dem »Zurücksetzen« der Darstellung von samp, small oder auch a? – ist eine unnötige Courtage auf Ladezeit, Verständlichkeit und Wartbarkeit. Redundanter Code ebenfalls.

Vernünftige Integration ist im Zusammenhang mit verbesserter Performance erforderlich, und so sollten zumindest zusätzliche HTTP-Requests so zwingend erforderlicher Reset-Stylesheets vermieden werden.

Vermengt man die Empfehlung, Resets anzupassen und dann vernünftig zu integrieren, mit etwas Erfahrung mit CSS, keimt der Verdacht, dass man diese Mode-Stylesheets vielleicht gar nicht benötigt. Viele der Dinge, die Resets zurücksetzen wollen, sind so offensichtlich, dass sie eh nicht vergessen oder übersehen werden; sind sie es nicht, schert es vielleicht auch niemand.

Der CSS-Novize ist aus dem Schneider: Er sollte um Reset-Stylesheets schon allein deshalb einen Bogen machen, um zu lernen.

Basteln Sie eigene, maßgeschneiderte Frameworks

HTML-/CSS-Frameworks, bei aller Liebe, können ebenfalls nicht ohne Reflexion davonkommen. Das Problem ist, dass öffentliche, freie Frameworks niemals die beste Lösung sind, und sie meistens noch nicht einmal eine gute Lösung für irgendeine Website darstellen. Dies setzt das Ziel voraus, die beste oder zumindest eine gute Lösung zu finden; Leser dieser Website sind aber nicht gerade bekannt dafür, sich mit »irgendetwas« zu begnügen.

Das Problem liegt in der Natur der Sache: Menschen außerhalb Ihrer Firma oder Organisation können weder Ihre Bedürfnisse noch Anforderungen noch Designprobleme kennen. Entsprechend können sie sie auch nicht lösen, auch bei der Fairness und Hochachtung nicht, dass Frameworks sinnvoller- und üblicherweise den Weg über populäre Probleme und deren Lösungen nehmen, Stichwort Patterns.

Da Frameworks nicht das anbieten, was Sie brauchen, brauchen Sie Frameworks nicht. Selbst wenn Frameworks einen guten Teil von dem anbieten, was Sie als Ihren Bedarf identifizieren, brauchen Sie Frameworks nicht unbedingt, da entweder Sie oder Ihr Publikum wieder eine Steuer begleichen müssen: Entweder müssen Sie nicht notwendigen Framework-Code irgendwie loswerden, oder Ihr Publikum sich jedes Mal am Herunterladen selbigen stören.

Wer will, kann sowohl bei Reset-Stylesheets als auch HTML-/CSS-Frameworks die »Schneider-Metapher« gebrauchen: Ein guter Webentwickler, wie Sie einer sind oder wie Sie einen beschäftigen wollen, erstellt Websites wie ein Schneider Kleidung. Resets und Frameworks können nur dem Bild von Websites von der Stange entsprechen. Sie sind billig(er), sie mögen sogar ein bisschen passen, aber sie sind sicher nicht mit einem Maßanzug vergleichbar.

Von den obigen Punkten abgesehen können Frameworks unter einer Bedingung funktionieren: Wenn die zu lösenden Designprobleme bekannt sind. Das lohnt sich bei einer kleinen Website kaum, kann aber für ein Unternehmen mit einem Geflecht von Websites und Designrichtlinien attraktiv sein. Ein Unternehmen kann sein eigenes Framework maßschneidern und somit den theoretischen Vorteil von Frameworks mit dem Ziel effizienten Codes in die Praxis umsetzen.

Große Gefühle zu diesen Themen gewöhnt, wird um ausschließlich konstruktive Rückmeldung gebeten; auf dieser Website [standen] dazu die Kommentarfunktion von Google Friend Connect (bei aktiviertem JavaScript und einem modernen Browser unten rechts angezeigt) sowie englischsprachige, kommentierbare Alternativbeiträge bereit, einmal zu Conditional Comments und Resets, dazu zu Frameworks.

Über mich

Ich bin Jens, und ich bin ein Engineering Lead und Autor. Ich habe als technischer Leiter für Firmen wie Google und als Engineering Manager für Firmen wie Miro gearbeitet, bin W3C und WHATWG verbunden und schreibe und prüfe Fachbücher für O’Reilly und Frontend Dogma.

Mit meinem aktuellen Umzug nach Spanien bin ich offen für eine neue Führungsposition im Frontend-Bereich. Beachte und empfehle gerne meinen Lebenslauf oder mein LinkedIn-Profil.

Ich experimentiere gerne, nicht nur in der Webentwicklung, sondern auch in anderen Bereichen wie der Philosophie. Hier auf meiert.com teile ich einige meiner Ansichten und Erfahrungen.