Bootstrap

Bootstrap is a toolkit from Twitter designed to kickstart development of webapps and sites. It includes base CSS and HTML for typography, forms, buttons, tables, grids, navigation, and more.

Via ALA.

Leselinks #2

Ein wunderschönes Spielzeug für Webkit-Browser ist UmbraUI: Experimental Shadow DOM styling of <input> elements. Keine Bilder, kein zusätzliches Markup, kein Javascript. Noch mehr CSS/HTML/JS-Spielerei gefällig? Die iPad2-Simulation!

Heute soll der/die/das Amazon Kindle Fire präsentiert werden. Bei paidContent.org noch schnell nachlesen, was man gestern noch darüber geglaskugelt hat.

Christian Krammer referiert eigentlich über den langen Weg zum Reset-Stylesheet, liefert stattdessen in den Kommentaren eine gute Erklärung, warum man immer noch em Nutzen sollte.

Beim Networking ist das beste Zeitmanagement kein Zeitmanagement, jedenfalls wenn man nicht Madonna treffen will, schreibt Simone Janson. Davon verstehe ich ehrlich gesagt nichts, da ich weder Zeit- noch Networkmanagement betreibe. Immer schön die toDo-Liste pflegen!

The state of CSS

Da ist ein Eisbär im Raum?

Im Moment gibt es wieder viel zu lernen, in Sachen CSS. Da sind zunächst die vielen neuen Dinge, die CSS3 bringt. Durch die derzeit rasante Browserentwicklung, Polyfills oder einfache Fallbacklösungen kann man vieles davon schon heute oder wenigstens morgen gebrauchen. Dazu kommen die Learnings aus einigen Jahren intensiven Einsatzes von CSS, seit der internationalen Ächtung des Tabellenlayout ist viel passiert.

Seit CSS dem style-Attribut entwachsen ist, unterlag es lange Zeit einer eher langsamen Entwicklung. Gehemmt durch den Internet Explorer hat es ewig gedauert, bis sich CSS 2(.1) überhaupt durchgesetzt hat. Man hat lange Zeit eher mit den gegebenen Umständen hantiert, anstatt CSS weiter zu entwickeln. Die floats lösten die Tabellen ab, die CSS Hacks beherrschten die Szene lange, machten zweigleisige Entwicklung für potente und für beschränkte Browser möglich. Das Set an Techniken hat sich aber in der Menge kaum verändert, vielmehr lernten wir immer besser damit umzugehen. Dabei sind aber auch viele Standardlösungen entstanden, die heute einer genaueren Prüfung unterzogen werden müssen.

Our best practices are killing us!

Nicole Sullivan (die, nicht die) tritt derzeit mit einem Vortrag unter diesem Titel auf, den ich sehr beeindruckend finde, weil er so sehr das trifft, was ich derzeit selbst in der Praxis feststelle. Viele der best practices, die in den letzten Jahren ersonnen, gepaukt und umgesetzt wurden, klingen gut, haben sich aber in den Jahren ihres Einsatzes vielleicht gar nicht bewährt. Andere wurden von der Entwicklung überholt, wurden zur Angewohnheit. Um mal ein klassisches Beispiel aus einem anderen Bereich zu bringen: wenn Sie <script>-Blöcke in einem HTML-Document nutzen, umgeben sie den Code dann auch noch mit HTML-Kommentarzeichen? Eine Technik, die heute lange nicht mehr nötig ist. Trotzdem sieht man sie immer wieder. So geht es auch mit vielen Angewohnheiten in CSS.

Nicole Sullivan nennt viele Beispiele. Unter anderem findet sie:

  • die Angabe von Schriftgrößen nicht in Pixel sei kontraproduktiv,

  • etwas mehr Klassizitis wäre gar nicht so schlecht, da so lange Selektorketten vermieden würden,

  • durch semantische Klassennamen würde der Codewiederholung der Weg bereitet,

  • der Mythos, kein zusätzliches Markup für das Layout einführen zu dürfen, sei mehr als schädlich, da durch Container Layoutprobleme auf festgelegte Bereiche beschränkt werden könnten.

In der Praxis nicht bewährt

Da geht es ihr genau wie mir. Wenn man betrachtet, wie wirklich große Website-Projekte entstehen, stellt man fest, dass durch die genannten best practices Nötiges nur von einer Ecke des Projekts in die andere verschoben wurde. So kann man wunderbares, absolut semantisch reines HTML schreiben, ohne jegliche Layout-Divs, so klein wie nur irgend möglich, ob die Seite dadurch wirklich schneller wird? Oder übersichtlicher? Nun, das HTML natürlich schon, aber wenn wir uns anschauen, wieviel sich gegenseitig überschreibendes CSS benötigt wird, merkt schnell, das man die Komplexität nur verlagert hat. Miss Sullivans Beispiel: bei Facebook hatte man vor einem umfassenden CSS-Relaunch 706 CSS Dateien, in denen 261 Mal die gleiche Farbe blau definiert war. Do not repeat yourself?

