nicht angemeldet
Hallo,
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.
Ich sehe das nicht so "dogmatisch" ...! ;-)
Die letzten 10 Jahre haben auch gezeigt, dass es immer Unterschiede zwischen Theorie & Praxis gibt und geben wird. Es nutzt doch herzlich wenig, wenn zwar theoretisch alle (gängigen) Browser 'table display' unterstützen, die Interpretation in der Praxis aber weit auseinander geht! Da wäre es mir zumindest lieber, ich könnte meinen (extra) CSS-Code sehr einfach auf den/ die erforderlichen Browser eingrenzen.
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.
Und wann soll das "irgendwann" sein!?
Was lässt dich annehmen, dass das, was die letzten 10 Jahre nicht geklappt hat, in naher Zukunft klappt? Und was machen wir in der Zwischenzeit?
Das ist doch genau eine der Diskrepanzen, von der ich gesprochen habe. Bei der (Weiter-)Entwicklung von CSS werden doch die tatsächlichen Gegebenheiten und Realitäten stur "ignoriert/ übersehen". Und für heutige Problemstellungen jetzt anzufangen Lösungen auf dem gewohnten Weg zu erstellen, dauert bis zu deren praktischen Nutzbarkeit doch viel zu lange. Auch das haben die letzten 10 Jahre hinlänglich genug bewiesen ...!
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.
Was verstehst du daran nicht (siehe auch mein Beispiel bezüglich der Viewportgröße)?
Und die geplante Abschaffung des zuständigen Meta-Tags, und die Verlagerung ins CSS (@viewport), ist ein Schritt vom Regen in die Traufe ...!
Warum?
Weil das das Problem lediglich verlagert (von HTML nach CSS), aber nicht löst ...!
- Es müssen neue Möglichkeiten her, effizienteres CSS schreiben zu können.
Du meinst Sass?
Nein, meine ich nicht. ;-)
SASS & Co. erleichtern vielleicht das Schreiben, verändern aber nichts an der Tatsache, dass CSS von Hause aus ineffizient ist.
- Es müssen Möglichkeiten her, die übermittelte Datenmenge auf das wirklich Erforderliche reduzieren zu können.
Du meinst SPDY?
Hmmm ..., I am not quite sure.
Inwiefern hat das etwas mit der eigentlichen Datenmenge zu tun (mal abgesehen davon, dass diese komprimiert wird)? Soweit ich das verstehe, ändert das aber nichts daran, dass jedem CLient trotzdem Unmengen an Daten geschickt werden, die er eigentlich gar nicht braucht, oder?
- 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.
Sorry, aber das sehe ich anders. Du wirst immer die Notwendigkeit haben, gemäß den unterstützten CSS Fähigkeiten des jeweiligen Browsers im CSS zu unterscheiden. Mit JS ist das auch relativ einfach und in ausreichendem Maße möglich. Nutzt aber nichts, solange wie man dessen Verfügbarkeit nicht mit 100% voraussetzen kann. Und die Umsetzung in CSS (via @supports) hat die bereits weiter oben erwähnten Probleme und reicht vom Umfang der Möglichkeiten her auch bei weitem nicht aus.
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).
Hehe ..., fällt dir auf, wie paradox das ist!? ;-)
Wenn ich JS zur Verfügung habe, brauche ich gar kein Flexbox-Layout ...! :-P
Brauchen tue ich es nämlich eigentlich nur dann, wenn eben kein JS verfügbar ist, um bspw. den Effekt der gleich hohen Boxen oder der Änderung der Reihenfolge von Elementen zu erreichen.
Da du schon davon angefangen hast und das imho aktuell ein recht gutes Beispiel ist:
Für Browser, die das Flexbox Modul unterstützen, wollen wir natürlich auch dieses verwenden.
Für andere Browser, die das Flexbox Modul nicht unterstützen, weichen wir auf display:table als Fallback aus. Und wenn du auch noch den IE 7 mit reinnehmen willst, brauchst du noch einen weiteren Fallback.
Jetzt wäre es doch höchst hilfreich, wenn ich in meinem CSS die jeweiligen Browser einfach unterscheiden könnte (ohne JS!), oder nicht?
Und es ist in solchen Fällen eben meist auch nicht damit getan, z.B. nur die jeweilige diplay Eigenschaft zu ändern. Denn oftmals braucht man auch unterschiedliche Werte für andere Eigenschaften, die aber wiederum von allen, oder zumindest mehreren Browsern verstanden werden. Und dann? Dann stehst du ohne z.B. entsprechende Kenntnis über den jeweiligen Browser/ die Engine mit CSS alleine auf dem Schlauch ...!
Und mir ist zur Lösung solcher Probleme (ohne JS) bislang nur UA-Sniffing (und für die IEs CCs) eingefallen ..., aber wenn du andere/ bessere Lösungen kennst ...?
Gruß Gunther
Matthias Apsel