nicht angemeldet
Hallo,
Kurz gesagt halte ich die Clientseite für die falsche Seite für diese Dinge.
Media-Queries lassen sich nunmal nur clientseitig auswerten. Spätestens bei einem Viewport-Resize oder Orientation-Wechsel müsste ein Request zum Server gehen.
Wirkliche "Abhilfe" würde hier imho nur etwas bringen, was es auf der Serverseite ermöglichen würde, nur die tatsächlich aktuell benötigten Resourcen auszuliefern.
Du schlägst doch weiter unten genau das vor, nur mit dem Unterschied, dass du es clientseitig per Javascript machen möchtest, während ich es dann (wenn überhaupt) für "besser" erachten würde, der Client würde die benötigten Informationen (also bspw. die aktuelle Viewportgröße und Ausrichtung) gleich mit dem Request mitschicken, sodass die Auswahl der zutreffenden Resource(n) gleich auf dem Server erfolgen könnte.
Eine solche Modularisierung …
<link rel="stylesheet" src="a.css" media="media query">
<link rel="stylesheet" src="b.css" media="andere media query">
>
> … ist doch eigentlich ideal. Dann lädt der Client das, was er gerade braucht. Jetzt mal vom HTTP-Overhead abgesehen.
Das bedeutet aber, dass du in jedem Fall aus dem einen Request mindestens zwei machst. Denn du müsstest ja immer auch noch das Basis-Stylesheet laden. Oder willst du das komplette CSS jeweils in deine MQ CSS Dateien schreiben!?
Letzteres würde schon von der Wartbarkeit her keinen Sinn machen.
Also "erkaufst" du dir die Einsparung von ein paar KB (hochkomprimiertem) Datenvolumen mit einem zusätzlichen Request. Plus weiterer Requests, sobald die vorher zutreffende Rule nicht mehr matched.
> Dafür ließe sich freilich eine Server-API schreiben, die in einem komplexen Verfahren Stylesheets (nach-)lädt. Aber einfacher als oben geht’s nicht.
Wie gesagt halte ich das aus den o.g. Gründen nicht für eine geeignete Variante, denn imho überwiegen die Nachteile bei weitem den/ die Vorteil(e).
> Ich denke nicht, dass dieses Problem durch ein spezifisches »Protokoll« gelöst wird, das dem Server die Entscheidung ermöglicht, gewisse Daten zu pushen. Die derzeitigen Vorschläge, z.B. HTTP Client-Hints, sind als allgemeine Lösung ungeeignet.
Es gibt ja noch viel mehr Bereiche außer dem reinen CSS. Und mit immer weiter steigender Zahl an verschiedenen APIs und unterschiedlichen Geräten, "bläht" sich der auszuliefernde Code auch immer weiter auf.
Ich halte eine "brauchbare" Lösung auf Serverseite daher für äußerst hilfreich. Denn die Methode jedem Client immer alles auszuliefern, damit er sich dann das "raussucht", was er auch gebrauchen kann, wird absehbar zu immer mehr "unnötigem" Datenvolumen führen.
Javascript als "Lösung" für dieses Problem halte ich dagegen für ein ungeeignetes Mittel. Denn wie soll das praktisch funktionieren?
Soll der Client dann jede seiner "Fähigkeiten" beim Server anfragen, um zu gucken, ob es dazu eine passende Resource gibt?
> Vielleicht wird langfristig HTTP 2.0 weiterhelfen und das parallele Laden sowie das modulare Nachladen von Ressourcen verbessern. Und hoffentlich sinken die Latenz von Mobilverbindungen sowie die Datenübertragungskosten langfristig.
Auch hier sehe ich weniger einen "Vorteil/ Gewinn" darin, wenn Dinge modular (oder on demand) nachgeladen werden, als vielmehr darin, wenn die zu übertragenden Resourcen von vorneherin auf das beschränkt werden könnten, was der jeweilige CLient auch wirklich braucht.
Wenn generell die aktuellen Nachteile von Requests, insbesondere bei Datenverbindungen über die Mobilfunknetze, beseitigt oder zumindest stark vermindert werden, dann schadet das natürlich auch nicht.
Ach ja, aktuelles Beispiel ist doch auch die (verzweifelte) Suche nach einer "brauchbaren" Lösung für HTML Images (Stichworte: 'Retina Displays' und '<picture>').
Gruß Gunther
Matthias Apsel
Gunnar Bittersmann