Element Queries

Bild

Wie ihr bereits wisst: wir lieben responsive Webdesign! Bestehend aus fluid Grids und CSS Media Queries hat dieser Trend das Web und uns im Nu erobert. Aber neben all den positiven Eigenschaten gehen die negativen oft unter. Einer davon sind Media Queries.

Das Problem mit Media Queries

Media Queries sind ein Hack! Sie sind ein Mittel zum Zweck. Klar, diesen erfüllen sie sehr gut, aber sie wurden nicht für Responsive Webdesign geschaffen. Woran das liegt jetzt schauen wir uns jetzt genauer an.
Media Queries beziehen sich auf die Größe des Browserfensters. Elemente werden auf Grund der Größe dieses Fensters geändert. Ein Kalender wird zum Beispiel ab einer Browser-Breite von unter 320px in eine vertikale Liste umgewandelt um Platz zu sparen. Super einfach und praktisch, aber derzeit nicht modular umsetzbar.
Bei modularer Programmierung geht es darum Code einmal zu schreiben und überall zu verwenden. So ersparen wir uns unnötigen Codezeilen und die Adaptierung muss bei Änderungen nur an einer Stelle gemacht werden. So sollten und wollen wir arbeiten.
Das Problem tritt auf wenn der Kalender auch anders im Layout eingesetzt wird. Beispiel hierfür wäre eine Sidebar. Dessen Breite ist entscheidend und nicht die des Browsers. Zur Zeit würden wir hier den Kalendar in der Sidebar extra ansprechen, wie es in folgendem Beispiel mit der Modifier-Klasse “calendar–mini” zu sehen ist.
[code language=“css“].calendar li {
display: block;
}
@media all and (min-width: 480px) {
.calendar li {
float: left;
}
}
.calendar–mini li {
display: block;
}
[/code]
Es funktioniert, aber es ist nicht gerade schön. Also was könnte uns hier helfen um wirklich modular zu arbeiten?

Die Lösung heißt Element Queries

Eine zur Zeit heiß diskutierte Lösung wären Element Queries. Diese beziehen sich im Gegensatz zu Media Queries auf das worauf es wirklich ankommt: Elemente. Diese werden mit einem Selektor und einer Bedingung angesprochen. Die Handhabung ist simpel, aber schauen wir uns gleich ein Beispiel an.
[code language=“css“].mainnav (min-width: 400px) {
display: block;
}
[/code]
Sobald die Navigation eine Größe von mindestens 400px erreicht, wird diese angezeigt. Im Fall von unserem Kalender würde ein Element Query so aussehen können:
[code language=“css“].calendar (min-width: 500px) > li {
flaot: left;
}
[/code]
In dem wir unsere Bedingung mit dem Element selbst koppeln, sind wir unabhängig von der Browser Größe und damit auch dem Layout. Es ist jetzt egal ob der Kalander in der Sdiebar oder sonst wo vorkommt. Er passt sich je nach dem ihm zur Verfügung stehenden Platz an. Jetzt ist unser Code auch modular, denn wir müssen ihn nur einmal schreiben und können unseren Kalender überall verwenden. Genial!

Realität

So wo ist der Haken? Wie ihr euch vielleicht schon gedacht habt sind wir hier noch sehr weit von der Realität entfernt. Bist jetzt wird nur darüber diskutiert und man kann nicht davon ausgehen Element Queries in nächster Zeit verwenden zu können. Trotzdem interessant ist aber ein JavaScript Element Query Polyfill von Tyson Matanich.  Hiermit kann man sich schon jetzt mit dem Thema praktisch beschäftigen und die Vorteile testen.
Weiters sind in Bezug auf Element Queries auch noch einige Punkte ungeklärt. Würde man z.B. die Größe eines Elements selbst ändern, greift die Bedingung nicht mehr.
[code language=“css“].element (min-width: 500px) {
width: 200px;
}
[/code]
Zu lange haben wir Media Queries blind vertraut ohne deren Zweck und Sinnhaftigkeit zu hinterfragen. Der Wunsch nach einer neuen Art von Queries wird auf jeden Fall immer stärker und wir können gespannt sein was uns hier noch erwartet. Klar ist, dass es hier Bedarf an Verbesserungen gibt und Element Queries ein guter Ansatz in die richtige Richtung sind.