nicht angemeldet
Matthias Apsel
Gunnar Bittersmann
molily
molily
molily
Gunnar Bittersmann
molily
Matthias Apsel
Gunnar Bittersmann
Hi all
Ich habe ein W3C CSS Validator Fehler, denn ich nicht ganz verstehe:
"unbekanntes Medium only screen and (max-width: 920px)"
Betreffen tut er diese Zeile im Code meiner Website:
<link rel="stylesheet" href="/mobile.css" media="only screen and (max-width: 920px)">
Was ich nicht verstehe:
Vielen Dank für Inputs
Kurly
Om nah hoo pez nyeetz, Kurty!
- was ist daran falsch?
syntaktisch imho nichts. only ist auch nur ein Hack, mediaqueries zu verstecken.
- warum zeigt mir der W3C Validator dies an, wenn ich via Firefox Plugin (Webdev.) eine Live Validierung mache ("Validate CSS") - aber nicht wenn ich "Validate Local CSS" mache?
Da ist die Entscheidung, welche Ressource verwendet wird, schon gefallen.
Matthias
Hallo Matthias
syntaktisch imho nichts. only ist auch nur ein Hack, mediaqueries zu verstecken.
Heisst dies, dass es das only ist das er nicht akzeptiert?
Vielen Dank und Grüsse
Kurty
@@Kurty:
nuqneH
<link rel="stylesheet" href="/mobile.css" media="only screen and (max-width: 920px)">
- was ist daran falsch?
Du solltest alles in ein Stylesheet schreiben.
Qapla'
Hallo,
Browser [laden] sämtliche Stylesheets […], nicht nur die gegenwärtig(!!) für Media-Queries zutreffenden.
M.M.n sollten die Browser dieses Verhalten schleunigst ändern. Gibt es da mittlerweile Fortschritte? Es kann ja nicht sein, dass Browser Code herunterladen, den sie niemals interpretieren werden.
Das einzige, was ich gefunden habe: Manche Browser priorisieren den Download von Stylesheets, deren Media Query gerade zutrifft.
Insofern ist es – auch perspektivisch gesehen – nicht dumm, mit unterschiedlichen Stylesheets zu arbeiten.
Dort wird auch die mögliche Lösung diskutiert, mit JavaScript Stylesheets zu laden. Denn die Browserlogik kann man getrost als kaputt bezeichnen.
Mathias
Hi,
Browser [laden] sämtliche Stylesheets […], nicht nur die gegenwärtig(!!) für Media-Queries zutreffenden.
M.M.n sollten die Browser dieses Verhalten schleunigst ändern. Gibt es da mittlerweile Fortschritte? Es kann ja nicht sein, dass Browser Code herunterladen, den sie niemals interpretieren werden.
„Niemals” lässt sich aber doch z.B. bei Abhängigkeit von der aktuellen Viewport-Größe nicht vorhersagen.
Wenn der Nutzer dann die Viewport-Größe ändert, was soll dann passieren? Das zutreffende Stylesheet erst zu diesem Zeitpunkt laden – und so lange, bis das abgeschlossen ist, die bisherigen Styles trotz nicht zutreffender media query anwenden, oder gar einen FOUC für den Übergangszeitraum provozieren …?
MfG ChrisB
Hallo,
Wenn der Nutzer dann die Viewport-Größe ändert, was soll dann passieren? Das zutreffende Stylesheet erst zu diesem Zeitpunkt laden – und so lange, bis das abgeschlossen ist, die bisherigen Styles trotz nicht zutreffender media query anwenden,
Ja. Nicht ideal, aber besser ist es schwer möglich.
So setzt es Mobile Safari im Grunde schon um, wenn er das Laden von Stylesheets hinten anstellt, deren media-Bedingungen gegenwärtig nicht zutreffen. Denn ich kann das Handy z.B. während des Ladens drehen, wodurch sich der Viewport ändert. Dann muss Safari zwangsläufig auf den laufenden HTTP-Request warten.
oder gar einen FOUC für den Übergangszeitraum provozieren …?
Habe ich nicht getestet, ich vermute aber, die bisherigen unzutreffenden Styles bleiben solange aktiv.
Mathias
Hallo Mathias!
Browser [laden] sämtliche Stylesheets […], nicht nur die gegenwärtig(!!) für Media-Queries zutreffenden.
M.M.n sollten die Browser dieses Verhalten schleunigst ändern. Gibt es da mittlerweile Fortschritte? Es kann ja nicht sein, dass Browser Code herunterladen, den sie niemals interpretieren werden.
Ich teile die Bedenken von CrisB diesbezüglich.
Außerdem glaube ich, dass auch (immer noch) der Gedanke, eine Website herunterladen zu können, um sie dann bspw. "offline" wo und wie auch immer zu betrachten, mit ein wesentlicher Grund dafür ist, dass Browser alles herunterladen.
Wobei das immer schwieriger wird - man denke bspw. an @font-face!
Das einzige, was ich gefunden habe: Manche Browser priorisieren den Download von Stylesheets, deren Media Query gerade zutrifft.
Hmmm ..., der verlinkte Artikel kommt aber doch gerade genau zu einem gegenteiligen Ergebnis, nämlich dass die (mit Abstand) schnellste Variante die ist, alle Styles in einer einzigen Datei zusammenzufassen.
Insofern ist es – auch perspektivisch gesehen – nicht dumm, mit unterschiedlichen Stylesheets zu arbeiten.
Die Frage hierbei scheint mir eher zu sein, unter welcher Prämisse, bzw. mit welchem Ziel.
Möchtest du das zu übertragende Volumen reduzieren,
oder die Zeit für das Rendering möglichst kurz halten?
Dort wird auch die mögliche Lösung diskutiert, mit JavaScript Stylesheets zu laden. Denn die Browserlogik kann man getrost als kaputt bezeichnen.
Neben meiner grundsätzlichen "Abneigung" dagegen, das grundsätzliche Layout einer Site von Javascript abhängig zu machen, sehe ich auch ansonsten keine Vorteile in diesem Ansatz.
Kurz gesagt halte ich die Clientseite für die falsche Seite für diese Dinge.
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.
Wobei man sich damit vermutlich mindestens genauso viele neue Probleme einhandelt, wie man evt. bestehende "löst/ umgeht".
Fazit: Im Prinzip ist es also quasi wie die Wahl zwischen Pest und Cholera. Eigentlich will man beides nicht haben ...! ;-)
Aber einen Tod muss man am Ende ja sterben.
Gruß Gunther
Hallo,
Neben meiner grundsätzlichen "Abneigung" dagegen, das grundsätzliche Layout einer Site von Javascript abhängig zu machen, sehe ich auch ansonsten keine Vorteile in diesem Ansatz.
Das habe ich auch nicht empfohlen. Ohne JavaScript kann man ruhig alle Stylesheets referenzieren (z.B. im noscript). Bei aktiviertem JavaScript kann man die gerade benötigten laden.
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.
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.
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.
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.
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.
Mathias
@@molily:
nuqneH
<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.
Und von den Latenzen im Mobilfunknetz auch? Möchte ein Nutzer beim Drehen des Geräts denn wirklich sekundenlang warten, bis sich die Darstellung anpasst? Oder wird er eher das Gefühl haben, da sei was kaputt?
Die Anpassungen für verschiedene MQs sollten i.d.R. nicht allzu viel CSS-Code sein, was spricht dagegen, den gesamten CSS-Code samt allen MQs in einem Stylesheet zu übertragen?
Qapla'
--
„Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)
Jetzt mal vom HTTP-Overhead abgesehen.
Und von den Latenzen im Mobilfunknetz auch?
Ja, ich hatte davon ebenfalls abgesehen.
Die Anpassungen für verschiedene MQs sollten i.d.R. nicht allzu viel CSS-Code sein, was spricht dagegen, den gesamten CSS-Code samt allen MQs in einem Stylesheet zu übertragen?
Praktisch gesehen ist das derzeit die beste Methode, das will ich nicht bezweifeln. Wenn man die Styles sinnvoll aufbaut, dann gibt es flexible Basis-Styles und relativ kleine Anpassungen mit Media-Queries.
Trotzdem, ideal und zukunftssicher ist es nicht, sämtlichen Code zum Client zu pushen. Man tut das nur, weil es unter derzeitigen Netzwerkbedingungen am schnellsten ist und für Webautoren relativ einfach ist. Die Tools, die wir verwenden, sind für das einmalige Bundling, Minification und Gzip-Auslieferung ausgelegt. Sie sind nicht für das Schnüren von tatsächlich benötigten Paketen on-the-fly ausgelegt.
CSS- und JavaScript-Code ist immer sehr kontextbezogen. Die Startseite eine Website oder Web-App verwendet vielleicht 10% des geladenen CSS- und JavaScript-Codes. Das hat dazu geführt, dass Websites immer schwergewichtiger werden. Vor allem bei umfangreichen Websites macht es keinen Sinn, beim Besuchen der Startseite Unmengen an Code zu laden, der mit großer Wahrscheinlichkeit nie gebraucht wird.
Wenn sich also die Netzwerkbedingungen verbessern, sollte man sich über sinnvolles Lazy-Loading Gedanken machen. Googles Module-Server für JavaScript geht in diese Richtung. Einfachere rein clientseitige Lösungen wie Require.js erlauben ebenfalls Pakete, die aus CSS und JavaScript bestehen.
Mathias
Hi Mathias!
Die Anpassungen für verschiedene MQs sollten i.d.R. nicht allzu viel CSS-Code sein, was spricht dagegen, den gesamten CSS-Code samt allen MQs in einem Stylesheet zu übertragen?
Praktisch gesehen ist das derzeit die beste Methode, das will ich nicht bezweifeln. Wenn man die Styles sinnvoll aufbaut, dann gibt es flexible Basis-Styles und relativ kleine Anpassungen mit Media-Queries.
Und die wären noch viel kleiner, wenn es "Lösungen" für die Anpassung von Schriftgrößen gäbe!
Trotzdem, ideal und zukunftssicher ist es nicht, sämtlichen Code zum Client zu pushen. Man tut das nur, weil es unter derzeitigen Netzwerkbedingungen am schnellsten ist und für Webautoren relativ einfach ist. Die Tools, die wir verwenden, sind für das einmalige Bundling, Minification und Gzip-Auslieferung ausgelegt. Sie sind nicht für das Schnüren von tatsächlich benötigten Paketen on-the-fly ausgelegt.
Und dieses "Schnüren" soll dann wie erfolgen? Aber nicht "per Hand", oder?
CSS- und JavaScript-Code ist immer sehr kontextbezogen. Die Startseite eine Website oder Web-App verwendet vielleicht 10% des geladenen CSS- und JavaScript-Codes. Das hat dazu geführt, dass Websites immer schwergewichtiger werden. Vor allem bei umfangreichen Websites macht es keinen Sinn, beim Besuchen der Startseite Unmengen an Code zu laden, der mit großer Wahrscheinlichkeit nie gebraucht wird.
Leider fehlt in der verlinkten Statistik eine Angabe dazu, in wie viel Prozent der Fälle die Startseite auch die tatsächliche Einstiegsseite ist. Aber ich bin mir sicher, du weißt worauf ich hinaus will.
Im übrigen tragen bspw. die Macher von jquery & Co. zu dem Übel bei. Ständig neue Versionen und dutzende verschiedene CDNs machen (effizientes) Caching quasi unmöglich.
Wenn sich also die Netzwerkbedingungen verbessern, sollte man sich über sinnvolles Lazy-Loading Gedanken machen. Googles Module-Server für JavaScript geht in diese Richtung. Einfachere rein clientseitige Lösungen wie Require.js erlauben ebenfalls Pakete, die aus CSS und JavaScript bestehen.
Ich bin nach wie vor nicht davon überzeugt, dass eine "Zerstückelung" wirklich Vorteile bringt. Vielleicht für den Fall, dass ein Besucher tatsächlich nur _eine_Seite einer Webpräsenz besucht.
Aber spätestens beim Aufruf einer zweiten Seite, oder einem Wiederbesuch einer Site, können Browser- und Application Cache ihre Vorzüge voll ausspielen - eine sinnvolle Nutzung vorausgesetzt.
Gruß Gunther
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
Hi Gunnar
Vielen Dank für deine Antwort.
Du sprichts wahrscheinlich die Ladezeiten an, oder?
Da die Stylesheets (meine CSS Dateien) sehr klein sind, finde ich dies nicht so wichtig. Nach dem ersten mal sollten sie sowieso vom Browser gechacht werden.
Aber ich muss es mir überlegen. Wahrscheinlich die einziege Möglichkeit, denn CSS Fehler zu beheben.
Vielen Dank und Grüsse
Kurty
Hi,
Nach dem ersten mal sollten [die Stylesheets] sowieso vom Browser gechacht werden.
Da jetzt alle Welt u.a. auf Basis des NSA-Skandals auf HTTPS umschwenkt, können wir uns was Caching angeht noch auf einigen Spaß gefasst machen – da per HTTPS ausgelieferte Ressourcen per Default von Browsern m.W. nicht gecached werden.
MfG ChrisB
Om nah hoo pez nyeetz, Kurty!
Da die Stylesheets (meine CSS Dateien) sehr klein sind, finde ich dies nicht so wichtig.
Gerade bei kleinen Dateien, die zudem noch eine hohe Kompressionsrate haben können, ist der Unterschied am größten, weil du weniger Anfragen sendest.
Matthias
@@Kurty:
nuqneH
Da die Stylesheets (meine CSS Dateien) sehr klein sind, finde ich dies nicht so wichtig.
Zur Dateigröße kommt der HTTP-Overhead hinzu. Und bei Übertragung übers Mobilfunknetz erhebliche Latenzzeiten.
Qapla'
Hi Kurty,
Da die Stylesheets (meine CSS Dateien) sehr klein sind, finde ich dies nicht so wichtig. Nach dem ersten mal sollten sie sowieso vom Browser gechacht werden.
und trotzdem muss der Browser für jede Datei einen Request rausschicken, um dann bei einer 304er (Not Modified) Antwort auf die gecachte Version zurückzugreifen.
Gruß Gunther