Der Viewport — das unbekannte Wesen

Seit wir uns mit Responsive Webdesign „herumschlagen müssen“, begegnet uns immer wieder das Wesen der Post-PSD-Ära – der Viewport.

Mittlerweile beherrscht er unser Tun und stellt uns immer wieder Fallen. Wir versuchen ihn zu beherrschen. Wir versuchen ihn einzugrenzen. Oft schlägt dies fehl. An dieser Stelle möchte ich meine Feldforschungsergebnisse der letzten Monate mit Euch teilen.

Vielerorts findet man Anwendungen, die über einen iframe die eingegebene Website „responsive“, also in einem bestimmten Viewport darstellen. Soweit so gut. Das ist durchaus nützlich, spiegelt aber oft nicht das Ergebnis auf den echten Geräten wieder. Man kann dabei lediglich sehen, ob die Layout-Container entsprechend umbrechen oder wie Texte laufen und Bilder sich anpassen, häufig reicht das ja auch. Vieles hängt aber bei der Darstellung auf den mobilen Endgeräten von den verwendeten Media-Queries und dem Viewport-Meta-Tag ab.

Warum ist das so?

Ich möchte nicht zu technisch werden. PPK erklärt den ganzen Zusammenhang zwischen CSS-Pixel und Device-Pixel hier und hier exzellent. Auch bei Apple oder Opera findet man auch gute Zusammenfassungen.

Zuersteinmal erinnern wir uns, dass der Meta-Viewport-Tag gesetzt werden muss, damit die Seite „responsive“ dargestellt wird. Ansonsten wird von den mobilen Browser die Seite auf eine Breite von 980px gezoomt dargestellt. In der HTML5 Boilerplate findet man diese Angabe:

<meta name="viewport" content="width=device-width">

Das wisst Ihr ja sicherlich. Aber hier beginnen schon die Probleme. Nehmen wir an, der Entwickler hat im CSS einen Media-Query (für das iPad) wie folgt definiert:

@media only screen and (min-width: 768px) {
  body {
    color: red;
  }
}

@media only screen and (min-width: 1024px) {
  body {
    color: blue;
  }
}

Beispiel: http://codepen.io/maddesigns/full/ykJzC

In der Desktop-Simulation werden wir ab 1024px blaue Schrift sehen, auf einem Android-Device auch, nicht aber auf dem iPad. Das iPad suggeriert es sei ein Hochkant-Device und meldet hier dem Browser eine Breite von 768px. Auch wenn man das Gerät quer in den Landscape-Modus dreht, bleibt die Gerätebreite auf 768px und der Inhalt wird gezoomt dargestellt. Gleiches passiert auch auf dem iPhone bei 320px. Auf den iOS-Geräten wird man also nie die Landscape-Ansicht erhalten, wenn man nicht zusätzlich für die Viewport-Angabe im Media-Query „and (orientation: landscape)“ angibt. Jetzt könnte man schmollen und twittern wie doof doch Apple ist, aber es ist wie es ist.

Abhilfe für das Verhalten auf iOS ist die zusätzliche „initial-scale=1.0“ im Meta-Viewport. Dann wird auch bei 1024px der Media-Query aktiv. Ich nutzte also immer:

<meta name="viewport" content="width=device-width,initial-scale=1.0">

Kleiner Nachteil: ab und zu kommt es dann zum sogenannte „iOS Zoom Bug“ Verhalten, das aber in iOS6 gefixt ist. Ein Javascript-Bugfix für die älteren Betriebssysteme gibt es von Scott Jehl. Im aktuellen Master der HTML5-Boilerplate wurde das nun auch wieder so eingeführt. https://github.com/h5bp/html5-boilerplate/commit/ff37dba6bf025a00f58b2bb12f7c6a827e6643c5

Apropos „orientation: landscape“ – einigen erzähle ich nichts Neues – aber orientation: landscape/portrait ist nur die Auswertung vom Seitenverhälnis des Browserfensters, und wird nicht anderweitig durch das Device geliefert. DAS kann man also auch auf dem Desktop simulieren.
Beispiel: http://codepen.io/maddesigns/full/Blygt

