Features von übermorgen: CSS3 und runde Displays

Tales from the Web side  –  0 Kommentare

Nachdem mit Smartwatches nun der nächste Trend in den Startlöchern steht, sehen sich Webentwickler bereits vor einer neuen Herausforderung: Wie kann die Oberfläche einer Webanwendung an runde Displays angepasst werden? Responsive Design bezieht sich derzeit ja schließlich immer auf rechteckige Displays.

Getreu dem Motto "was es nicht gibt, wird einfach in einer neuen Spezifikation definiert", hat die CSS Working Group Ende September diesen Jahres ein Public Working Draft mit Namen "CSS Round Display Level 1" veröffentlicht. Das Dokument hat im Wesentliche zwei Ziele:

  1. Zum einen sollen Wege geschaffen werden, runde Displays zu erkennen und dementsprechend das CSS jeweils anpassen zu können (Stichwort: Media Queries),
  2. zum anderen sollen neue CSS Layouts definiert werden, die speziell für runde Displays geeignet sind.
Erkennen runder Displays

Um runde Displays zu erkennen, wird vorgeschlagen, innerhalb von Media Queries die neue Eigenschaft device-radius einzuführen, sodass abhängig von der Rundung eines Displays gezielt CSS geladen werden kann:

<link media="screen and (device-radius: 0%)" rel="stylesheet" 
href="normal.css" />
<link media="screen and (device-radius: 50%)" rel="stylesheet"
href="smartwatch.css" />

Die Eigenschaft device-radius soll dabei vom Prinzip her ähnlich zu der bereits vorhandenen Eigenschaft border-radius funktionieren, sprich ein Radius von 0 Prozent beschreibt ein rechteckiges Display, ein Radius von 50 Prozent ein rundes Display, alles dazwischen mehr oder weniger stark abgerundete rechteckige Displays.

Layouts für runde Displays

Neben dem Erkennen von runden Displays ist es natürlich auch wichtig, den Inhalt einer Webanwendung entsprechend dem jeweiligen Display ausrichten zu können. CSS Shapes definiert diesbezüglich bereits die Eigenschaft shape-inside, über die sich Inhalte entlang einer bestimmten geometrischen Form anordnen lassen. Der "CSS Round Display" Working Draft schlägt nun vor, diese Eigenschaft um den Wert display zu erweitern, um den entsprechenden Inhalt automatisch entlang des Display-Randes auszurichten:

#container {
/* Ausrichtung für gegebene Displayform */
shape-inside: display;
}

Darüber hinaus soll über die neue Eigenschaft border-boundary definiert werden können, ob mit CSS definierte Rahmen entlang des Displayrandes gezeichnet werden sollen oder darüber hinausfließen:

#container {
/* Zeichnen des Rahmens entlang Displayform */
border-boundary: display;
}

Bezüglich der Positionierung von Elementen hat man ebenfalls mitgedacht: So soll es zukünftig möglich sein, Elemente innerhalb eines Polarkoordinatensystems ausgehend von einem Referenzpunkt (dem Polarpunkt) und einer Referenzrichtung anzuordnen. Dies kann beispielsweise dann hilfreich sein, wenn bei einem runden Display Elemente ausgehend vom Zentrum des Displays kreisförmig angeordnet werden müssen (man denke nur an die Ziffern auf einer Uhr).

Dazu wird vorgeschlagen, die Eigenschaft position um den Wert polar zu erweitern und zwei neue Eigenschaften polar-angle und polar-distance hinzufügen, um den Winkel von der Referenzrichtung (polar-angle) und den Abstand vom Referenzpunkt (polar-distance) beschreiben zu können:

#container {
position: polar;
polar-angle: 0deg; polar-distance: 50%
}
Fazit

Der Public Working Draft "CSS Round Display" hat zum Ziel, Webanwendungen gezielt für runde Displays anpassen zu können. Ob man sich allerdings damit einen Gefallen tut, lediglich runde Displays zu adressieren, sei mal dahingestellt. Denn was ist, wenn in Zukunft nicht nur für runde Displays, sondern auch für rautenförmige, sternförmige oder beliebig anders geometrisch geformte Displays oder sogar für gebogene Displays entwickelt werden muss? Dann kommt man auch mit "CSS Round Display" auch nicht weiter.

Dieses Problem ist bekannt, wird im Working Draft auch kurz angesprochen und steht noch zur Diskussion: Soll eine einfache, dafür weniger ausdrucksstarke Syntax (wie die oben beschriebene) verwendet werden oder doch eine komplexere, dafür ausdrucksstärkere Syntax (die eventuell auch geometrische Formen über SVG involvieren würde)? Mitdiskutieren kann man übrigens über die öffentliche Mailingliste.