Responsive Webdesign fühlt sich für einen Entwickler manchmal wie die Entwicklung von fünf Webseiten gleichzeitig an.
Mobile Teststation mit Adobe Shadow/Weinre:
Gründe hierfür sind die Tests auf unterschiedlichen Endgeräten – und vor allem das ständige Groß- und Kleinziehen des Browserfensters. „Das geht einfacher“, sagt sich der gewillte Entwickler, und begibt sich auf die Suche nach einem Verfahren, welches diesen Workflow optimiert. Gesucht, gefunden: Adobe Shadow.
Es handelt sich dabei um ein Programm (Mac/Windows), welches das Surfen auf allen Geräten parallelisiert und mittels Weinre das Remote Debugging des tatsächlichen HTML DOM auf dem Endgerät ermöglicht. Adobe Shadow ist ein Verbund aus lokaler App (Mac & Windows), mobiler App (derzeit: Android, iOS, Kindle) und Browser Extension (Google Chrome). Alle drei Teile sind zwingend erforderlich. Zum Vorgehen: Lokale App starten, mobile App starten, Google Chrome starten, in der Extension das Pairing von lokalem Computer und den verwendeten mobilen Endgeräten durchführen: Fertig!
Jede URL, die in Google Chrome ausgerufen wird, wird automatisch auch auf dem gepairten Endgerät geöffnet. Klickt man auf einen Link und wechselt die Seite, so wechseln auch sämtliche Endgeräte die Seite. Und das Beste kommt noch: Der Remote DOM Inspektor mittels Weinre. Man kann direkt auf dem mobilen Endgerät HTML/CSS debuggen. Javascript Debugging per Konsole und Inspektor ist leider noch nicht möglich, aber wir befinden uns in einer Preview-Phase, da steht sicher noch etwas in der Pipeline. Seit dem 12. April 2012 ist Release 2 der Preview verfügbar.
REM als Alternative zu EM!
Innerhalb von CSS Dateien kann man verschiedene Einheiten für Schriftarten sowie Abmessungen im Allgemeinen verwenden. Die Einheit „px“ ist dabei die gängigste. Die Einheit „em“ rückt gewöhnlich erst nach zunehmender Auseinandersetzung des Web-Entwicklers mit Flexibilität der Styles sowie Barrierefreiheit des eigenen Werkes in den Fokus. Seit CSS3 gibt es eine Ergänzung zur Maßeinheit „em“. Sie wird als „rem“ bezeichnet.
EM vereinfacht die flexible Webentwicklung, denn sämtliche Größen sind nur noch relativ und zwar zur gewählten Fontgröße des Benutzers. Ändert der Benutzer seine gewählte Schriftgröße, passen sich im Optimalfall alle Elemente der Seite an die neue Schriftgröße an.
Einziges Problem: Verschachtelt man EM Angaben, entsteht schnell ein Wirrwarr an kryptischen EM-Dimensionen oder es entstehen gar unerwartete Größenangaben, da EM-Angaben grundsätzlich im DOM vererbt werden. Abhilfe schafft die CSS3 Neuerung REM. REM ist das EM, welches sich immer auf das Wurzelelement im DOM bezieht- also auf den <html> Tag. Damit kann eine verschachtelte, unsortierte Liste bequem relativ formatiert werden ohne einen Reset für tiefere <li> Elemente zu setzen.
Bildergrößen im Responsive Webdesign:
Eine der drei Grundzutaten, die Ethan Marcotte für Responsive Webdesign formuliert, sind fluid images. Das sind Bilder (<img>), die dem Browser zur Skalierung überlassen werden und sicherstellen, dass die Bilder in den umgebenden Container passen. Der Zustand wird hergestellt indem man dem Browser weder im HTML Markup noch im CSS eine genau definierte Größe für das Bild mitteilt. Stattdessen setzt man via CSS eine maximale Breite (max-width) von 100%.
Damit dieses Bild über alle Auflösungen hinweg gut aussieht, muss der größte gemeinsame Nenner der verschiedenen denkbaren Bildauflösungen verwendet werden. Im Klartext bedeutet dies, dass das Bild mit der größten Auflösung eingebunden wird – und der Browser skaliert es für alle kleineren Auflösungen herunter. Mobile Endgeräte, bei denen Bandbreite, Arbeitsspeicher und die Rechenleistung noch immer sehr kostbar sind, laden jedoch auch diese große Version für alle herunter. Hier muss eine Lösung gefunden werden.
Wir folgen dazu dem „mobile first“ Ansatz. Ein Standardbild, optimiert für mobile Endgeräte, wird erst mit höherer Auflösung durch größere Bilder ersetzt. Mit Bordmitteln geht das nicht, also muss eine externe Lösung her. Wir haben zwei grundsätzlich verschiedene Varianten gefunden. Serverseitige oder clientseitige Anpassung der Bilder:
- Die gestellte Anforderung: Lade ein Standardbild in geringer Auflösung. Wenn möglich, lade eine höhere Auflösung des Bildes nach in Abhängigkeit der gegebenen Bildschirmauflösung bzw. Browserbreite.
- Serverseitig: Adaptive Images – Der Ansatz wird genutzt von diesem Skript adaptive-images.com. Zum Vorgehen: Lese die Auflösung des Besuchers mittels Javascript aus und setze ein Cookie, sodass das serverseitige Skript auf diese Information zugreifen kann. Leite alle Bild-Requests serverseitig an ein Skript, welches sodann das Bild abruft, skaliert, cached und in einer für den Client zumutbaren Größe ausliefert. Am HTML Markup muss nichts gedreht werden; nur das kleine JS Snippet (um die Auflösung auszulesen) muss eingebunden werden.
Das Skript funktioniert tadellos. Wir haben versucht dieses Skript zum Ende eines Projekts einzubinden. Jedoch sind vor allem Bilder, die mittels background:cover eingebunden wurden, auf diese Weise ungünstig skaliert worden. Wir haben deshalb den Einsatz abgebrochen. Trotzdem ist die Idee eine gute – und je nach Projekt gut einsetzbar.
- Clientseitig: responsejs – Es geht um das Skript responsejs.com. Grandioses JS Tool, welches sich ganz dem „graceful degradation“-Paradigma folgend unauffällig integriert und nur dann etwas macht, wenn das Endgerät technisch dazu in der Lage ist. „Mobile first“ par excellence. Und so funktioniert es: 1. Teile dem Skript die gewünschten Breakpoints mit. 2. Setze HTML5-data-Attribute mit dem jeweiligen Breakpoint als Postfix. So kann das Skript für jedes HTML-Element und für jeden Breakpoint feststellen, ob andere Daten als die default-Werte gesetzt werden sollen. Zu abstrakt?
Hier ein Beispiel von responsejs.com:
- <img src=”lo-fi.png” data-src481=”medium.png” data-src1025=”hi-fi.png” alt=”example” />
Default Wert des Bildes ist „lo-fi.png“. Ab einer Breite des Browserfensters größer als 480px verwende medium.png, ab einer Breite von mehr als 1024 verwende hi-fi.png. Ist Javascript deaktiviert, werden die zusätzlichen data-src* Attribute ignoriert, das niedrigauflösende Bild „lo-fi.png“ geladen und der Benutzer verpasst nicht allzu viel. Stimmt irgendwo auf dem Endgerät mit der Auswertung der zusätzlichen Attribute etwas nicht, passiert selbiges. Das ist die eingangs genannte graceful degradation.
HTML Meta-Tag viewport:
Zum Abschluss noch etwas für die Bildung. Damit es nun auch der Letzte weiß: Die korrekte Formatierung des Meta Tags, um den viewport für mobile Endgeräte zu fixieren und damit das ungewollte Zoomen zu verhindern, lautet:
- <meta name=”viewport” content=”initial-scale=1.0, maximum-scale=1.0, user-scalable=0, width=device-width”>
Man beachte die Kommata. Es werden keine Semikolons verwendet!
(Bild: © senoldo – fotolia.com)
- Projektausschreibungen zum Thema “Web” auf freelancermap.de
© Copyright bei Georgios Kaleadis
Keine Kommentare zu diesem Eintrag