device-width Media-Querys

Meiner Meinung nach ist es nicht optimal mit device-width Media-Querys zu arbeiten. Aus mehreren Gründen:

– man orientiert sich an bestimmten Devices
– man kann es schlecht am Desktop nachvollziehen
– bräuchte man noch einen dritten Punkt auf der Liste?

Man orientiert sich an bestimmten Devices

Unter Umständen greifen die Anpassungen nur für ein Gerät, könnten aber für viele andere Geräte auch zutreffen, die nur geringfügig andere Werte haben. Viele Media-Query Anpassungen bedeutet also mehr Arbeit, unter Umständen mehr Pflegeaufwand. Zudem ist es bei dem rasanten Anstieg an neu veröffentlichten Geräten kaum noch möglich Schritt zu halten.

Man kann es schlecht am Desktop nachvollziehen

Noch einmal gefährliches Halbwissen vorausgesetzt dürfte bekannt sein, dass viele Geräte bereits ein hochauflösenden Display haben. Die Pixel sind kleiner und enger als bei herkömmlichen Displays. So werden – wie beim Klassiker unter den hochauflösenden Geräten dem iPhone 4 – auf der gleichen Fläche wie zuvor die 4-fache Menge an Pixel untergebracht. In der Breite nicht mehr nur 320 Pixel, sondern 640 Pixelchen. Würde die Website nun auf die Device-Pixel gematcht werden, wäre die Schrift mit Sicherheit zu klein. Deshalb bleibt der Viewport gleich und die Angaben für Schrift und Co. werden umgerechnet. Bildlich gesprochen: Eine Überschrift mit der Größenangabe 24px, wird beim iPhone 4 auf 48px hochgerechnet und erscheint uns dann auf dem hochauflösendem Display wie 24px und nebenbei noch sehr scharf. Für die Angabe der Schriftgröße nehmt ihr aber „rem“ oder „em“, klar oder? ;)

Um auf unseren „Viewport-Switcher“ zurückzukommen, tritt dann natürlich folgendes Problem auf. Ich habe einen Media-Query folgendermaßen angegeben:

/* iPad Retina */
@media only screen and (min-device-width: 1536px) {
  body {
    color: red;
  }
}

Diese Anpassung werde ich auf dem Desktop erst ab einer Bildschirmauflösung von min. 1536px sehen können. Selbst dann könnte man das noch nicht richtig überprüfen, weil u.U. noch ein Media-Query für „Große Desktop-Ansicht“ greift.
Beispiel: http://codepen.io/maddesigns/full/njFcp

Um es einfach und nachvollziehbar am Desktop zu haben, habe ich mir angewöhnt im Sinne von „Mobile first“ alle Media-Querys mit der Angabe „min-width“ zu machen. Falls Anpassungen für hochauflösende Displays zu machen sind, wird dann die Pixel-Ratio bzw. Resolution abgefragt.

@media (-webkit-min-device-pixel-ratio: 1.5),
       (min-resolution: 144dpi),
       (min-resolution: 1.5dppx) {
	/* hiDPI stuff */
}

Diese Anpassungen greifen dann automatisch bei sehr vielen Geräten. Viele ältere Android-Geräte haben ein (laut Android) HiDPI-Display also eine Pixel-Dichte von 1.5.

Zum Beispiel:
– Galaxy S
– Galaxy S2
– Motorola Milestone (Droid)
– HTC Desire,
– Samsung Nexus S

Diese Geräte haben alle einen Display mit 480x800px und einen Viewport im Browser von 320×533px. Ergo könnte man die Geräte mit

@media only screen and (min-device-width: 480px) {
  …
}

ansprechen, bräuchte man aber nicht, sie bekommen automatisch die Anpassungen für „iPhone“ (falls man welche hat).

