nicht angemeldet
Hallo,
Lange Zeit wurde nicht nur hier gebetsmühlenartig gepredigt sein Layout nicht von Javascript abhängig zu machen!
Das sollte idealerweise so sein. Wenn es einem nicht auf jeden übertragenen Byte ankommt und man keine Scheu hat, z.B. ein float-/position-CSS immer zu laden, selbst wenn ein JavaScript später ein Flexbox-CSS hinzulädt und ersteres deaktiviert, so ist Progressive Enhancement auch möglich.
Von daher plädiere ich seit langem dafür, dass man in CSS einen den 'Conditional Comments' ähnlichen Mechanismus implementiert, der das gezielte Ansprechen bestimmter Engines und Browsern ermöglicht, ohne auf irgendwelche 'Hacks' zurückgreifen zu müssen.
Das Webdesign hat die letzten 10 Jahre gebraucht, um diese Methode zu überwinden. Die Webstandards-Bewegung hat sich 10 Jahre lang den Mund fusselig geredet beim Kampf gegen browserspezifischen Code und Browser-Abfragen.
Möglich ist das immer noch, sowohl client- als auch serverseitig, und es wird allerorten trotz besseren Wissens getan. Aber jeder, der an der Web-Plattform arbeitet (Webstandards, Browser, Authoring Tools usw.), will diese Methode irgendwann gänzlich begraben.
Ich meine spätestens, wenn bei etlichen Websites der Umfang der zugehörigen CSS Datei(en) größer ist als der eigentliche Inhalt, muss man sich doch mal fragen, ob das alles wirklich so "richtig" ist!
Dann macht der Autor höchstwahrscheinlich etwas falsch – oder das CSS umfasst sinnvollerweise Styles für die gesamte Site, nicht nur für das aktuelle Dokument.
Warum muss man solch einem Client dann die anderen 90% des CSS ausliefern, mit denen er nichts anfangen kann!?
Muss man nicht.
Es ist einfach eine Erfahrung der Performance-Optimierung, dass es einfacher und schneller ist, alles in eine Datei zu packen, anstatt auf einem Gerät mit High-Latency-Internetzugang dutzende Requests abzuschicken, um nur das nötigste zu laden.
Natürlich gibt es elaborierte Modulserver, die HTML/CSS/JS-Pakete schnüren, wie sie der Client gerade braucht. Dann ist auch Lazy Loading problemlos möglich. Allerdings bringt das eine riesige Komplexität mit sich und die gegenwärtigen Webtechniken sind noch nicht darauf ausgelegt.
Und die Browserhersteller tun ein Übriges ...! So "nötigen" sie einen quasi zu serverseitigem UA-Sniffing, wenn du dem User die Möglichkeit geben willst, auch die sog. Desktopversion der Seite zu sehen.
Das verstehe ich nicht.
Und die geplante Abschaffung des zuständigen Meta-Tags, und die Verlagerung ins CSS (@viewport), ist ein Schritt vom Regen in die Traufe ...!
Warum?
- Es müssen neue Möglichkeiten her, effizienteres CSS schreiben zu können.
Du meinst Sass?
- Es müssen Möglichkeiten her, die übermittelte Datenmenge auf das wirklich Erforderliche reduzieren zu können.
Du meinst SPDY?
- Es müssen Möglichkeiten her, clientseitig für das Layout relevante Dinge auch ohne JS in Erfahrung bringen zu können.
Im Gegenteil. Das Problem, Fähigkeiten in Erfahrung bringen zu müssen, sollte in Zukunft vermieden werden. Es müssen Webtechniken entstehen, die in den Browsern erst freigeschaltet werden, wenn W3C Candidate Recommendations existieren. Genau das machen Chrome und Firefox in Zukunft. Keine Vendor-Prefixes mehr, keine verbuggten proprietären Vorab-Implementierungen.
Sicherlich wird es immer noch die Notwendigkeit geben, z.B. zwischen float-/position- und Flexbox-Layout zu unterscheiden. Das geht nicht so einfach ohne Modernizr & yepnope (JavaScript-Featureabfrage und bedingtes Laden von Stylesheets).
Mathias
Matthias Apsel