Der große Fehler bei der CSS-Medienabfrage

Veröffentlicht: 2017-05-15

Fühlst du dich manchmal komisch, wenn alle um dich herum etwas tun, von dem du normalerweise denkst, dass es falsch ist [oder zumindest nicht ganz ideal], aber irgendwie scheint niemand aus dem einen oder anderen Grund etwas sagen zu wollen? Es ist ein sehr seltsames Gefühl zu sehen, wie jeder seinen besten Eindruck von einem unglücklichen Beobachter macht. Es erinnert mich irgendwie an die alte Fabel „Des Kaisers neue Kleider“.

Ich habe mich bei CSS-Medienabfragen immer so gefühlt. Warum akzeptieren alle so eine Technologie, die scheinbar einfach nicht funktioniert? Warum sind wir als Gemeinschaft nicht zusammengekommen und haben es auf eine echte und sinnvolle Weise verbessert? Warum haben wir uns nichts Besseres einfallen lassen?

Heutzutage sind CSS-Medienabfragen einfach der funktionale Eckpfeiler des responsiven Webdesigns. Aber es wurde nie für das entwickelt, wofür es heute jeder verwendet, und der Beweis ist in der Praxis. Ich stolpere immer noch oft über Websites, wenn ich ein Tablet-Gerät verwende, die auf den ersten Blick gut gestaltet erscheinen, aber auf Herz und Nieren geprüft einfach ziemlich wackelig aussehen und sich anfühlen.

An dieser Herangehensweise an responsives Webdesign ist etwas grundlegend falsch, das wir noch nicht richtig angesprochen haben, und ich möchte eine der wenigen Stimmen sein, die den Kaiser für seine Nacktheit in diesem Fall anprangert. Glücklicherweise bin ich heutzutage froh, dass es fast keine Chance gibt, auf dem Scheiterhaufen verbrannt zu werden, weil ich diese alternative Sichtweise vertrete.

Was ist falsch an CSS-Medienabfragen?

CSS-Medienabfragen wurden für etwas entwickelt, aber das Ding ist kein responsives Webdesign. Basierend auf meiner Erfahrung sind hier sieben (7) große Probleme, auf die ich gestoßen bin, als ich versuchte, sie für die Arbeit mit Websites zu verwenden:

1. Nicht intuitiv:

„CSS-Medienabfragen sind intuitiv“, hat noch kein Webdesigner gesagt. Die Art und Weise, wie Sie eine Medienabfrage definieren, ist ziemlich einfach, aber es ist nicht immer genau klar, wie sich die Dinge in echten Browsern, auf echten Geräten und in einer Vielzahl von Szenarien entwickeln werden.

 @media nur Bildschirm und (min. Breite: 320px) und (max. Breite: 480px) {
    /** CSS-Regeln gehören hier **/
}

Der obige Code gilt für den Darstellungsbereich, wenn er zwischen 320 und 480 Pixel beträgt. Es ist jedoch nicht genau endgültig [oder intuitiv], wenn Sie etwas Spezifischeres tun möchten, z. B. eine Stilregel anwenden, wenn das Gerät ein Tablet im Querformat ist. Es ist nicht unmöglich, dafür eine Medienabfrage einzurichten, aber es ist definitiv nicht intuitiv – oder endgültig.

2. Begrenzte Konditionalität:

CSS-Medienabfragen sind dynamisch und ermöglichen es Ihnen, bedingte Anweisungen in Ihrem CSS zu definieren. Wenn sich das Ansichtsfenster beispielsweise zwischen diesem und jenem befindet, machen Sie das andere. Sie sind jedoch hauptsächlich auf Viewport-Überlegungen beschränkt, und es gibt viele weitere bedingte Szenarien, die im modernen Webdesign sinnvoll wären.

Mobile Designrichtlinien für die Tab-Leiste

