YellowLeds Weblog v2 - Webdesign

Web ≠ Print – So geht es auch

nospam@example.com (Matthias Mees) — Wed, 16 May 2012 15:50:00 +0200

Es ist nichts Neues, dass die Zusammenarbeit zwischen Webdesignern und Print-Grafikern mitunter etwas schwierig ist. Da treffen zwei Welten aufeinander, die zusammenarbeiten sollen, aber andere Werkzeuge benutzen und unterschiedliche Sprachen sprechen. Der Kollege Marc Hinse hat dazu mal den schönen Artikel Web ≠ Print verfasst.

Ich hatte neulich™ das Vergnügen, einem vorbildlichen Gegenbeispiel zu begegnen.

Ich bat im Gespräch mit dem Kunden um die Kontaktdaten der Grafikerin, die das Logo entworfen hatte, um ggf. Rückfragen zur verwendeten Schriftart und Farbcodes klären zu können. Antwort: „Aber das haben wir doch alles da.“ Man versprach, mir eine PDF-Datei zukommen zu lassen.

Was ich bekam, war – vorbildlich.

Neben dem Logo wies die PDF-Datei die darin verwendete Schriftart inklusive aller verwendeten Schriftschnitte (nebst Schriftprobe) aus und listete sämtliche verwendete Farben auf, und zwar jeweils als:

(Und jetzt merke mir bitte niemand in den Kommentaren an, dass da noch Hex- und HSL-Farbcodes fehlen. Ja, websichere Farben sind heutzutage bedeutungslos.)

Das ist alles, was man als Webdesigner an Informationen zu einem Logo braucht. Ein solches Infoblatt spart dem Webdesigner eine Menge Zeit, vor allem dann, wenn Printler auf die Frage nach den verwendeten Farben nur die (für sie wichtigen, für uns aber völlig irrelevanten) Pantone-Farben benennen können oder offenbar wahllos Schriften einsetzen, ohne sich um Aspekte wie Webfonts und Schrift-Lizenzen auch nur Gedanken zu machen. (Ja, das sind leider echte Praxisbeispiele aus anderen Projekten.)

Ein solches PDF sagt: „Ich weiß, dass Andere meine Arbeit weiterverarbeiten. Deshalb dokumentiere ich sie sorgfältig.“ Ich habe der Kollegin dafür ausdrücklich gedankt. Und ich möchte so etwas jetzt in jedem Projekt haben.

Modernizr: API

nospam@example.com (Matthias Mees) — Sat, 03 Mar 2012 09:11:00 +0100

Zum Abschluss der kleinen Reihe über Modernizr noch ein paar Dinge, die vielleicht über den alltäglichen Einsatz hinausgehen oder nicht für jeden Webentwickler interessant sind – API-Methoden und Möglichkeiten, Modernizr zu erweitern.

Prefixed

Hersteller-Präfixe in CSS sind ein (derzeit) viel diskutiertes Thema. Wie alle anderen CSS-Eigenschaften gibt es auch für diese ein Äquivalent in Javascript, allerdings etwas anders implementiert: Ohne Bindestrich und case-sensitiv. In Javascript wird also aus -moz-transform z.B. MozTransform.

Die Methode Modernizr.prefixed ermöglich es, auf das vom jeweiligen Browser benutzte Präfix zu testen und somit zur Laufzeit nur auf dieses zu reagieren – was eine Menge Code einsparen kann. Die Methode liefert die vollständige Präfixform in Javascript-Format als String zurück. Sie kann noch etwas mehr, auf das ich hier allerdings nicht weiter eingehen möchte – es gibt aber einen sehr ausführlichen ausführlichen Artikel von Andi Smith dazu.

Media Queries

Gerade in Zeiten des Responsive Web Design kann es absolut Sinn machen, Skripte in Abhängigkeit von bestimmten Dimensionen des Bildschirms auszuführen – also im Prinzip das zu tun, was Media Queries in CSS leisten. Das geht etwas primitiver bereits in nacktem Javascript, indem man screen.width abfragt, aber Modernizr.mq stellt hier als Javascript-Methode etwas mehr bereit.

Es testet ein als String übergebenes Media Query, welches einen Typ enthalten sollte und einen Wert enthalten muss, also z.B. Modernizr.mq('only screen and min-width:480px'), zur Laufzeit gegen den aktuellen Zustand des Browserfensters und liefert true/false zurück.

