Man hört es immer wieder: Smartphones sind überall und der Anteil jener User, die allein mit einem Laptop oder Desktop ins Internet gehen, schrumpft stetig. Was zwar aus Sicht des Online-Publishings und -Marketings etwas differenzierter betrachtet werden muss, bedeutet für Webdesigner und -entwickler, dass auch in Hinblick auf die verschiedenen Nutzungsweisen Lösungen gefunden werden müssen. Spätestens, seitdem mobile first die Rolle eines weit verbreiteten Design- und Workflow-Prinzips eigenommen hat, tritt die besondere Beachtung verschiedener Endgerätetypen in den Vordergrund.

Oft heißt es dann, eine Webseite müsse für Mobilgeräte optimiert werden. Aber was das im Einzelfall bedeutet, ist nicht immer klar. Denn was zeichnet ein Smartphone, ein Tablet, einen Inkreader etc. aus?

Bildschirmbreite, -ausrichtung oder Touchscreen?

Häufig wird diese Frage beantwortet, indem die Bildschirmgröße herangezogen wird. Dann werden per @media screen and (min-width: …) entsprechende Entscheidungen getroffen. Schließlich sind Smartphones selten mehr als 600 Pixel breit. Alles, was wesentlich breiter ist, tausend, 1200 oder mehr Pixel hat, muss ein Laptop sein. So die landläufige Meinung. Und dann kam der Kindle HDX 8 mit seinen 2560×1600 Pixeln Auflösung auf den Markt. Dabei haben selbst iMacs (ohne Retina-Display), die zweifelsfrei Desktop-Rechner sind, weniger Bildpunkte.

Vielleicht geht es aber auch darum, andere Styles anzuwenden, wenn ein Mobilgerät im Hochformat gehalten wird. Immerhin lassen sich seit der CSS3-Spezifikation solche Fälle in praktisch allen gängigen Browsern mit dem Media-Query @media (orientation: portrait) ansprechen. Aber auch das reicht nicht immer aus, denn einerseits gibt es Desktop-Bildschirme in dieser Konfiguration. Andererseits, noch tückischer, führt das Aufrufen der Tastatur auf so manchem Smartphone dazu, dass der eigentliche Seitenbereich im Browser auf einmal nicht mehr hoch- sondern querformatig wird.

Das unüberschaubare Angebot an Smartphones, Tablets, Laptops usw. lässt das Problem einer wirklich vollkommen gerätefreundlichen Webseite nahezu unlösbar erscheinen. Daher hilft es oft weiter, das konkrete Problem zu definieren. Geht es darum, die Größe oder Anordnung von Seitenelementen zu bestimmen? Dann reichen die obigen Media-Queries tatsächlich meist aus. Geht es darum, einen Hover-Effekt auf einem Gerät darzustellen, das zwar mit einer Maus ausgestattet ist, aber doch meist mit einem Stift bedient wird? Dann hilft das Media-Query @media (hover: none) weiter.

@media (pointer: coarse) – Touchgeräte erkennen

Manchmal sollen aber Radiobuttons oder Checkboxen in ihrer Größe angepasst werden, je nachdem, ob der User eine Maus, ein Trackpad oder eben nur einen Touchscreen zur Verfügung hat. Hier helfen Bildschirmgröße und -orientierung kaum weiter. Schließlich sind längst Tablets in FullHD-Auflösung auf dem Markt. Glücklicherweise gibt es auch dafür ein Media-Query, das allerdings dem Anschein nach kaum genutzt wird:

@media (pointer: coarse) {
	input[type="radio"] {
		width: 30px;
		height: 30px;
		margin: 0 15px;
	}
}