Angenommen, Sie erstellen eine progressive Web-App. Es gibt Zeiten, in denen es sinnvoll wäre, bestimmte UI-Elemente je nach Betriebssystem unterschiedlich zu gestalten. Beispielsweise ist es bei iOS-Geräten üblich, die Tab-Leiste unten zu haben, während es bei Android umgekehrt ist. Wie genau würden Sie das also mit CSS-Medienabfragen zum Laufen bringen?

Das können Sie nicht, weil CSS-Medienabfragen nicht mit Funktionen ausgestattet sind, die Ihnen dies ermöglichen würden. Abgesehen davon gibt es noch zahlreiche andere Anpassungen, die Sie möglicherweise über CSS vornehmen müssen, aber Medienabfragen sind keine Option, wenn Sie unterschiedliche Grade einfacher bis erweiterter Konditionalität benötigen.

3. Nicht nativ erweiterbar:

CSS-Medienabfragen sind Funktionen, die in den Browser integriert sind. Dies bedeutet, dass es nicht nativ erweiterbar ist. Mit anderen Worten, Sie können CSS-Medienabfragen nicht nativ über die CSS-Schnittstelle zusätzliche und erweiterte Funktionen hinzufügen.

Selbst wenn neue CSS-Medienabfragefunktionen vom [langmütigen] Webstandardprozess genehmigt werden, dauert es aufgrund der Allgegenwärtigkeit noch einige Zeit, bis diese Funktionen nutzbar werden. Darüber hinaus ist möglicherweise nicht jede hinzugefügte Funktion für Sie nützlich, sodass Sie einen anderen Weg finden müssen, um Ihre spezifische Herausforderung zu lösen, wenn Sie nicht das bekommen, was Sie wollen.

Natürlich gibt es eine Möglichkeit, CSS zu erweitern, aber Sie müssen JavaScript sehr, sehr gut kennen, und es ist kein Verfahren, das für die meisten Webdesigner praktikabel ist.

4. Nicht zur Nachrüstung geeignet:

Einige mögen das kaum glauben, aber bevor mobile Geräte auftauchten, gab es tatsächlich viele Websites da draußen, und keine davon war für Mobilgeräte optimiert. Infolgedessen mussten diese Websites aus der Desktop-Ära aktualisiert werden.

Leider sind CSS-Medienabfragen für diese Aufgabe keine sehr gute Option. Da diese Websites erstellt wurden, bevor mobile Geräte relevant waren, haben viele von ihnen Designelemente, die sich nicht für responsives Webdesign eignen, z. B. Seitenleisten, tabellenbasierte Layouts, Inhalte mit Registerkarten usw. Auch ein beträchtlicher Teil dieser Websites ist auf einem Content-Management-System (CMS) wie WordPress, Drupal, Magento usw. aufgebaut ist und die effektive Integration von CSS-Medienabfragen [Front-End] aus dem Back-End extrem schwierig bis unmöglich zu koordinieren ist.

Ich musste Websites nachrüsten, die von Magento Enterprise, WordPress und einer Website betrieben werden, die ein benutzerdefiniertes CMS auf Basis von Coldfusion verwendet, und alle Projekte wären mit CSS-Medienabfragen schlichtweg unmöglich gewesen [was alle meine Kunden vor der Verwendung unserer Alternative versucht haben sich nähern].

5. Nicht codierungseffizient:

Die Verwendung von CSS-Medienabfragen, um eine Webseite reaktionsfähig zu machen, erfordert eine Code-Multiplikation in erheblichem Umfang. Aufgrund der Art und Weise, wie diese Direktiven [mit Ihren Breakpoints] arbeiten, müssen Sie in jedem einzelnen Medienabfrageblock individuelle Stilregeln definieren.

 Abschnitt {Breite: 960px;}

/* Porträt */
@media nur Bildschirm und (min. Gerätebreite: 320px) und (max. Gerätebreite: 480px) und (-webkit-min.device-pixel-ratio: 2) und (Ausrichtung: Hochformat) {
    Abschnitt {Breite: 100 %}
}
/* Landschaft */
@media nur Bildschirm und (min. Gerätebreite: 320px) und (max. Gerätebreite: 480px) und (-webkit-min.device-pixel-ratio: 2) und (Ausrichtung: Querformat) {
    Abschnitt {Breite: 100%;}
}