(Und genauso kann man natürlich auch andere Werte des Modernizr-Objektes als Testbedingungen in Javascript verwenden.)

Erweiterungen schreiben

Wer Modernizr erweitern möchte (so weit überhaupt noch nötig, siehe unten), findet auch dafür einige API-Methoden vor. Ich spare es mir, das entsprechende Beispiel aus der Modernizr-Dokumentation hier zu zitieren – angesichts der bereits zur Verfügung stehenden Community-Erweiterungen wird es vorerst kaum nötig sein, eigene zu schreiben.

Falls doch, bietet die API Methoden, um Tests anzulegen (wobei sich die API um das Anlegen der CSS-Klassen und Werte im Modernizr-Objekt kümmert), das so erzeugte Test-Element auf Styles und Events zu testen und dabei auch Browser-Präfixe zu berücksichtigen.

Unerkennbares

Es gibt Features, die Modernizr aus technischen Gründen nicht erkennen kann – die sogenannten Undetectables, die im Modernizr-Wiki in einer Liste gesammelt werden. (Dort findet man auch eine Liste der empfehlenswerten Polyfills.)

Community-Erweiterungen

Es gibt bereits eine Vielzahl von Erweiterungen für Modernizr aus der Community (Stand März 2012: 74). Diese liegen auf GitHub, lassen sich jedoch viel einfacher über den Download-Builder in Modernizr integrieren. Ebenso müssen die API-Methoden zur Nutzung von Prefixed (nicht aber für Media Queries) und zum Schreiben eigener Erweiterungen auf diese Weise ausdrücklich eingebunden werden.

Modernizr: Load

nospam@example.com (Matthias Mees) — Thu, 01 Mar 2012 09:26:00 +0100

Wie im Grundlagen-Artikel bereits angedeutet halte ich den integrierten Script-Loader mittlerweile für die wichtigere Komponente in Modernizr. Bevor wir uns den Loader genauer ansehen nochmals der Hinweis: Er wird nur in generierte Versionen eingebunden, die Entwicklerversion (die z.B. auch im HTML5 Boilerplate enthalten ist) kommt ohne Loader daher.

Warum überhaupt ein Script Loader?

Zunächst mal ist Modernizr.load eigentlich kein Script-, sondern vielmehr ein Ressource-Loader – es kann nicht nur Javascript-, sondern auch CSS-Dateien nachladen, und das asynchron und parallel, wobei sie dennoch in der beabsichtigten Reihenfolge ausgeführt werden. Auch ist Modernizr natürlich bei weitem nicht der einzige Script-Loader – sein großer Vorteil ist die Integration mit Modernizr.

Performance

In Sachen Performance kann es vorteilhaft sein, mehrere kleine Skripte anstatt einer kombinierten Skript-Datei parallel zu laden, obwohl mehrere Skripte logischerweise auch mehrere HTTP-Requests bedeuten – muss es aber nicht. Der eigentliche Vorteil eines Script-Loaders in Zusammenhang mit Polyfills ist, dass man nur die Skripte (nach)lädt, die tatsächlich vom Browser benötigt werden, um Funktionalitäten nachzurüsten, die er nicht nativ beherrscht. Das spart in modernen Browsern in jedem Fall zu übertragende Daten ein. Im Übrigen ist es natürlich auch möglich, über den Loader zusammengefasste Skripte (etwa in Form einer oldie.js) nachzuladen.

Die grundsätzliche Form

Allgemein sieht die Form eines Aufrufes von Modernizr.load so aus:

Modernizr.load([
    {
        test: Modernizr.test,
        yep: Aktion_1,
        nope: [
            Aktion_2,
            Aktion_3
        ]
    }
]);

Wir testen also eine (oder mehrere über Javascript-Operatoren verknüpfte) Bedingung und führen in Abhängigkeit des Ergebnisses entweder die eine oder andere Aktion aus, wobei es nicht notwendig (und wohl auch in den wenigsten Anwendungsfällen sinnvoll) ist, beiden Testergebnissen eine Aktion, aber sehr wohl möglich, einem Ergebnis mehrere Aktionen (also etwa das Laden einer JS- und einer CSS-Datei) zuzuweisen. Wichtig ist allerdings die Reihenfolge, in der ggf. mehrere solcher Anweisungen in der Skriptdatei stehen, denn sie bestimmt auch die Reihenfolge, in der Ressourcen von Modernizr.load nachgeladen werden.

