nicht angemeldet
Gunnar Bittersmann
suit
molily
molily
Gunnar Bittersmann
Matthias Apsel
molily
molily
Gunnar Bittersmann
molily
Guten Tag
Gibt es eine Möglichkeit in eine CSS eine weitere CSS Datei einzubinden?
Die Idee dahinter:
-Erste CSS-Datei mit diversen Media Queries und pro Queries eine eingebundene CSS-Datei
-Einzubindende CSS-Dateien mit dem eigentlichen Code für den Media Queries
-> Es geht um Responsive Design und darum nicht den ganzen CSS Code einzulesen, sondern nur den in der CSS-Datei die mit dem passenden Media Queries verlinkt ist. Also möglichst wenig Daten zu übertragen.
Danke für Eure Unterstützung!
Gruss
Hi,
Gibt es eine Möglichkeit in eine CSS eine weitere CSS Datei einzubinden?
Die Idee dahinter:
-Erste CSS-Datei mit diversen Media Queries und pro Queries eine eingebundene CSS-Datei
-Einzubindende CSS-Dateien mit dem eigentlichen Code für den Media Queries
http://wiki.selfhtml.org/wiki/CSS/@-Regeln#Medienspezifisches_Einbinden_von_Stylesheets
MfG ChrisB
@@ChrisB:
nuqneH
Die Idee dahinter:
-Erste CSS-Datei mit diversen Media Queries und pro Queries eine eingebundene CSS-Datei
-Einzubindende CSS-Dateien mit dem eigentlichen Code für den Media Querieshttp://wiki.selfhtml.org/wiki/CSS/@-Regeln#Medienspezifisches_Einbinden_von_Stylesheets
Nein, das macht überhaupt keinen Sinn, da Browser sämtliche Stylesheets laden, nicht nur die gegenwärtig(!!) für Media-Queries zutreffenden.
AFAIS gibt’s nichts besseres als den gesamten Code incl. aller Media-Queries in einem Stylesheet zu haben.
Es sei denn, man will mit JavaScript ein conditional loading von Stylesheets frickeln.
Qapla'
Guten Morgen,
AFAIS gibt’s nichts besseres als den gesamten Code incl. aller Media-Queries in einem Stylesheet zu haben.
Solange das Responsive Design rein clientseitig ausgehandelt werden soll gebe ich dir Recht. Jedoch schleppt dieser Ansatz doch u.U. eine Menge Overhead mit.
IMO ist der beste Weg für RD die Verlagerung auf die Serverseite. Dann bekommt der Client nur genau den Code und die Ressourcen die er benötigt, egal ob HTML, CSS, JS oder Bilder etc.
Gruß
Ole
AFAIS gibt’s nichts besseres als den gesamten Code incl. aller Media-Queries in einem Stylesheet zu haben.
Solange das Responsive Design rein clientseitig ausgehandelt werden soll gebe ich dir Recht. Jedoch schleppt dieser Ansatz doch u.U. eine Menge Overhead mit.
Wenn der Webdesigner ein Webdesigner ist und nicht nur ein drittklassiger Webdekorateur, dann hält sich der Overhead in Grenzen, weil sich die unterschiedlichen Breakpoints (sofern es welche gibt) sehr viele Ressourcen Teilen.
IMO ist der beste Weg für RD die Verlagerung auf die Serverseite.
Nein, das ist der größte Blödsinn überhaupt :)
Dann bekommt der Client nur genau den Code und die Ressourcen die er benötigt, egal ob HTML, CSS, JS oder Bilder etc.
Welche Bilder vom Server benötigt werden kann der Client aushandeln indem man z.B. Bilder in unterschiedlichen Auflösungen generieren lässt jenachdem was der Client anfordert und das kann per Media-Queries oder JavaScript am Client entschieden werden. Der Overhead dadurch ist minimal aber dafür ist die Sache endlos zuverlässiger als am Server zu raten ohne auch nur ansatzweise irgendwelche relevanten Faktoren zur Verfügung zu haben.
Hallo suit,
Nein, das ist der größte Blödsinn überhaupt :)
Da gehen die Meinungen auseinander. Das ist deine.
Welche Bilder vom Server benötigt werden kann der Client aushandeln indem man z.B. Bilder in unterschiedlichen Auflösungen generieren lässt jenachdem was der Client anfordert und das kann per Media-Queries oder JavaScript am Client entschieden werden. Der Overhead dadurch ist minimal aber dafür ist die Sache endlos zuverlässiger als am Server zu raten ohne auch nur ansatzweise irgendwelche relevanten Faktoren zur Verfügung zu haben.
Sobald man einmal in einer Kombination aus client- und serverseitigen Techniken das Endgerät und seine Möglichkeiten ermittelt hat, kann man sehr granular die benötigten Ressourcen ausliefern.
Klar kann man mit den diversen Möglichkeiten (Media Queries, Responsive Images, Clown Car Technique etc.) den Overhead reduzieren, aber wenn es auf jedes kb und jeden Request ankommt führt kein Weg an einer serverseitigen Lösung vorbei.
Mit Media Queries hat man ggf. überflüssigen CSS-Code auf dem Client und ein Javascript das entscheidet welche Bilder, Polyfills etc. in welchem Fall angefordert werden ist auch Overhead (und eine potenzielle Fehlerquelle) den man sich mit einer serverseitigen Lösung spart.
Gruß
Ole
Sobald man einmal in einer Kombination aus client- und serverseitigen Techniken das Endgerät und seine Möglichkeiten ermittelt hat, kann man sehr granular die benötigten Ressourcen ausliefern.
Da ist das Kind aber schon im Brunnen - du kannst nicht pauschal davon ausgehen, dass sich das Endgerät nicht ändert. Es gibt eine ganze Latte an Geräten, deren Gegebenheiten später geändert werden können.
Man kann das Browserfenster nachträglich kleiner und größer ziehen, man kann einen Orientierungswechsel vornehmen - ja man kann sogar ein Smartphone an einen anderen Monitor docken (z.B. per HDMI an einen Fernseher) und hat gleich ein anderes Display. Wie willst du das serverseitig abfangen, wenn du es nur "1x am Anfang" prüfst?
Mit Media Queries hat man ggf. überflüssigen CSS-Code auf dem Client und ein Javascript das entscheidet welche Bilder, Polyfills etc. in welchem Fall angefordert werden ist auch Overhead (und eine potenzielle Fehlerquelle) den man sich mit einer serverseitigen Lösung spart.
Mit einer serverseitigen Lösung bist du permanent "einen Request zu spät" dran - das erzeugt unnötig "Latenz" und ebenfalls entsprechend Overhead, dadurch gewinnt man nichts.
Hallo
Da ist das Kind aber schon im Brunnen - du kannst nicht pauschal davon ausgehen, dass sich das Endgerät nicht ändert. Es gibt eine ganze Latte an Geräten, deren Gegebenheiten später geändert werden können. [...]
Das gilt natürlich für fast jedes Gerät, aber nur weil sie geändert werden können, heißt es nicht, dass sie das auch werden.
Gerade bei Mobilen Endgeräten und Tablets dürfte das häufigste Szenario der Orientation Change sein. Kenne ich das Gerät, weiß ich von vorne herein welche Anforderungen nach dem Change gestellt werden. Dafür muss ich keine neue Ressourcen anforderen.
Einige Mobile Endgeräte kann man auch in ein Tablet stecken oder ein externes Display anschließen. Aber das Eintreten dieses Anwendungsfalles liegt, abgesehen von sehr spezialisieren Projekten weit unter einem Promille.
Ein Resize des Viewports auf Mobilen Endgeräten liegt noch weit darunter.
Die Wahrscheinlichkeit, dass ein User während einer "Session" die Größe des Viewport ändert liegt i.d.R. (ja es gibt Ausnahmen, aber wo gibt es die nicht) bei weit unter 5% (bis hin zu unter 1%; Die Zahlen basieren auf Auswertungen einiger großer Seiten und den UX Studien einiger darauf spezialisierter Agenturen).
Wie willst du das serverseitig abfangen, wenn du es nur "1x am Anfang" prüfst?
I.d.R. brauche ich das nicht, da die oben aufgeführten Situationen meistens quantitativ und qualitativ nicht so relevant sind, dass sie auch ohne eine 100% angepasste Seite auskommen.
Mit einer serverseitigen Lösung bist du permanent "einen Request zu spät" dran - das erzeugt unnötig "Latenz" und ebenfalls entsprechend Overhead, dadurch gewinnt man nichts.
Beim ersten Aufruf gebe ich dir Recht. Danach, so haben multivariate Tests gezeigt, bin ich mit meinem Ansatz (in den getesteten Projekten) durchweg schneller.
Natürlich ist das auch immer projektspezifisch zu sehen. Je nach Projekt kann sich eine clientseitige oder eine severseitige Lösung oder irgendwas dazwischen als das Optimum erweisen. Die perfekte Lösung für alle Anwendungsfälle gibt es nicht.
Gruß
Ole
Meine Herren,
Die Wahrscheinlichkeit, dass ein User während einer "Session" die Größe des Viewport ändert liegt i.d.R. (ja es gibt Ausnahmen, aber wo gibt es die nicht) bei weit unter 5% (bis hin zu unter 1%; Die Zahlen basieren auf Auswertungen einiger großer Seiten und den UX Studien einiger darauf spezialisierter Agenturen).
Klingt interessant. Kannst du die Quelle auch benennen?
Hallo,
Klingt interessant. Kannst du die Quelle auch benennen?
Leider nein. Diverse Vertragswerke hindern mich daran, da es im beruflichen Umfeld ablief.
Gruß
Ole
Hi!
Man kann das Browserfenster nachträglich kleiner und größer ziehen, man kann einen Orientierungswechsel vornehmen - ja man kann sogar ein Smartphone an einen anderen Monitor docken (z.B. per HDMI an einen Fernseher) und hat gleich ein anderes Display. Wie willst du das serverseitig abfangen, wenn du es nur "1x am Anfang" prüfst?
Und wie fängst du das überhaupt ab?
AFAIK gibt es dafür zumindest momentan noch gar keine Lösung.
Die letzten "original" Opera Browser waren/ sind AFAIK auch die einzigen Browser, die bei Vorhandensein, im Fullscreen Modus die Styles für den Medientyp "Projection" verwenden.
Ansonsten wendet der Browser immer die Styles an, die zu dem "originalen" Display des Geräts "passen", auf dem er läuft.
Gruß Gunther
Hallo,
du kannst nicht pauschal davon ausgehen, dass sich das Endgerät nicht ändert. Es gibt eine ganze Latte an Geräten, deren Gegebenheiten später geändert werden können.
Dann ist es halt so. Es ist ja nicht so, als würde die Seite dann nicht mehr funktionieren.
Eine serverseitige Erkennung und ggf. getrennte Seiten für Mobilgeräte (zumindest Smartphones) und größere Geräte haben ihre Gründe. Es gibt viele Sites, wo das nicht nötig ist, und man sollte den Mehraufwand nach Möglichkeit vermeiden. Trotzdem gibt es verschiedene Bedingungen und Anforderungen:
Mathias
Die Use-Cases einer Mobilseite sind i.d.R. anders. Die UX sollte entsprechend angepasst werden. D.h. die Inhalte sind andere, die Präsentation ist anders, die Bedienung ist anders.
Ich habe die Thematik natürlich nur angerissen. Tiefergehende Artikel dazu:
http://jimramsden.com/notes/no-more-mobile
http://www.smashingmagazine.com/2013/02/25/there-is-no-mobile-internet/
Hallo,
Da ist das Kind aber schon im Brunnen - du kannst nicht pauschal davon ausgehen, dass sich das Endgerät nicht ändert. Es gibt eine ganze Latte an Geräten, deren Gegebenheiten später geändert werden können.
Neben dem sehr guten Raten am Server kann man dem User mal ganz locker eine Möglichkeit geben, seine Einstellung mit dem Druck auf ein Knöpfchen zu ändern.
Viele Grüße
Siri
Guten Morgen,
AFAIS gibt’s nichts besseres als den gesamten Code incl. aller Media-Queries in einem Stylesheet zu haben.
Solange das Responsive Design rein clientseitig ausgehandelt werden soll gebe ich dir Recht. Jedoch schleppt dieser Ansatz doch u.U. eine Menge Overhead mit.
IMO ist der beste Weg für RD die Verlagerung auf die Serverseite. Dann bekommt der Client nur genau den Code und die Ressourcen die er benötigt, egal ob HTML, CSS, JS oder Bilder etc.
Leider sind aber die Möglichkeiten auf der Serverseite sehr begrenzt, d.h. eigentlich kannst du nur den UA String auswerten.
Und der HTML Code sollte sich doch nicht unterscheiden, egal um welches Endgerät es sich handelt, oder?
Beim CSS ist es imho auch nicht erforderlich, da man allenfalls für ältere IEs (8 + 9) deutlich "abweichende" Styles benötigt. Diese kann man aber "bequem" per Conditional Comments einbinden. Da sich diese Browser aber nicht auf mobilen Endgeräten wiederfinden, ist der Umstand, dass diese User einen gewissen Overhead und/ oder einen zusätzlichen Request haben, zu "verschmerzen".
Und mal ehrlich - von was reden wir denn hier eigentlich, wenn es um den "Overhead" geht? Das sind doch i.d.R. maximal 5KB - 10KB, die noch dazu auch nur ein einziges Mal übertragen werden müssen, weil danach im Cache.
Bei den Bildern sieht die Sache momentan noch etwas schwieriger aus.
Grundsätzlich verwende ich, wo möglich, SVG (bzw. gezippte .svgz) Grafiken und eine Standardgrafik (gif|jpg|png) als Fallback.
Gerade beim RWD halte ich persönlich nichts davon, irgendetwas clientseitig auszuhandeln. Denn erstens kann die Übertragung der dafür notwendigen Resourcen relativ lange dauern, sodass es zu "unschönen" Verzögerungen kommen kann. Und gerade auch bei mobilen Endgeräten darf man den "Aufwand" für jedes (neue) Rendern der Seite auch nicht vernachlässigen.
Gruß Gunther
Hallo,
Und der HTML Code sollte sich doch nicht unterscheiden, egal um welches Endgerät es sich handelt, oder?
Es ist unter Umständen sinnvoll, dass er sich unterscheidet.
Und mal ehrlich - von was reden wir denn hier eigentlich, wenn es um den "Overhead" geht?
http://www.stevesouders.com/blog/2013/04/05/page-weight-grows-24-year-over-year-not-44/
Mathias
Hallo,
Und der HTML Code sollte sich doch nicht unterscheiden, egal um welches Endgerät es sich handelt, oder?
Es ist unter Umständen sinnvoll, dass er sich unterscheidet.
Und welche Umstände wären das? ;-)
Könntest du bitte mal ein Beispiel aufzählen?
Und mal ehrlich - von was reden wir denn hier eigentlich, wenn es um den "Overhead" geht?
http://www.stevesouders.com/blog/2013/04/05/page-weight-grows-24-year-over-year-not-44/
Auch hier kann ich ohne weiteren Kommentar "die Aussage" der Statistik(en) nicht erkennen!?
So liegt bspw. die Größe von CSS Dateien durchweg unter 40KB und die Anzahl der Requests ziemlich konstant um 3,5.
Wobei das imho so gut wie gar keine Aussagekraft hat.
Denn wenn ich bspw. eine Hintergrundgrafik per Data-URL in meine CSS Datei einbinde, dann wird diese dadurch zwangsläufig größer, dafür habe ich aber einen Request eingespart.
Gruß Gunther
Hallo,
Und welche Umstände wären das? ;-)
Die habe ich in https://forum.selfhtml.org/?t=215390&m=1475087 zu schildern versucht, siehe auch die Links.
Könntest du bitte mal ein Beispiel aufzählen?
https://github.com/blog/1559-github-s-on-your-phone
Bspw. https://github.com/chaplinjs/chaplin (Man vergleiche Mobile-UA mit Desktop-UA)
Die Mobilansicht hat hier anderes HTML, CSS und JavaScript, und es gibt einen User-Agent-Switch. »Pfui!«, werden da viele sagen, oder gar »es gibt kein ›Mobile Web‹!«. Das halte ich so pauschal für unzutreffend. Die Mobilseite von GitHub ist (auf Mobile) weitaus schneller und besser bedienbar als die Desktop-Site, aber die Features der Desktop-Site will ich auch nicht missen.
So liegt bspw. die Größe von CSS Dateien durchweg unter 40KB und die Anzahl der Requests ziemlich konstant um 3,5.
CSS ist ja nur ein Faktor. Die Gesamtdatenmenge einer üblichen Desktop-Site ist frappierend. Das heißt nicht unbedingt, dass die Autoren etwas falsch gemacht haben – heutige Desktop-Sites sind eben inhaltlich und grafisch komplex und clientseitig dynamisch. Auf Geräten mit anderen Fähigkeiten und Eigenschaften will ich diesen ganzen Kladderadatsch nicht laden, dafür anderen Code.
Denn wenn ich bspw. eine Hintergrundgrafik per Data-URL in meine CSS Datei einbinde, dann wird diese dadurch zwangsläufig größer, dafür habe ich aber einen Request eingespart.
Ja. Das ist ein Argument für das dynamische, selektive Laden von Stylesheets.
Mathias
Hallo,
Und welche Umstände wären das? ;-)
Die habe ich in https://forum.selfhtml.org/?t=215390&m=1475087 zu schildern versucht, siehe auch die Links.
Könntest du bitte mal ein Beispiel aufzählen?
https://github.com/blog/1559-github-s-on-your-phone
Bspw. https://github.com/chaplinjs/chaplin (Man vergleiche Mobile-UA mit Desktop-UA)Die Mobilansicht hat hier anderes HTML, CSS und JavaScript, und es gibt einen User-Agent-Switch. »Pfui!«, werden da viele sagen, oder gar »es gibt kein ›Mobile Web‹!«. Das halte ich so pauschal für unzutreffend. Die Mobilseite von GitHub ist (auf Mobile) weitaus schneller und besser bedienbar als die Desktop-Site, aber die Features der Desktop-Site will ich auch nicht missen.
OK, in solchen Fällen (imho eher die Ausnahme, denn die Regel) mag das sicher sinnvoll sein. Wobei sich für mich dann wiederum die Frage nach einer nativen App stellen würde, ob der größeren Möglichkeiten die speziellen Gerätefähigkeiten anzusprechen/ auszunutzen.
So liegt bspw. die Größe von CSS Dateien durchweg unter 40KB und die Anzahl der Requests ziemlich konstant um 3,5.
CSS ist ja nur ein Faktor. Die Gesamtdatenmenge einer üblichen Desktop-Site ist frappierend. Das heißt nicht unbedingt, dass die Autoren etwas falsch gemacht haben – heutige Desktop-Sites sind eben inhaltlich und grafisch komplex und clientseitig dynamisch. Auf Geräten mit anderen Fähigkeiten und Eigenschaften will ich diesen ganzen Kladderadatsch nicht laden, dafür anderen Code.
Wenn die Desktop-Site wirklich "unvermeidbar" so "vollgestopft" ist, ist das dann ggf. eben ein Fall, wo sich eine separate "Mobile" Version der Site anbietet. Natürlich um den Preis des nahezu doppelten Pflegeaufwands. Dafür stellen sich dann aber eine ganze Reihe der Fragen, über die wir hier diskutieren, nicht.
Es ist also je nach "Art & Umfang" der Site eine Frage für welche Variante man sich am besten entscheidet - und diese Frage muss man im Vorfeld klären!
Gruß Gunther
Hallo Gunther,
Leider sind aber die Möglichkeiten auf der Serverseite sehr begrenzt, d.h. eigentlich kannst du nur den UA String auswerten.
Darum findet auch einmalig eine clientseitige Erfassung statt, vergleichbar mit z.B. Modernizer.
Und der HTML Code sollte sich doch nicht unterscheiden, egal um welches Endgerät es sich handelt, oder?
Doch, auch das kann möglich/erforderlich sein.
Beim CSS ist es imho auch nicht erforderlich, da man allenfalls für ältere IEs (8 + 9) deutlich "abweichende" Styles benötigt. Diese kann man aber "bequem" per Conditional Comments einbinden. Da sich diese Browser aber nicht auf mobilen Endgeräten wiederfinden, ist der Umstand, dass diese User einen gewissen Overhead und/ oder einen zusätzlichen Request haben, zu "verschmerzen".
Windows Phone 7 setzt(e) auf den IE7.
Und mal ehrlich - von was reden wir denn hier eigentlich, wenn es um den "Overhead" geht? Das sind doch i.d.R. maximal 5KB - 10KB, die noch dazu auch nur ein einziges Mal übertragen werden müssen, weil danach im Cache.
Jedes kb und jeder Request zählen. Jede Sekunde Ladezeit kostet u.U. Geld. Je Nach Projektumfang und Granularität der Anpassungen können da auch dreistellige kb auflaufen.
Gruß
Ole
Hallo Ole,
Leider sind aber die Möglichkeiten auf der Serverseite sehr begrenzt, d.h. eigentlich kannst du nur den UA String auswerten.
Darum findet auch einmalig eine clientseitige Erfassung statt, vergleichbar mit z.B. Modernizer.
Die immer nur dann funktioniert, wenn JS verfügbar + aktiviert!
Ich finde es ehrlich gesagt ziemlich paradox, dass wir auf der einen Seite alles unternehmen, um CSS soweit zu nutzen, dass wir für RWD nicht (mehr) auf JS angewiesen sind, und dann auf der anderen Seite doch wieder auf JS zurückgegriffen wird, und das teils in der Form, dass die Seite ohne nicht "vernünftig" angezeigt wird, bzw. benutzbar ist.
BTW: Ich verwende auch eine Kombi aus serverseitigem und clientseitigem Check. Den clientseitigen aber im Prinzip nur zur Kontrolle, bzw. Korrektur des Serverseitigen. Heißt, wenn clientseitig nicht möglich, bleibt es bei den serverseitigen Ergebnissen/ Vorgaben.
Und der HTML Code sollte sich doch nicht unterscheiden, egal um welches Endgerät es sich handelt, oder?
Doch, auch das kann möglich/erforderlich sein.
Wie schon in der Antwort an Mathias - bitte konkrete Fälle/ Umstände nennen.
Ansonsten ist die Diskussion eher rein hypothetischer Natur ...! ;-)
Beim CSS ist es imho auch nicht erforderlich, da man allenfalls für ältere IEs (8 + 9) deutlich "abweichende" Styles benötigt. Diese kann man aber "bequem" per Conditional Comments einbinden. Da sich diese Browser aber nicht auf mobilen Endgeräten wiederfinden, ist der Umstand, dass diese User einen gewissen Overhead und/ oder einen zusätzlichen Request haben, zu "verschmerzen".
Windows Phone 7 setzt(e) auf den IE7.
Ja und? Den wolltest du heutzutage auch immer noch unterstützen?
Und mal ehrlich - von was reden wir denn hier eigentlich, wenn es um den "Overhead" geht? Das sind doch i.d.R. maximal 5KB - 10KB, die noch dazu auch nur ein einziges Mal übertragen werden müssen, weil danach im Cache.
Jedes kb und jeder Request zählen. Jede Sekunde Ladezeit kostet u.U. Geld. Je Nach Projektumfang und Granularität der Anpassungen können da auch dreistellige kb auflaufen.
Ersteres ist sicherlich richtig. Aber gerade im mobilen Bereich sehe ich Vorteile darin die Anzahl an Requests zu minimieren und dafür ggf. einmalig 20KB mehr an Datenvolumen in Kauf zu nehmen.
Wenn der Overhead solche Größenordnungen annimmt, wie von dir genannt, dann liegt in meinen Augen eher schon ein "konzeptioneller Fehler" vor.
Gruß Gunther
Hallo,
Die immer nur dann funktioniert, wenn JS verfügbar + aktiviert!
Das ist richtig, sind aber zumindest in den von mir betreuten und/oder untersuchten Projekten über 99% der Clients.
Anhand der rein serverseitig verfügbaren Daten lassen sich mittels einer umfangreichen Device Database die Möglichkeiten der Endgeräte auch schon sehr gut ermitteln.
Ich finde es ehrlich gesagt ziemlich paradox, dass wir auf der einen Seite alles unternehmen, um CSS soweit zu nutzen, dass wir für RWD nicht (mehr) auf JS angewiesen sind, und dann auf der anderen Seite doch wieder auf JS zurückgegriffen wird, und das teils in der Form, dass die Seite ohne nicht "vernünftig" angezeigt wird, bzw. benutzbar ist.
Die Anzahl der Clients ohne aktives JS ist, zumindest in meinen Beobachtungen, von "verschwindend gering" weiter zurückgegangen.
Davon ab sollte eine Seite natürlich auch ohne JS funktionieren. Auch dafür kann die gezielte Auslieferung von Code sinnvoll sein. So bekommt der No-JS Client eben auch keine JS-Libs etc. ausgeliefert.
Wie schon in der Antwort an Mathias - bitte konkrete Fälle/ Umstände nennen.
Ansonsten ist die Diskussion eher rein hypothetischer Natur ...! ;-)
Tabellen sind immer so ein Fall. Ist genug Platz (Viewport) und Bandbreite vorhanden können umfangreiche Daten ohne Probleme in durchaus großen Tabellen ausgeliefert werden. Auf kleineren Viewports und/oder mit geringerer Bandbreite kann es durchaus sinnvoll sein die Daten in anderer Form aufzubereiten und initial nur eine Teilmenge an den Client zu schicken.
Windows Phone 7 setzt(e) auf den IE7.
Ja und? Den wolltest du heutzutage auch immer noch unterstützen?
Natürlich. Es sind noch erstaunlich viele Windows Phone 7 Geräte unterwegs. Vor allem, da sich die meisten dieser Geräte nicht auf Windows Phone 7.5 aktualisieren lassen.
Ersteres ist sicherlich richtig. Aber gerade im mobilen Bereich sehe ich Vorteile darin die Anzahl an Requests zu minimieren und dafür ggf. einmalig 20KB mehr an Datenvolumen in Kauf zu nehmen.
Natürlich muss man immer kb gegen Requests abwägen.
Wenn der Overhead solche Größenordnungen annimmt, wie von dir genannt, dann liegt in meinen Augen eher schon ein "konzeptioneller Fehler" vor.
Nein. Je granularer die Adressierung ist, desto mehr Code fällt an. Im clientseitigen RD macht es doch auch einen Unterschied ob 5 oder 50 Media Queries definiert werden.
Und wenn man die möglichen Kombinationen von Viewport, Orientierung, Touch, OS, Browser, etc. mal hochrechnet kommen da deutlich mehr bei rum.
Gruß
Ole
Hallo,
Die immer nur dann funktioniert, wenn JS verfügbar + aktiviert!
Das ist richtig, sind aber zumindest in den von mir betreuten und/oder untersuchten Projekten über 99% der Clients.
Die Frage ist halt immer die, wie viel sind das eine Prozent?
Und kann man darauf "verzichten"?
Mich würde aber mal interessieren, wie du auf die Zahlen kommst?
Anhand der rein serverseitig verfügbaren Daten lassen sich mittels einer umfangreichen Device Database die Möglichkeiten der Endgeräte auch schon sehr gut ermitteln.
Und wieder eine Sache mehr, die laufend gepflegt und aktualisiert werden muss!
Ich finde es ehrlich gesagt ziemlich paradox, dass wir auf der einen Seite alles unternehmen, um CSS soweit zu nutzen, dass wir für RWD nicht (mehr) auf JS angewiesen sind, und dann auf der anderen Seite doch wieder auf JS zurückgegriffen wird, und das teils in der Form, dass die Seite ohne nicht "vernünftig" angezeigt wird, bzw. benutzbar ist.
Die Anzahl der Clients ohne aktives JS ist, zumindest in meinen Beobachtungen, von "verschwindend gering" weiter zurückgegangen.
Davon ab sollte eine Seite natürlich auch ohne JS funktionieren. Auch dafür kann die gezielte Auslieferung von Code sinnvoll sein. So bekommt der No-JS Client eben auch keine JS-Libs etc. ausgeliefert.
Das "passiert" ja von alleine ...! :-P
Wie schon in der Antwort an Mathias - bitte konkrete Fälle/ Umstände nennen.
Ansonsten ist die Diskussion eher rein hypothetischer Natur ...! ;-)Tabellen sind immer so ein Fall. Ist genug Platz (Viewport) und Bandbreite vorhanden können umfangreiche Daten ohne Probleme in durchaus großen Tabellen ausgeliefert werden. Auf kleineren Viewports und/oder mit geringerer Bandbreite kann es durchaus sinnvoll sein die Daten in anderer Form aufzubereiten und initial nur eine Teilmenge an den Client zu schicken.
Windows Phone 7 setzt(e) auf den IE7.
Ja und? Den wolltest du heutzutage auch immer noch unterstützen?
Natürlich. Es sind noch erstaunlich viele Windows Phone 7 Geräte unterwegs. Vor allem, da sich die meisten dieser Geräte nicht auf Windows Phone 7.5 aktualisieren lassen.
Komisch ..., bei JS "stört" dich das ein Prozent nicht, aber bei Windows Phone ...
Windows Phone OS 7.0 Market Share on Mobile/Tablet
Windows Phone OS 7.5 Market Share on Mobile/Tablet
ist es dann relevant!? :-P
Wenn der Overhead solche Größenordnungen annimmt, wie von dir genannt, dann liegt in meinen Augen eher schon ein "konzeptioneller Fehler" vor.
Nein. Je granularer die Adressierung ist, desto mehr Code fällt an. Im clientseitigen RD macht es doch auch einen Unterschied ob 5 oder 50 Media Queries definiert werden.
Und wenn man die möglichen Kombinationen von Viewport, Orientierung, Touch, OS, Browser, etc. mal hochrechnet kommen da deutlich mehr bei rum.
Das ist doch schon ein "konzeptioneller Fehler". Die entwickelst doch nicht für eine bestimmte Viewportgröße oder Browser etc.
Du legst einige (wenige) Breakpoints gemäß deinem Inhalt an (die sich natürlich durchaus auch an den "gängigen" Viewportgrößen orientieren dürfen).
Innerhalb dieser Breakpoints gestaltest du deine Site fluide.
Und was spricht dagegen, eine Site so anzulegen, dass sie sowohl mit einer Maus, als auch per Finger/ Stift (Touch) gleichermaßen gut bedienbar ist?
Sorry, aber 20 oder mehr MQs halte ich persönlich für völlig unsinnig.
Und je größer, oder wie du es bezeichnest je "granularer die Adressierung" ist, umso größer wird nicht nur der Erstellungsaufwand, sondern auch der Pflege- & Aktualisierungsaufwand!
Den "Aufwand", den du da scheinbar betreiben willst, wird dir kein Kunde bezahlen!
Mal davon abgesehen, dass ich ihn, wie schon erwähnt, auch nicht als sinnvoll erachte.
Gruß Gunther
Hallo,
Die Frage ist halt immer die, wie viel sind das eine Prozent?
Und kann man darauf "verzichten"?
Quantität ist eher sekundär, die Qualität der User ist i.d.R. relevanter.
Mich würde aber mal interessieren, wie du auf die Zahlen kommst?
Auswertung von diversen Trackingverfahren von einigen großen Seiten und Zusammenarbeit mit einigen auf UX spezialisierten Agenturen.
Und wieder eine Sache mehr, die laufend gepflegt und aktualisiert werden muss!
Muss man nicht selber machen. Kann man relativ günstig einkaufen.
So bekommt der No-JS Client eben auch keine JS-Libs etc. ausgeliefert.
Das "passiert" ja von alleine ...! :-P
Aber die CSS und andere Ressourcen die mit diesen Libs zusammenhängen werden meist dennoch referenziert und vom client angefordert.
Komisch ..., bei JS "stört" dich das ein Prozent nicht, aber bei Windows Phone ...
Es sind großzügig aufgerundet eher 0,1%
Windows Phone OS 7.0 Market Share on Mobile/Tablet
Windows Phone OS 7.5 Market Share on Mobile/Tablet
Schöne Zahlen, aber nur zur groben Orientierung geeignet. Die eigenen Zahlen sind sie wichtigen.
ist es dann relevant!? :-P
s.o.
Das ist doch schon ein "konzeptioneller Fehler". Die entwickelst doch nicht für eine bestimmte Viewportgröße oder Browser etc.
Ein typisches Projekt
Da kommt schon einiges Zusammen. Und bei einer serverseitigen Lösung bekommt der Client eben nur das was er braucht.
Den "Aufwand", den du da scheinbar betreiben willst, wird dir kein Kunde bezahlen!
Doch, durchaus.
Ob ich das nun clientseitig mittels Media Queries, Conditional Comments, Polyfills, diversen JS-Libs wie z.B. Modernizr mache oder serverseitig ist doch nun wirklich kein Unterschied vom Aufwand her.
Mal davon abgesehen, dass ich ihn, wie schon erwähnt, auch nicht als sinnvoll erachte.
Das ist deine Meinung aber nicht allgemeingültig.
Wie ich schon mehrfach in diesem Thema schrieb ist es auch immer projektabhängig welchen Weg man wie weit geht.
Gruß
Ole
@@Gunther:
nuqneH
Die Frage ist halt immer die, wie viel sind das eine Prozent?
Und kann man darauf "verzichten"?
Und da sollte auch nicht eine n%-Hürde aufgebaut werden, sondern das Kosten-Nutzen-Verhältnis abgewogen werden.
Wenn ein Fallback für die 1% (wenn schon nicht auf progressive enhancement gesetzt wird) in einem Wimpernschlag erledigt werden kann (also si gut wie nichts kostet), dann sollte man das tun.
Wenn ein Fallback sehr aufwendig wäre, kann auch die Entscheidung gegen 10% evtl. eine sinnvolle sein.
Sorry, aber 20 oder mehr MQs halte ich persönlich für völlig unsinnig.
Kommt auf die Zählweise an.
Wenn man die Gestaltung von innen nach außen entwickelt (was man tun sollte) und die Breakpoints nach dem Inhalt setzt (was man tun sollte), kann schon sowas bei rauskommen:
html { … }
@media (min-width: 24em) { html { … } }
@media (min-width: 30em) { html { … } }
foo { … }
@media (min-width: 26em) { foo { … } }
bar { … }
@media (min-width: 32em) { bar { … } }
Viele Breakpoints können sich ungünstig zum Testen erweisen, die QA wird sie hassen. Vielleicht sollte man da Kompromisse eingehen und sich auf wenige beschränken; in dem Beispiel statt 26em den schon vorhanden Breakpoint 24em wiederverwenden und entsprechend 30em satt 32em:
html { … }
@media (min-width: 24em) { html { … } }
@media (min-width: 30em) { html { … } }
foo { … }
@media (min-width: 24em) { foo { … } }
bar { … }
@media (min-width: 30em) { bar { … } }
Wären dass bei deiner Zählweise nun 4 Breakpoints oder 2?
Insbesondere bei Verwendung eines CSS-Präprozessors wird man das so im CSS zu stehen haben und nicht als
html { … }
foo { … }
bar { … }
@media (min-width: 24em)
{
html { … }
foo { … }
}
@media (min-width: 30em)
{
html { … }
bar { … }
}
weil der Sass-Quelltext so aussieht:
html
{
…
@media (min-width: 24em) { … }
@media (min-width: 30em) { … }
}
foo
{
…
@media (min-width: 24em) { … }
}
bar
{
…
@media (min-width: 30em) { … }
}
Qapla'
PS: Der Syntax-Highlighter des Forums ist kaputt.
Om nah hoo pez nyeetz, Gunnar Bittersmann!
PS: Der Syntax-Highlighter des Forums ist kaputt.
Kaputt nicht, er arbeitet genauso, wie er programmiert wurde, imo.
Seine Programmierung ist nur nicht mehr aktuell.
Im neuen Forum sollte man auf eine Fremdlösung setzen.
Matthias
@@Gunnar:
nuqneH
Die Frage ist halt immer die, wie viel sind das eine Prozent?
Und kann man darauf "verzichten"?Und da sollte auch nicht eine n%-Hürde aufgebaut werden, sondern das Kosten-Nutzen-Verhältnis abgewogen werden.
Wenn ein Fallback für die 1% (wenn schon nicht auf progressive enhancement gesetzt wird) in einem Wimpernschlag erledigt werden kann (also si gut wie nichts kostet), dann sollte man das tun.
FACK
Wenn ein Fallback sehr aufwendig wäre, kann auch die Entscheidung gegen 10% evtl. eine sinnvolle sein.
Ja das, auch!
Es kommt, wie eigentlich immer und bei allem, auf den jeweiligen individuellen Fall an.
Sorry, aber 20 oder mehr MQs halte ich persönlich für völlig unsinnig.
Kommt auf die Zählweise an.
Wenn man die Gestaltung von innen nach außen entwickelt (was man tun sollte) und die Breakpoints nach dem Inhalt setzt (was man tun sollte), kann schon sowas bei rauskommen:
Viele Breakpoints können sich ungünstig zum Testen erweisen, die QA wird sie hassen. Vielleicht sollte man da Kompromisse eingehen und sich auf wenige beschränken; in dem Beispiel statt 26em den schon vorhanden Breakpoint 24em wiederverwenden und entsprechend 30em satt 32em:
html { … }
@media (min-width: 24em) { html { … } }
@media (min-width: 30em) { html { … } }foo { … }
@media (min-width: 24em) { foo { … } }bar { … }
@media (min-width: 30em) { bar { … } }
>
> Wären dass bei deiner Zählweise nun 4 Breakpoints oder 2?
Das wären für mich 2 Breakpoints.
Es war und ist nicht die Anzahl an MQ Rules im CSS gemeint, sondern tatsächlich die Anzahl an (unterschiedlichen) Breakpoints.
Es ist also eher eine sprachliche Ungenauigkeit, wenn nur von MQs die Rede ist/war.
Wobei ich aber davon ausgehe, dass Ole das in diesem Fall auch so gemeint hat.
Gruß Gunther
Hallo,
Windows Phone 7 setzt(e) auf den IE7.
Ab Windows Phone 7.5 gibt es IE 9. Versionen darunter würde ich vernachlässigen, sie haben wahrscheinlich einen kaum messbaren Marktanteil.
Mathias
Hi Mathias,
Ab Windows Phone 7.5 gibt es IE 9. Versionen darunter würde ich vernachlässigen, sie haben wahrscheinlich einen kaum messbaren Marktanteil.
Leider lassen/ließen sich die meisten 7er nicht auf 7.5 aktualisieren. Und wenn die Quantität der qualitativ hochwertigen User ausreicht, oder ein Entscheider ein solches System nutzt, führt kein Weg um die Unterstützung.
Das muss von Fall zu Fall entschieden werden. Ist ja nicht so wie mit dem "echten" IE7, welcher uns schon seit gefühlt 100 Jahren terrorisiert. Windows Phone 7 ist ja grade mal vor etwa 3 Jahren auf den Markt gekommen.
Gruß
Ole
Hallo,
AFAIS gibt’s nichts besseres als den gesamten Code incl. aller Media-Queries in einem Stylesheet zu haben.
Es sei denn, man will mit JavaScript ein conditional loading von Stylesheets frickeln.
Was hätten Sie denn nun gerne, eine performante Website auf Mobilgeräten oder eine Seite, die den gesamten Code ausliefert, von dem nur ein Teil gebraucht wird?
Mich wundert immer wieder die Absolutheit der Aussagen hier. »Es gibt nichts besseres«, »der größte Blödsinn«. Da läuft es mir als professioneller Webentwickler immer kalt den Rücken herunter. In der Realität™ sind Probleme zu lösen und da gibt es hinsichtlich RWD keine beste Lösung, sondern bestenfalls Kompromisse.
Mathias
@@molily:
nuqneH
Was hätten Sie denn nun gerne, eine performante Website auf Mobilgeräten oder eine Seite, die den gesamten Code ausliefert, von dem nur ein Teil gebraucht wird?
Leider gehst du mit keinem Wort darauf ein, wie man keinen Stylesheet-Code ausliefert, der von dem betreffenden Gerät nicht gebraucht wird. So wie ChrisB sagte jedenfalls nicht, denn da wird sämtlicher Stylesheet-Code ausliefert.
Qapla'
Hallo,
Leider gehst du mit keinem Wort darauf ein, wie man keinen Stylesheet-Code ausliefert, der von dem betreffenden Gerät nicht gebraucht wird.
Du hast die Lösung ja schon genannt: Man lädt Stylesheets per JavaScript, wenn Media-Queries matchen.
Mathias
Hallo,
AFAIS gibt’s nichts besseres als den gesamten Code incl. aller Media-Queries in einem Stylesheet zu haben.
Es sei denn, man will mit JavaScript ein conditional loading von Stylesheets frickeln.
Mich wundert immer wieder die Absolutheit der Aussagen hier. »Es gibt nichts besseres«, »der größte Blödsinn«. Da läuft es mir als professioneller Webentwickler immer kalt den Rücken herunter. In der Realität™ sind Probleme zu lösen und da gibt es hinsichtlich RWD keine beste Lösung, sondern bestenfalls Kompromisse.
Ich find ja auch, dass nur ein Vulkanier den Anspruch auf die absolute Logik/Wahrheit haben kann, aber kein Klingone ;-)
Viele Grüße
Siri
Om nah hoo pez nyeetz, Siri!
Ich find ja auch, dass nur ein Vulkanier den Anspruch auf die absolute Logik/Wahrheit haben kann, aber kein Klingone ;-)
Gunnar ist Vulkanier. (Beweis) Er arbeitet als Botschafter im Hohen Rat, seine Begrüßung und Verabschiedung ist ein Zeichen des Respekts und der Achtung den Klingonen gegenüber.
Matthias
-> Es geht um Responsive Design und darum nicht den ganzen CSS-Code einzulesen, sondern nur den in der CSS-Datei die mit dem passenden Media Queries verlinkt ist. Also möglichst wenig Daten zu übertragen.
Antwort gab's ja schon, aber verspreche dir da nicht zu viel von. In der Theorie ist das alles schön und gut, in der Praxis (genauer: den Serverprotokollen) habe ich leider immer wieder beobachtet, dass rundweg alles runtergeladen wird, dessen so mancher Browser habhaft werden kann.
Das hat natürlich einen nachvollziehbaren Hintergedanken, wenn man das Browserfenster verkleinert, soll er nicht erst die CSS-Daten für kleinere Anzeigeflächen nachladen müssen, sondern sofort umschalten. Es führt nur halt dazu, dass der Einspareffekt nicht so ausfällt, wie man sich das vorgestellt hat.
Es kann im Gegenteil sogar dazu führen, dass man die Sache verschlimmbessert. Jeder einzelne Austausch zwischen Browser und Server kostet Zeit, je weiter man die Daten zersplittert, desto mehr Aufwand fällt für die Verbindungsverwaltung an.
Wenn du aus einer großen Datei zehn kleine machst, könntest wegen des Protokolloverheads dümmstenfalls ein Vielfaches der ursprünglichen Datenmenge durch die Leitung jagen; das alleine ist schon schlimm genug, obendrauf kommt noch die "unsichtbare" Zeit für den Verbindungsaufbau.
Kurzum: Überlege dir dein Vorhaben gut. Es ist in aller Regel völlig ausreichend, eine einzelne CSS-Datei zu behalten, aus dieser die Luft rauszulassen und sie zu komprimieren (was auch vorweg geht).
Aufteilen jedoch, wenn überhaupt, dann nach URLs, d.h. Bereichen deines Angebots.
Funktionierendes Caching mitsamt Verbindungsvermeidung sollte davon abgesehen eh selbstverständlich sein.
Greifst du auf anderer Leute Arbeiten zurück, benutze ein oder mehrere offene CDN wie jsdelivr, cdnjs, zur Not auch von der Datenkrake oder den Geldschindern. Browser begrenzen die Anzahl der gleichzeitigen Verbindungen auf eine Handvoll, Dateien von anderen Servern abzurufen, erhöht daher die Verbindungszahl für deine Seiten und verkürzt so die Wartezeit; ganz zu schweigen davon, dass die Daten vielleicht schon von jemand anderem im Browsercache abgelegt wurden.