Als ich den obigen Code geschrieben habe, war meine ursprüngliche Absicht, die <section> -Elemente auf meiner Seite auf allen mobilen Geräten fließend [Breite von 100 %] zu machen. Da ich jedoch keine native Geräteerkennungsfunktion habe, muss ich Kompromisse eingehen und eine Stilregel in jedem einzelnen CSS-Medienabfrageblock für Mobilgeräte definieren, um sicherzustellen, dass die neue Eigenschaft in allen relevanten Szenarien angewendet wird.

Das bedeutet, dass die funktionale Effizienz der Stylesheet-Kaskade und die guten Entwicklungsprinzipien von Do-not-Repeat-Yourself in den Hintergrund treten müssen.

6. Erhöht die Komplexität des Workflows:

CSS-Medienabfragen behandeln nur einen sehr spezifischen Aspekt des responsiven Webdesigns, das sich fast ausschließlich auf die Größenänderung des Layouts konzentriert. Ergo, um mehr zu tun, müssen Sie sich auf JavaScript verlassen, um den Unterschied auszugleichen. Dadurch werden zusätzliche Lernanforderungen für Code und Tools eingeführt.

Darüber hinaus bedeutet die nicht endgültige Art und Weise, wie [Medienabfragen] Haltepunkte behandelt, dass Sie mehr Zeit [und Geld] aufwenden müssen, um Ihre Webseiten in zahlreichen virtuellen und/oder physischen Geräten zu testen, um sicherzustellen, dass die Dinge so funktionieren, wie Sie es ursprünglich beabsichtigt haben . Und Sie müssen alles erneut testen, wenn Sie wesentliche Änderungen an Ihrem Layout vornehmen.

Durch die einfache und zielgerichtete Verwendung von CSS-Medienabfragen erhöhen Sie die Anzahl der erforderlichen Schritte zum Erstellen einer modernen Webseite erheblich.

7. Verschlechtert die Leistung:

Aufgrund der Funktionsweise von CSS-Medienabfragen benötigen Sie am Ende viel mehr CSS-Code als sonst, um Ihre Website responsive/mobilfreundlich zu machen. Laut Daten von HTTPArchive.org sind die CSS-Dateigrößen in den letzten fünf Jahren um 114 % gestiegen. Die Zunahme der HTML-Dateigröße erreichte im selben Zeitraum mit etwa 53 % ihren Höhepunkt.

Diese besondere Situation wirkt sich auf die Leistung Ihrer Website aus, da sie nach der Implementierung von CSS-Medienabfragen [in einem responsiven Webdesign-Kontext] langsamer sein wird als je zuvor, insbesondere für mobile Geräte, die weniger als ideale mobile Breitbandnetze verwenden.

Abgesehen von dem Problem der erhöhten Dateigröße gibt es keinen internen Mechanismus in CSS-Medienabfragen, um die Leistung Ihrer Webseite tatsächlich zu verbessern. Dazu müssen Sie fortgeschrittene JavaScript-Techniken nutzen, um diese Verbesserungen zu ermöglichen.

Warum verwenden wir das immer noch?

Wenn ich Sie fragen würde, wie viel Prozent der Websites CSS-Medienabfragen verwenden, was würden Sie antworten? Bei all dem Stress, den Webdesigner im Laufe der Jahre ertragen mussten, würden Sie denken, dass wir den Adoptionsbuckel inzwischen wahrscheinlich überwunden hätten, aber Sie würden sich sehr irren.

Der Prozentsatz der Websites, die CSS-Medienabfragen im gesamten Web verwenden, beträgt etwa 0,2 %. Vergleichen Sie dies mit dem Prozentsatz der Websites, die jQuery verwenden, bei 18 %. Das bedeutet, dass Sie mit 90-mal höherer Wahrscheinlichkeit auf eine Website stoßen, die von jQuery unterstützt wird, als auf eine responsive Website [ohne diejenigen, die zufällig beides sind].