Testen kann man grundsätzlich alles, was Modernizr erkennt, nachladen kann man JS- und/oder CSS-Dateien. Ausführlichere Dokumentation zum Loader findet man auf der Webseite von yepnope, dem „Mutterprojekt“ von Modernizr.load.

Ein praktisches Beispiel

Nehmen wir an, wir wollen für ein Projekt den placeholder-Polyfill von Dirk Ginader verwenden. Nachzuladen wären in Browsern, die placeholder nicht nativ unterstützen, eine JS- und eine CSS-Datei, die Testbedingung ist auch klar:

Modernizr.load([
    {
        test: Modernizr.input.placeholder,
        nope: [
            'placeholder_polyfill.min.css',
            'placeholder_polyfill.jquery.min.combo.js'
        ]
    }
]);

Oder in Klartext formuliert: „Falls der Browser das input-Attribut placeholder nicht unterstützt, lade die CSS- und die JS-Datei nach“ (der Pfad zu den nachzuladenden Ressourcen ist hier relativ zum Dokument, das den Modernizr-Aufruf enthält). Wichtig auch hier: Die Tests basieren auf den tatsächlich vom Browser unterstützten Funktionen, nicht auf dem von ihm (eventuell fälschlich) übermittelten User Agent.

In jedem Fall lohnt sich ein Blick in die Dokumentation der Tests von Modernizr. Zum einen sind diese (zum Teil) nicht hundertprozentig verlässlich – so liefern zum Beispiel Palm Pre/WebOS-Geräte bei Modernizr.touch ein false zurück, da diese Geräte trotz Touchscreen keine Touch-Events unterstützen. Des weiteren reicht es bei einigen Tests nicht, nur auf true/false zu prüfen – dem Test auf Media-Queries etwa sollte man einen Typ und muss man einen Wert mitgeben, also z.B. Modernizr.mq('only screen and (max-width: 768px)').

Selbstverständlich gilt auch hier, dass man sich in jedem Fall einen angepassten build von Modernizr erzeugen lassen sollte, der nur die Tests enthält, die man konkret benutzt, um Performance-Einbußen durch die Einbindung von Modernizr möglichst gering zu halten.

Nachtrag: Schepp hat mich per Twitter auf einen sehr umfassenden Vergleich gängiger Script-Loader aufmerksam gemacht. Danke!

Modernizr: Grundlagen

nospam@example.com (Matthias Mees) — Wed, 29 Feb 2012 09:17:00 +0100

Wenn ich die Suchanfragen dieses Blogs richtig deute, gibt es einen relativ großen Bedarf an (deutschsprachiger) Dokumentation zu Modernizr. Ich versuche mal, diese kleine Javascript-Wunderwaffe zu erklären, so gut ich kann.

Was ist Modernizr?

Modernizr ist eine Javascript-Bibliothek, deren primäre Aufgabe es ist, zu prüfen, ob ein Browser bestimmte HTML5- oder CSS3-Features (aber auch solche, welche nicht einem dieser beiden Standards zuzuordnen sind) nativ unterstützt. Es gibt uns damit die Möglichkeit, auf die Leistungsfähigkeit des Browsers eines Seitenbesuchers individuell zu reagieren, also gegebenenfalls Polyfills einzusetzen oder eine alternative Gestaltung anzuwenden und zwar – und das ist der Clou an Modernizr – eben nicht basierend auf dem sogenannten User Agent (dem nicht sehr zuverlässig zu ermittelnden „Namen“ des Browsers), sondern auf den Ergebnissen diverser Tests, was der Browser tatsächlich beherrscht.

Modernizr testet (derzeit – Version 2.5.3) über 40 Features und stellt basierend auf den Ergebnissen ein Javascript-Objekt bereit, welches die Testergebnisse als true/false-Werte enthält. Zudem fügt es dem html-Element einer Seite eine Reihe von CSS-Klassen hinzu, die ebenfalls anzeigen, ob der Browser die betreffende Eigenschaft nativ unterstützt – also z.B. .boxshadow und .no-boxshadow. Darüber hinaus enthält Modernizr den html5shiv, um veralteten Browsern die neuen HTML5-Elemente „beizubringen“ sowie mit yepnope einen sogenannten Script-Loader, der es ermöglicht, Skripte (aber auch CSS-Dateien) bei Bedarf dynamisch nachzuladen, was einen halbwegs performanten Einsatz von Polyfills möglich macht.