Das Media-Query pointer kennt drei Zustände:

  • „Fine“ für Geräte, deren primäre Eingabemethode recht präzise arbeitet. Das kann eine Maus, ein Touchpad oder etwa ein Eingabestift sein.
  • „Coarse“ für Geräte, deren primäre Eingabemethode eher ungenau ist. Hierzu gehören Touchscreens, aber auch der Nintendo-Wii-Controller oder die Kinect.
  • „None“, wenn kein primäres Zeigegerät vorhanden ist. Das könnte ein Drucker oder ein Screenreader sein. Fraglich auch, ob der ein oder andere Browser eine ausgestöpselte oder ungeladene Maus entsprechend behandelt.

Damit lassen sich bereits die meisten Touchgeräte sinnvoll ansprechen. Übrigens, ohne dass dieser Wert von einem etwaigen Zoom-Level beeinflusst wird. So weit geht es dann doch nicht.

Wer es unbedingt darauf anlegt, bestimmte Modelle in CSS zu erkennen, kann damit und den genannten Media-Queries bereits etliche Geräte unterscheiden. Abgesehen davon, dass es dafür kaum einen sinnvollen Praxiswert gibt, bleibt das Problem, dass manche Endgeräte nicht nur eine, sondern gleich mehrere Eingabemethoden unterstützen. So hat etwa das Microsoft Surface Pro sowohl ein Trackpad, kann über USB-Anschlüsse eine herkömmliche Maus aufnehmen und hat auch noch einen Touchscreen, der nicht nur per Finger, sondern auch mit einem Stift benutzt werden kann. Ein Entwickler-Albtraum.

Immerhin hilft da ein weiteres, ähnliches Media-Query ein Stück weiter:

@media (pointer: coarse) and (any-pointer: fine) {
	input[type="radio"] {
		…
	}
}

Für any-pointer kommen dieselben Zustände wie für pointer infrage, wobei letzteres nur die primäre Eingabemethode erfasst und ersteres prüft ob ein Eingabegerät der Art fine/coarse/none überhaupt vorhanden ist. Die obige Deklaration würde etwa anspringen, wenn ein Nutzer mit einem Controller auf seinem Smart-TV surft, aber auch eine zusätzliche Maus angeschlossen hat.

Webentwicklung mit Augenmaß

Zugegeben, diese Fälle wirken reichlich konstruiert. Alle erdenklichen Geräte umfassend zu berücksichtigen, bleibt zumindest aus praktischen und pragmatischen Gründen ein Wunschtraum. Hinzu kommt, dass die Interpretation der einzelnen Browser, welches Gerät welcher Gruppe zuzuordnen ist, in Grenzfällen wohl kaum vorhersehbar ist. Da wäre es interessant, wie sich die gängigen Browser auf solchen Geräten verhalten, auf denen der User zwischen den Eingabemethoden wechseln kann.

Es lohnt aber, über die Komplexität der möglichen User-Interaktionen nachzudenken und je nach Bedarf gesonderte Lösungen und die entsprechenden Media-Queries zu finden. Daher wird ein Online-Tutorial für digitale Zeichnung wohl eher auf Stift-Tablets eingehen müssen als ein einfaches Künstlerportfolio. Ebenso sollte eine Webseite, die das Feature eines Einkaufszettels bereit hält, auf eine ordentliche Druckdarstellung achten. Und der Online-Auftritt eines Blindenverbandes wird sorgsam für Screenreader und andere Geräte für Sehbehinderte ausgerichtet sein, wohingegen ein kleines Blog darauf eher verzichten wird.

Die Media-Queries pointer und any-pointer können dazu einen wichtigen Beitrag leisten, obgleich die mangelnde Browser-Unterstützung in Firefox und Internet Explorer immerhin ein Drittel der User außen vor lässt. Jedenfalls ist für das Nutzererlebnis bereits viel gewonnen, wenn Klickbereiche auf ein sinnvolles Mindestmaß vergrößert werden können. Und auch so manche kreative Anwendung ließe sich (in Zukunft) mit solchen und anderen Media-Queries elegant umsetzen – warum nicht mal ein Easteregg implementieren, das nur auf Touchscreens und bei gedämpftem Umgebungslicht sichtbar wird?