10 tipps für webseitenbauer

[molily]

Hallo,

ich bezog mich vielmehr darauf, warum sich allgemein zu dem Thema niemand mehr zu Wort melden will.

Zu deinem Posting konkret: Ich verstehe dein Argument nicht. Du listest einige große Sites auf, die kein oder nur ein kleines separates IE-Stylesheet haben. Okay. Aber schaue in die regulären Stylesheets rein, finde ich dort (sogar zusätzlich zu einem separaten IE-Stylesheet) dutzende Inline-Hacks, von _eigenschaft über *eigenschaft zu * html und *+html. Aus eigener Erfahrung weiß ich, dass es viele Bugs gibt, die man ohne sichtbare Hacks (also Weichen), sondern mit Standard-CSS umschiffen kann (z.B. padding statt margin oder umgekehrt, feste Breiten/Höhen, eine harmlose Eigenschaft, die als Nebeneffekt hasLayout auslöst usw.). Daher gehe ich davon aus, dass die großen Sites zudem massig dieser unsichtbaren Fixes einsetzen bzw. Browserbugs erst gar nicht auszulösen versuchen. Oder wie MySpace derartig anachronistisches Tabellenlayout verwenden, dass sie auf CSS-Fixes verzichten können.

Und ehrlich gesagt rate ich jedem, der eine große Site baut, IE-Kram möglichst separat einzubinden und auch keinesfalls »unsichtbare« Hacks einzubauen. Schau dir Youtube an, die wollen den IE6-Support beenden. Das geht nur, wenn der IE-spezifische Code lokalisierbar ist und problemlos herausgezogen werden kann. Klar, das kann man mit Regeln, die mit »* html« beginnen, auch, aber per separatem IE6-Stylesheet ist das noch einfacher.

Hinter Xing steht übrigens Ingo Chao als Frontend-Architekt und dessen Philosophie bezüglich IE kann man im seinem m.M.n. hervorragenden Buch nachlesen; eines der besten deutschsprachigen CSS-Bücher, welches einem viel über robustes und wartbares CSS vermittelt. Chao ist lediglich nicht so »laut« wie Meiert.

Was ich hier schon einmal vor geraumer Zeit verlinkt habe, sind die Stylesheets von InterNations.org, einer größeren Site, die unter meiner Federführung zur Jahreswende 2008/2009 redesigned wurde. (Man sieht davon nicht viel, es ist ein invite-only Social Network.)

http://www.internations.org/static/css/ie/ie.css
http://www.internations.org/static/css/ie/ie6.css
http://www.internations.org/static/css/ie/ie7.css

Richtig, das ist aufs Ganze gesehen ziemlich wenig - das geminifyte Master-Stylesheet ist 156KB groß. Dagegen sind diese paar Regeln nichts. Und sicher hätte man es noch reduzieren können. (Die obigen Dateien sind noch nicht einmal minified und daher sehr redundant - was bei der Auslieferung dank GZip allerdings nicht stark ins Gewicht fällt.) Aber diese Hacks auf ein Minimum zu reduzieren, um diese Dateien letztendlich abzuschaffen, war für mich als »Architekt« des HTML und CSS dieser Site kein entscheidender Punkt. Natürlich habe ich »defensiv« CSS geschrieben, um das Auslösen und Fixen von IE-Bugs von vornherein zu vermeiden. Diese Arbeit sieht man wie gesagt nicht im End-Stylesheet. Sie ist aber da, auch ohne explizite hasLayout-Trigger udgl.

In der Umgebung, in der ich arbeite, bin ich derjenige, der sich am besten mit IE-Bugfixing auskennt (zumal IE6). Ehrlich gesagt kenne ich außer Leuten wie Ingo Chao sehr wenige - geschweige denn in diesem Forum -, die IE-Probleme korrekt beschreiben und zielgenau korrigieren können. Das nicht als Eitelkeit, sondern nur zu den Umständen solcher Arbeit. Es war bei der besagten Site einfach eine von vielen weiteren Konventionen, auf CCs zu setzen. Wie es als Coding-Guideline auch bei den meisten anderen Sites der Firma, in der ich arbeite, Konvention ist. Und wir fahren in den meisten Fällen sehr gut damit, auch bei hoch frequentierten Sites. Wir wissen um die Nachteile. Vieles davon, was Kritiker wie Meiert nur als Vermutung theoretisch geäußert haben, kann ich - im positiven wie im negativen - in der Praxis bestätigen. Wir wissen daher auch um die Vor- und Nachteile der Alternativen. Im Hauptstylesheet (wo ca. 25 Module zusammenkommen) finden sich aus Bequemlichkeit sicher auch einige zoom:1.

In einem Team Konventionen aufzustellen, zu vermitteln und durchzusetzen (welche Probleme, welche Fixes, wohin mit den Fixes, wie erkenntlich machen und kommentieren) halte ich für viel wichtiger und schwieriger als die Frage nach der konkreten Umsetzung. Da geben sich die Ansätze nicht viel. Und messbare Performanceoptimierung setzt, das hat obige Site gezeigt, noch einmal ganz woanders an. Aber das habe ich hier glaube ich schon vor zwei Jahren geschrieben. Insofern stinkt mir immer noch die Art und Weise, wie dogmatisch oder einfach nur übertrieben skeptisch hier manche reagieren.

Die wenigsten hier haben vermutlich Sites in der Größe von Twitter, Youtube oder SmashingMag umgesetzt und können von konkreten Erfahrungen berichten. Klar, für mickrige Sites wie meine private Homepage brauche ich kein IE-Stylesheet. Da leiste ich mir einfach den Luxus, auf IE-Optimierung komplett zu verzichten. Das ist aber kein Argument für irgendetwas, denn bei kommerziellen Sites oder Sites für IE-Intranets ist das nicht praktikabel. Wenn ich solche Sites baue, selbst kleine, dann erfinde ich jedoch die Coding-Guidelines und die wiederverwendbare Frontend-Struktur, die wir einmal gebaut, getestet, dokumentiert und im Team etabliert haben, nicht neu, nur weil die spezifischen Anforderungen der Site ein Fitzelchen anders sind. Das sind halt menschengemachte Konventionen. Manchmal ist es besser oder zumindest nicht nennenswert nachteilig, ihnen zu folgen, manchmal gehören sie über den Haufen geworfen, weil sie nicht zu den Anforderungen passen. Dass es Ermessensspielräume gibt und geben muss, verstehen auch (fast) alle, wie etwa jobos Posting zeigt.

Mathias