Zur Pixel-Density noch eine Geschichte: Ein paar Android-Geräte haben ein sehr kleines und schlechtes Display, z.B. das sehr verbreitete Galaxy Y, das Samsung Galaxy Mini oder das HTC Wildfire. Das Display ist 240×320px groß. In einigen „Responsive View“ Online-Tools kann man die Webseite mit einer Breite von 240px darstellen lassen. Das ist schön, aber diese Ansicht wird man auf diesen Geräten nicht bekommen. Zumindest, wenn man die Defaulteinstellungen so lässt. Klingt komisch, ist aber so. Diese genannten Geräte haben eine Pixel-Dichte von 0.75. Hier wird also der Viewport nicht verkleinert, sondern vergrößert und liegt bei unseren Beispielen demnach bei 320×427px, also etwa wie das iPhone 4. Es gibt auch zahlreiche Billig-Tablets, die das genauso so machen.

Achso Tablets…

Mein Lieblingsbeipiel das Nexus 7 macht total verrückte Sachen. Bei der Veröffentlichung des Nexus 7 (1. Generation) hatte es mit dem Chrome gemessen eine Viewport-Breite von 603px bei einem Display von 800×1280px. Einige Monate später wurde das durch irgendein Update (entweder OS oder Browser) korrigiert und der Chrome meldete 600px. Aber alle anderen Browser meldeten etwas anderes, Opera mobile (noch ohne Blink) meldete 800px, Firefox 533px und derUC-Browser 602px. Hier zu sagen „so sieht Ihre Website auf dem Nexus 7 aus“, ist schon fast fahrlässig.

Dann wäre da noch das iPad Mini, das so gar nicht nach den Regeln spielt. Das iPad Mini hat ein 7,9″ Display mit einer Auflösung von 768×1024px, quasi genauso wie das iPad 2, nur eben 20% kleiner (aber leicht höhere Pixeldichte). Das Gerät meldet auch den Viewport und Pixel-Dichte genau wie das iPad 2, also zeigt exakt die gleiche Menge an Inhalten an wie das iPad 2, nur eben 20% kleiner. Es zeigt auch die gleiche Ansicht wie das iPad 3/4 nur nicht so scharf und 20% kleiner. Eine Ansicht „wie im iPad mini“ kann ich am Desktop also schlecht simulieren.

Na doch ich könnte folgendes machen:

iframe.ipadmini {
  transform: scale(0.8);
}

Zu Guter Letzt

Was die meisten* Viewport Resizer Tools (bzw. in dem Fall die Browser) falsch machen, sie beziehen die Scrollbar mit in die Anzeige der Größe ein. WebKit basierende Browsers sind die einzigen Browser, die die Scrollbar in der Berechnung des passenden Media-Query nicht mit einbeziehen. Das kann also je nach System und Browser ein falsche Ansicht ergeben. Mobile Browser haben ja keine richtige Scrollbar.

Nur was tun?

Nicht auf die Ansicht im Desktop-Browser verlassen! Auf echten Geräten testen, z.B. mit Adobe Edge Inspect, Ghostlab oder MIH-Tool. Open Device Labs nutzen oder eröffnen. Ich habe mir mittlerweile einen (klitzekleinen) Park an Devices angeschafft odl.maddesigns.de.

Ein gutes Online-Tool ist Ish von (na klar) Brad Frost (auf http://bradfrostweb.com/demo/ish/ – mal http://roxik.com/cat/ links oben bei URL eingeben und dann rechts oben bei „size“ „Disco“ anschalten => Party! Hier kann man das Layout überprüfen, indem man auf die unterschiedlichen Größen (S, M, L, XL,…) klickt, klickt man mehrfach auf die Button wird der Viewport in dem gewählten Viewport-Bereich leicht angepasst. Eine Verbindung zu irgendwelchen Devicegrößen ist hier bewusst nicht gemacht worden. Persönlich finde ich auch die neue Responsive View im Firefox sehr gut gelungen (seit FF 15, also seit mehr als 6 Wochen drin ;)).

Was man auf dem Desktop auch nicht simulieren kann: Systemschriftarten, deren Fallbacks, und und und … aber das ist wieder eine ganz andere Geschichte.

*es gibt kein Sternchen