Warum sollte ein Toolkit, das auf einer Kerntechnologie [JavaScript] basiert, die manche Leute für kompliziert und überflüssig zu halten scheinen, einem scheinbar weniger komplexen [CSS] so weit voraus sein, das ein wohl wichtigeres Problem angehen soll [Mobilfunkfreundlichkeit]? ? Offensichtlich ist hier etwas ernsthaft falsch, das die Adoption behindert, und es muss angegangen werden.

CSS-Medienabfragen fanden ihren Weg in Webbrowser, um eine bestimmte Herausforderung zu bewältigen, aber es wurde dann entworfen, um das gesamte Gewicht des responsiven Webdesigns auf seinen Schultern zu tragen. Es ist ein bisschen so, als würde man für ein Blockflötenkonzert der 3. Klasse üben, nur um auf magische Weise in die Royal Albert Hall transportiert zu werden, um ein Posaunensolo von Händels Messiah zu spielen; Keine Messe!

Bei all den Herausforderungen des modernen Webdesigns ist es äußerst überraschend, dass wir immer noch in diesem Geschäft mit Medienabfragen tätig sind. Es geht nicht weit genug, um neben einigen neuen in neuen Bereichen wie progressivem Web-App-Design auch einige wichtige Altlasten zu behandeln. Daher denke ich, dass es an der Zeit ist, eine Alternative zu finden. Aber was wäre das genau?

Was ist die Lösung?

Die Lösung für all das ist eigentlich ganz einfach: JavaScript. Nun, bevor Sie diese Mistgabel aufheben, geben Sie mir eine Chance, es zu erklären.

JavaScript ist die einzige Komponente der HTML5-Trinität, bei der Erweiterbarkeit kein Schimpfwort ist. Sie können HTML-Markup nicht mit mehr HTML erweitern, und Sie können CSS ganz sicher nicht nativ mit CSS erweitern. Sie können JavaScript jedoch nativ mit JavaScript erweitern, und Sie können dasselbe sogar für CSS tun.

Die Manipulation von CSS mit JavaScript wird ausführlich im Web Standards Curriculum des W3C behandelt. Die document.stylesheets DOM-Schnittstelle ermöglicht uns den Zugriff auf die auf eine Webseite angewendeten Stylesheets, einschließlich aller externen Stylesheets, auf die mit dem <link> -Tag von HTML verwiesen wird. Das ist nicht einfach, aber möglich.

Daher sollte ich die anfängliche Antwort erweitern: Es ist nicht einfach JavaScript, es ist JavaScript-unterstütztes CSS . JavaScript ist eine großartige Plattform mit Funktionen, die Sie nicht glauben würden, aber CSS ist der Ort, an dem die meisten Webdesigner arbeiten. Wenn wir irgendwie eine Art funktionale Brücke zwischen diesen beiden schaffen könnten, wo ein Webdesigner einen CSS-Regelsatz schreiben könnte, um die JavaScript-Funktionalität zu nutzen, wäre das eine Art Wendepunkt für das Webdesign.

Zeig mir einen Code

In den letzten zwei Jahren habe ich an einem neuen JavaScript-unterstützten CSS-Toolkit namens rKit gearbeitet. Die ganze Idee bestand darin, ein Designer-freundliches Tool zu entwickeln, das nicht nur CSS-Medienabfragen für responsives Webdesign ersetzt, sondern auch einige der bekannten [und unbekannten] Herausforderungen angeht, denen Webdesigner/-entwickler beim Erstellen moderner Websites und Webapps gegenüberstehen.

Das Konzept hat viel zu bieten, aber hier ist ein kurzes Code-Snippet von CSS zur Erklärung:

 #my-element[rk="if @viewport.width between 320 and 480"]{background-color: #0000ff;}

Bei rKit sehen die CSS-Regeln wie modifizierte Attributwertselektoren aus. Sie können dann einen Ausdruck innerhalb des Wertabschnitts definieren. Die Syntax dieses Ausdrucks ist einfach und intuitiv gestaltet.