Wie funktioniert Modernizr?

In den meisten Fällen erzeugt Modernizr ein Element, wendet eine bestimmte CSS-Eigenschaft darauf an und fragt besagtes Element ab, was entweder einen sinnvollen Wert oder eben nichts zurückliefert und entsprechend in Werte innerhalb des Modernizr-Objektes bzw. CSS-Klassen umgesetzt wird.

Dabei ist Modernizr relativ leichtgewichtig – minifiziert schlägt ein Modernizr in „Vollausstattung“ mit 17 KB zu Buche. Diesen Wert kann (und sollte) man über den Generator drücken, indem man eine angepasste Version des Skriptes erzeugt, die nur die Tests enthält, die man auch wirklich benötigt. Ebenfalls zu beachten ist, dass der Script-Loader nur über den Generator eingebunden wird; in der Entwicklungsversion ist er nicht enthalten. Ebenso wurde kürzlich respond.js, ein Polyfill für Media-Queries, aus Performance-Gründen aus Modernizr entfernt.

Besagte Tests funktionieren laut Modernizr-Dokumentation in IE6+, Firefox 3.5+, Opera 9.6+, Safari 2+, Chrome, Mobile Safari, Android WebKit, Opera Mobile, Firefox Mobile und (obschon das offenbar noch nicht ausreichend getestet ist) Blackberry 6+. Damit der html5shiv korrekt umgesetzt wird, sollte man die entsprechenden Anweisungen (wie etwa in normalize.css enthalten) im Stylesheet haben.

Wie benutzt man Modernizr?

Modernizr wird im <head> einer HTML-Datei nach den Stylesheet-Referenzen eingebunden. So ist sichergestellt, dass der html5shiv korrekt funktioniert, bei Nutzung der von Modernizr erzeugten CSS-Klassen wird ein „flash of unstyled content“ zumindest minimiert.

Die gängigste Anwendungen für Modernizr dürfte es sein, über die erzeugten CSS-Klassen alternative Gestaltungen bereit zu stellen. „Ersetzt“ man also z.B. den Rahmen eines div-Elementes mit der ID #logo in modernen Browsern durch box-shadow, kann man diesem Element in alten Browsern über .no-boxshadow #logo { } einen „konventionellen“ border zuweisen. Mittlerweile dürfte in Zeiten des progressive enhancements die Möglichkeit, Polyfills über Modernizr.load nachzuladen, sehr viel nützlicher sein. Darauf möchte ich später in einem separaten Artikel näher eingehen.

Für den Moment sollte man bedenken, dass es nur bedingt eine gute Idee ist, für jedes erdenkliche Feature ein Polyfill nachzuladen. Auch dynamisch nachgeladenen Skripte müssen geladen werden und beeinflussen somit die Ladezeit einer Seite, wenngleich „nur“ in Browsern, welche das Polyfill tatsächlich benötigen.

Responsive Ressourcen 2011

nospam@example.com (Matthias Mees) — Wed, 28 Dec 2011 20:03:00 +0100

2011 war das Jahr des Responsive Webdesign. Aus meinen Bookmarks hier die meines Erachtens wichtigsten Quellen aus 2011 dazu:

Grundlagen

ALA: Responsive Webdesign
Mobile first (ist spannenderweise bereits aus 2009)
ALA: Fluid Grids (auch schon aus 2009)
The Responsive Designer's Workflow (Vortragsprotokoll)

Responsive Images

Fluid images und eine Ergänzung dazu via Twitter
Responsive IMGs Teil 1, Teil 2
Adaptive images
Context aware image sizing

`viewport` und Co.

Progressive enhancement/Feature detection

Modernizr documentation
ALA: Taking Advantage of HTML5 and CSS3 with Modernizr
Regressive Enhancement with Modernizr and Yepnope (yepnope ist mittlerweile Bestandteil von Modernizr)

Sammelsurium

Falls Ihr in den Kommentaren weitere Ressourcen ergänzen wollt, denkt bitte daran, dass Links in den Kommentaren mit Textile-Syntax möglich sind, HTML jedoch nicht zulässig ist.