Nach Monaten (gefühlten Jahrhunderten) hatte ich wieder Zeit, an meiner Internetseite – diesem Blog genauer gesagt – etwas zu schrauben. Seit IE 6 von Microsoft selbst zu Grabe getragen wurde und IE 9 langsam an Verbreitung zunimmt habe ich etwas unruhig geschlafen. Auch wegen der vielen mobilen Browser…
Die neuen Gestaltungsmöglichkeiten, die die modernen Browser bieten, und die mobile Front mit ihren 480px Breite machten ein Update notwendig. Bewusst habe ich auf Unterstützung von IE6 verzichtet. Stattdessen sollen die webkits dieser Welt besser ausgelastet werden.
Die neuen Möglichkeiten werden nicht um ihrer selbst Willen eingesetzt. Es gehört zur Usability, dem Leser eine angepasste und auf seinem Gerät gut lesbare Version bereit zu stellen. Man nennt es „responsiv“. Die ästhetische Wirkung gehört zwar nicht dazu aber es beeinflusst den Leser. (Auf Internetseiten mit ansprechender Optik verweilen die Benutzer länger als auf hässlichen. Wie weit diese Tatsache auch die Bereitschaft, längere Ladezeiten oder andere Unwegbarkeiten hinzunehmen, beeinflusst, ist mir unbekannt. Schätze es aber als förderlich ein.)
Mein anfänglicher Plan, das responsive Framework responsivegs einzusetzen, schlug nach einem Testversuch mit einer Kopie der Startseite des Blogs fehl. Die starren Breitenangaben des Grids machten die Erhaltung des Designs (bewusst für die volle Browser-Breite und sehr „rechtslastig“ entwickelt) unmöglich. Die flexible und ebenfalls responsive Alternative responsify erwies sich als sehr praktikabel. Nachdem ich mit dem Generator das Grundsystem erstellt habe, konnte ich das HTML stückweise umkopieren und das Ergebnis vergleichen. Die Breiten- und Abstandsangaben in Prozent erlauben die volle Ausnutzung des Platzes im Browser. Leider nicht ganz ohne Probleme: Einige Auflösungen führen zum Fehlen eines Pixels in der rechten Spalte. Dafür kann das Framework ja nichts… (Nur IE7 bekommt auch eines Sonderbehandlung, weil es sich gewaltig verrechnet.)
Die media-queries waren leider nicht ganz so, wie ich es mir vorgestellt hatte. Ich musste (für die Android-Geräte und -Browser, die ich einsetze) etwas nachbessern. Mal ist die Navigation (auf dem Desktop ab ca. 800px rechts) unter dem Artikel zweispaltig (Tablets) und mal einspaltig (Handys). Logo und Slogan bleiben immer oben auf dem Banner mit einem leichten Transparenz-Verlauf des Hintergrunds.
Bei aller Framework-Nutzung und Orientierung an mobilen Geräten (und deren Bandbreiten)… Eines kann keiner ohne eine eigene Version für diese Geräte umgehen: das Herunterladen hoch aufgelösten Bilder. Die Banner z. B. werden nur teilweise gezeigt aber ganz heruntergeladen… Da habe ich auf media-queries von Modernizr zurückgegriffen und setzte dem HTML-Tag eigene Klassen, in der Hoffnung, dass die Browser nicht jede url, die irgendwo im CSS vorkommt, auch herunterladen versuchen. Dazu dient die CSS-Regeln „html.px480 header“, „html.px860 header“ und als default „header“. Bei „header“ suche ich (wie bisher) ein Bild aus und merke mir seinen Namen per Coockie, damit nich auf jeder Seite ein neues Banner-Bild angefordert werden muss.
Ich ergriff die Gelegenheit, die sich durch die Einbindung der Modernizr ergeben, und setzte gleicht auf HTML5. Aside, Footer und Article stören die alten Browser recht wenig. Mit einigen Attributen konnte ich ohne große Mühe sogar den Screenreadern unter die Arme greifen. Per Role-Attribute gibt man den Sehbehinderten die Möglichkeit, durch die Seitenteile semantisch zu navigieren. Mit einer Tastenkombination soll es angeblich möglich sein, sofort die Navigationsleiste oder den Artikelinhalt zu erreichen. (Wenn man sich vorstellt, dass diese Menschen sich ansonten alles erst anhören müssen, um sich in der Struktur der Seite zu orientieren, dann nimmt man die Accessibility etwas ernster…)
Responsify bringt im Zip Modernizr und jQuery mit. Das ist so weit nicht schlimm. Ich benutze es gerne. Nur… warum müssen sie immer getrennt ausgeliefert werden? Die besten HTTP-Requests, die man machen kann, sind diejenigen, die man gar nicht erst startet! jQuery bringt schon WP mit, ohne CDN! So viel Datenschutz muss sein ;-) So habe ich auch unnötige transparente Hintergrundbilder oder RSS-Icons entfernt. (Gleiches Schicksal traf den Anti-Software-Patente-Banner, der vom fremden Server eingebunden wurde… Ich habe meine Meinung dazu nicht verändert. Ich möchte nur meine Leser nicht mit möglichen Unzulänlichkeiten fremder Server oder unnötigen kBs unterwegs belästigen.)
Bei größeren Umbauten lohnt es sich, neue Technologien auszuprobieren. Aus einem direkten Vergleich dreier CSS-Präprozessoren habe ich den stylus ausersehen. Less ginge auch, bietet aber etwas weniger Funtionen. Sass ist mächtiger… aber ich wollte meinem Rechner noch eine Programmiersprache (ruby) mit seinen Abhängigkeiten ersparen. Und wenn man schon die Tastenschläge sparen will, dann aber immer: Einrückungen statt geschweifte Klammern! Python macht vor, wie es funktionieren kann. Besonders hilfreich fand ich die Variablen. Wenn man mehrere Seiten mit ähnlichem Design ausstatten muss, sind sie unentbehrlich. Mixins sind auch ganz nett, besonders für Prefixe. Das CSS abzutippen wäre mir zu viel. Also habe ich meine CSS „decompilieren“ lassen. Es ließ sich auch wieder „compilieren“. So weit, so gut. Dann habe ich noch hier und da nachgebessert: gruppiert, Variablen erstellt, IE-filter-Attribute in Anführungszeichen gesetzt (wenn sie kein literal sind, produziert stylus störendes Müll in der CSSDatei). Mixins wollten auch keine Argumente wie „rgba(x,x,x,y)“ so wie sie waren an die Zeilen durchreichen. „1px 1px 3px rgba(255,255,255,0.5)“ als Variable an das Mixin übereben, funktionierte es wiederum…
Ich hätte gerne noch ein Request eingespart, die „style.css“-Basis aus responsify. Ein „@import ’style.css'“ führte zu keinem include an der angegebenen Stelle. So habe ich auch diese CSS-Datei „decompiliert“ und „@import style“ eingesetzt. Leider ist stylus mit seiner eigener Leistung unzufrieden: vom node.js wird eine Ausnahme geworfen – an einer völlig harmlosen Stelle. Dazu fällt mir nichts ein. Alle Vermutungen erwiesen sich als falsch. Mit „/stylus –include-css –compress xx.styl“ macht stylus eine unangetastete Inklusion der mit „@import“ definierten CSS-Datei in die .style-Datei möglich. Ja mehr noch: das „–compress“ sorgt dafür, dass nach der Umwandlung von .styl in .css Zeilenumbrüche und unnötige Leerzeichen aus diesem Part entfernt werden.
Leider sind die erstellten CSS-Regeln nicht gerade auf Performance getrimmt. Einige :hover-Elemente reagieren recht träge. Auch auf meine Lieblingsschriften möchte ich nicht verzichten… Worauf ich gut verzichten kann, sind WP-Plugins, die einen Rattenschwanz an CSS- oder JS-Dateien für das Syntax-Highlighting einbinden. Dafür gibt es genug Alternativen, was aber Portierung der Auszeichner in den Artikeln bedeutet.
Ich bin mit dem Ergebnis zufrieden. Bei IE habe ich Abstriche gemacht. Die Requests sind halbiert. Die Accessibility ist wenigstens etwas verbessert. Der Sprung ins HTML5-Zeitalter geschafft…