Hinweis : rk ist ein konstanter Attributbezeichner.

Der obige Code entspricht funktional der folgenden CSS-Medienabfrage:

 Nur @media-Bildschirm und (min. Gerätebreite: 320 Pixel) und (max. Gerätebreite: 480 Pixel) {
    #mein-element {Hintergrundfarbe:#0000ff;}
}

Mit rKit können Sie jedoch noch viel mehr tun. Hier ist ein weiteres kurzes Beispiel:

 #my-element[rk="if @self.width between 320 and 480"]{background-color: #00ff00;}

Indem wir einfach die Entity-Referenz von @viewport in @self , haben wir im Wesentlichen das eingerichtet, was gemeinhin als Elementabfrage bezeichnet wird. Was nun also passiert ist, dass wenn die Breite von #my-element zwischen 320 und 480 Pixel liegt, die angegebene Deklaration [ background-color: #00ff00 ] gilt.

Statt reiner Deklarationen können Sie auch Klassen verwenden:

 #my-element[rk="if @self.width zwischen 320 und 480 then addClass(c_mobile_320)"]{}
.c_mobile_320 {Hintergrundfarbe: #00ff00;}

Dies ist jedoch nur die Spitze des Eisbergs. Mit rKit können Sie einige ziemlich tolle Dinge tun, wie Ereignisverwaltung, Mutationsbeobachtung, Mengenabfragen, Routing, Datenbindung [bis zu 7-Wege] und eine Menge anderer cooler Sachen, alles mit reinem CSS-Code und ohne zu schreiben eine einzelne Zeile JavaScript.

rKit wird kostenlos und Open-Source sein, wenn es gestartet wird. Außerdem wird es ein spezielles Leistungspaket enthalten, das Sie so installieren können, dass es keine Renderblockierung garantiert, sodass die Webseite wie eine Rakete auf Schienen geladen wird.

Es hat eine ganze Weile gedauert, dies zusammenzustellen, aber es wird bald hier sein [definitiv vor Godot], und ich bin wirklich daran interessiert zu sehen, was Webdesigner [und Entwickler] damit machen können.

Fazit

Ich hoffe, Sie verlassen diesen Beitrag nicht mit dem Gedanken, dass ich CSS-Medienabfragen verprügele, nur weil. Ich bin nicht. Das wäre, als würde man eine Tomate verprügeln, weil sie in einem Obstsalat landet. Wie ich bereits sagte, wurden CSS-Medienabfragen nie für responsives Webdesign entwickelt. Es wurde aus Zweckmäßigkeit kooptiert, und wir alle haben den Fehler begangen, damit alle Probleme zu lösen.

Leider sind wir als Web-Community nie wirklich dazu gekommen, diesen anfänglichen Fehler zu korrigieren, indem wir ihn erheblich verbessert oder eine bessere Alternative herausgebracht haben. Aber leider müssen die Shows weitergehen, Websites müssen erstellt werden und der Fortschritt muss sich durchsetzen. Es ist Zeit für eine Veränderung.

rKit ist nur eine Option und eine Antwort. Es ist nicht das erste und es wird definitiv nicht das letzte sein. Aber zumindest ist es ein richtiger Schritt in die richtige Richtung. Eine Gelegenheit, einige Probleme der Vergangenheit zu beheben und diese dann im Jetzt und in der Zukunft zu beheben. Es wäre interessant zu sehen, wie es zum Status quo passt.

Alles geläutet, einen Fehler zu machen ist kein Selbstzweck; es sollte eine Lernerfahrung sein. Mit etwas Glück lernen wir beim nächsten Mal, wie man das richtige Werkzeug für den richtigen Job verwendet. Ich meine, nur weil Sie auf einer asphaltierten Straße Fahrrad fahren können, heißt das nicht, dass Sie eines zum Nürburgring mitnehmen sollten. Bringen Sie einen Porsche mit!