Und dabei geht’s nicht mal darum, sich gegenseitig den schwarzen Peter zuzuschieben: Komplexität im CSS schadet allen Beteiligten, denn sie drückt auf die Performance. Mein Beispiel ist die tägliche Praxis. Bei einem großen Projekt wurden nahezu nach Lehrbuch beim Schreiben von HTML-Code (und Javascript[1]) auf auf eine ganze Reihe best practices geachtet. Das hat zunächst mal dazu geführt, dass wir zwar schlankes HTML, aber ziemlich viel CSS (und Javascript) über die Leitungen schicken. Dabei ist die Menge an CSS und seine Komplexität eine direkte Folge der semantischen Strukturen im HTML. Aber wo im HTML bspw. nur wenige Klassen stehen, muss im CSS mit unendlich langen Selektorketten auf Elemente zugegriffen werden, was die Menge an CSS erhöht, die Geschwindigkeit des Renderings aber herabsetzt. Nach einigen Jahren ist diese Situation immer schlimmer geworden. Sie ist dabei kaum noch überschaubar, weil man praktisch nur noch mit dem Firebug entscheiden kann, welche CSS-Regel auf ein Element greift. Und die schiere Menge an Code macht es nicht besser. Abhilfe schafft da oft, einfach mal eine Klasse ins HTML zu schreiben, die direkt angesteuert wird. Und die darf dann vielleicht auch mal „blue“ heissen, naja, vielleicht besser „main-color“.

CSS Refactoring?

Will man sich aber, mindestens in Teilen nun aber von dieser Praxis abwenden, dann hat man jetzt den GAU, den man eigentlich vermeiden wollte: Änderungen an der Codebasis und am CSS. Zumindest kann man das Nutzen, um die IE6-Unterstützung endgültig zu droppen und so das ganze CSS etwas zu modernisieren. So stehen nun vieler Orten viele Änderungen in Sachen CSS an. Neues hinzufügen, alte Zöpfe abschneiden. Alte Projekte auf den aktuellen Stand heben.

[1] Noch ein Nebensatz zur Rolle von Javascript: dies wurde erstaunlicherweise viel zu oft genutzt, um die selbst gesetzten Grenzen bei HTML und CSS zu überwinden oder umgehen. Hüstel…

Optimierungen mit CSS media queries

Über die berühmten CSS Media Queries haben wir ja schon viel gehört und gelesen. Mitunter werden sie unnütz für das mobile Web angesehen und ohne eine nennenswerte Zusammenarbeit mit Javascript wird man wohl auch nicht auskommen. Damit wissen wir ja schon einiges. Hier im Blog sind sie seit den letzten kosmetischen Korrekturen im Einsatz (einfach mal die Fenstergröße anpassen oder Codecandies auf dem Kindle 3 aufrufen), sehr schön kann man das auch bei den iAs anschauen.

Was Jason Grigsby vor allem kritisiert ist, dass man um eine Anpassung bspw. für mobile Clients zu erreichen, mehr anstatt weniger Code hinzufügt:

The idea of adding more code—adding more to download—in order to optimize for mobile should be the first clue that this isn’t a good solution.

Das wäre natürlich kontraproduktiv und ist für große Websites, die sowieso schon immer mit ihrem Gewicht zu kämpfen haben auch tatsächlich keine Alternative. Zudem hat man ja auch keine Unterscheidung für die ausgelieferten Medien, bspw. Bilder. Große hochaufgelöste Bilder braucht man bspw. für das iPad, aber nicht für das kleine Display eines Mobiltelefons. Smartphones wie das iPhone4 fallen aus dieser Kritik aber eher heraus, lechzt es doch nach noch höher aufgelösten Bildern als der Desktopwebbrowser. Hier müsste dann je nach Nutzungssituation unterschieden werden.

Allen Lösungen gemein ist im Moment, dass die mit media queries spezialisierten Seiten, nur wenige kleine Effekte anbieten, bspw. schmalere Spalten, verkleinerte Bilder etc. Was aber, wenn die Seiten für das iPad und später auch das iPhone wirklich komplett anders aussehen sollen? Versucht man sämtlichen CSS-Code zu überschreiben, landet man schnell in der Codinghölle und das Gewicht der Seite explodiert. Ich habe mich nun gefragt, mal in Bezug auf das iPad (und andere Tablets) gesehen, deren Nutzung ich weniger als mobile Nutzung betrachte, wie man mit den media queries nun zwar genug, aber eben möglichst wenig CSS-Daten an die Browser schicken kann. Mein derzeitiger Lösungsansatz sieht so aus siehe Update am Ende des Artikels:

[html]<!–[if IE]>
<link rel="stylesheet" href="css/base.css" type="text/css" />
<![endif]–>
<link media="only screen and (min-device-width: 769px)" rel="stylesheet" href="css/base.css" type="text/css" />
<link rel="stylesheet" media="only screen and (min-device-width: 768px) and (max-device-width: 1024px)" href="css/ipad.css" type="text/css" />[/html]

Zur Erklärung: Zunächst mal werden die IEs bedient, die derzeitig nicht in der Lage sind media queries auszuwerten. Der bekommt ganz normal sein CSS geliefert. Die restlichen Stylesheets ignoriert ein IE dann geflissentlich. Alle anderen Browser widerum ignorieren die conditional comments und falls sie eine min-device-width größer 769px haben, laden und zeigen sie das normale base.css. Hernach folgt dann das CSS für das iPad, mit einem Query auf seine Werte abgestimmt.

Soweit zur Theorie. In der Praxis scheint das so zu funktionieren. Lädt man viele verschiedene CSSse, kann das allerdings schnell unübersichtlich werden, da alle nichtmobilen CSSse doppelt aufgeführt werden müssen.

Anregungen und andere Ideen sind mehr als willkommen.

Update: Zwei Tatsachen haben inzwischen dazu geführt, dass ich selbst nicht mehr so überzeugt von dieser Lösung bin: 1. werden ob mit media queries oder ohne immer alle Dateien vom Browser gezogen. Man spart aber ggf. durch weniger CSS-Überschreiben, je nach Art und Größe der Styles; 2. wichtige Info: schon Firefox 3.0 kann keine CSS media queries.