Microsoft entwickelt am IE10 herum und kommuniziert die eigenen Fortschritte offensiv. Das ist löblich, für mich persönlich aber nur bedingt interessant. Der Veröffentlichungstermin des Browsers ist unbekannt und die Installationsrate dürfte sich am Anfang vorerst in Grenzen halten, schließlich ist der Browser für Windows Vista oder XP nicht erhältlich.
Interessant ist aber, dass sich Microsoft von den Conditional Comments trennt (am Ende des Artikels). Das ist nur konsequent, schließlich will man HTML5 und CSS perfekt unterstützen. Ich hoffe deshalb, dass sie diesmal auch keine extremen Fehler machen und Sonderwege gehen. Nicht dass wir uns am Ende extrem ärgern, dass uns diese schöne Methode nicht mehr zur Verfügung steht, um die ärgsten IE-Probleme direkt anzusteuern.
Der IE10 wird also keinen eigenen CC-Vektor mehr haben und sich gegenüber Conditional Comments wie jeder richtige Browser verhalten.
Ich persönlich finde es ja schade, dass Conditional Comments nicht als Standard in HTML5 aufgenommen wurden. Abseits der sinnvollen Featuredetection könnte man so die speziellen Nickligkeiten und Fehler eines Browsers direkt ansprechen und beheben. Aber wir hoffen ja darauf, dass die Notwendigkeit dafür demnächst gegen Null tendiert. Oder?
7. Juli 2011 um 7:12 Uhr
Ich find’s mithin die beschissenste Idee, die die zum IE10 jemals haben konnten. CCs sind so unendlich praktisch und es wird immer Gründe geben, warum man sie braucht. Letztens erst durfte ich Safari und Chrome (aufgrund der Antiquität des Safari 5.05) irgendwie auseinanderklamüsern, um jedem einen eigenen Style zu verpassen. Wie einfach wäre das mit CCs gegangen… Stattdessen versaue ich mir mein Stylesheet mit Hacks, die kein (Third Party) Schwein mehr verstehen wird. Ist das besser? Ich glaube, im Vergleich zu sprechenden .ie6 – .ie10 Klassennamen eher nicht.
Und mit JavaScript-basierter Featuredetection braucht mir keiner kommen. Ebenso nicht mit Legacy-Modus und schon gar nicht mit UA-Sniffing.
Bestenfalls könnte ich damit leben, wenn wir endlich mal adäquaten Ersatz bekämen, wie etwa UA-spezifische Media Queries à la
@media screen and (agent:ie) and (version:10)oder so.snief 🙁
7. Juli 2011 um 7:22 Uhr
Andererseits hat MS mit Windows Phone 7 (dankenswerterweise) erstmalig CC für mobile IE eingeführt: Conditional Comments für Internet Explorer auf Windows Mobile .
Ich halte es allerdings auch für möglich, dass das eine Interimslösung für den in WP 7.0 noch verwendeten IE7 ist, der natürlich mit all den üblicherweise verwendeten HTML5 / CSS3 Sachen zu wenig anfangen kann. Das die meisten neueren mobile-websites für iOS (vulgo: iPhone) und Android optimiert sind, dürfte MS wirklich wurmen. „Optimiert für…“ hatten wir doch schonmal, oder? Wie sich die Geschichte wiederholt.
Ich benutze mein WP7 Gerät auch nur zum gruseln und testen, aber nicht im täglichen Mobile-Web-Gebrauch – es geht wirklich nicht.
7. Juli 2011 um 7:25 Uhr
Solange wie für den IE6 Sicherheitsupdates gefahren werden und die IT’ler der Meinung ist „ein gut laufendes System in Ruhe zu lassen“ werden wir nie um Conditional Comments einen Bogen machen können. Und irgendwo hat’s uns auch die Browserübergreifende Arbeit vereinfacht, oder?
7. Juli 2011 um 7:28 Uhr
@Chrishe: Das ist ja nicht das Thema. Das Problem ist, dass wir wohl nur bis inkl. IE9 den Browser direkt ansprechen können. Und wer sagt uns, dass es nicht auch im IE10 Probleme geben wird, bei denen wir für ein CC dankbar wären? Wir können natürlich weiterhin IE6 und 7 per CC ansprechen.
Ich hätte gerne wie der Schepp einen CC auch für Safari, Chrome, Opera, Firefox und die vielen anderen Browser da draussen. Das wäre im Notfall (!) eine saubere und sichere Lösung ohne Javascript.
7. Juli 2011 um 7:28 Uhr
Hoffen ist gut – vor allem, dass Microsoft sich zukünftig wirklich an die Standards hält. Ich persönlich denke aber, dass man relativ bald zurückrudern und die Conditional Comments wieder unterstützen wird.
7. Juli 2011 um 7:38 Uhr
Achja, die Clowns aus Redmond. Darin, völlig irrationale Entscheidungen zu treffen, sind sie ungeschlagen. Ich frage mich, woher die ihre Gewissheit nehmen, mit IE10 würde ja alles ganz anders werden. U know what? Es wird wieder Bugs und Scheiß geben, der uns die Haare zu Berge stehen und länger als kalkuliert schuften lassen wird. Es wird sich nichts am Kindergartrn-Browser ändern.
Übrigens +1 für UA Media Queries vom Schepp.
7. Juli 2011 um 7:38 Uhr
Du hast vollkommen Recht …
„Und wer sagt uns, dass es nicht auch im IE10 Probleme geben wird“ so sieht’s leider aus. Ich habe mich beim lesen des Artikels sofort wieder in diverse Situationen zurückgesetzt gefüllt, bei denen CC sowas von hilfreich gewesen waren, aber irgendwie trotzdem innerlich wieder sowas von aufgeregt, dass sowas überhaupt notwendig war. Hmm naja, wir werden sehen. 😀
7. Juli 2011 um 7:58 Uhr
UA spezifische Media-Queries fänd ich auch gut. Es geht ja nicht nur um den IE – bei dem ich die Hoffnung nicht aufgebe, dass er in Zukunft wieder zu den guten Browsern gehören wird.
Jeder Browser hat seine unterschiedlichen Wehwehchen und selbst zwischen Webkit basierten wie Chrome und Safari gibt es Unterschiede, die so gut gelöst werden könnten. Die Lösung über Media-Queries würde das HTML in Ruhe lassen und wäre mehr im Sinne der Standards, unter dessen Gesichtspunkt mir die CCs nie gefallen haben.
7. Juli 2011 um 8:21 Uhr
Sobald man nicht mehr nur rein statische Webseiten ausliefert, kann man natürlich auch einfach jeden Browser anhand seiner HTTP Header erkennen – serverseitige CC für alle sozusagen – und jedem sein extra Style zukommen lassen.
Was Dein Browser behauptet zu sein, kannst Du hier sehen: Mein Browser – nehme ich auch gerne, wenn Kunden optische Bugs anmeckern, mir aber nicht sagen können, was genau sie benutzen. Dami kann ich’s rausfinden 🙂
7. Juli 2011 um 8:52 Uhr
Bowser detection ist falsch, es macht HTML und CSS kaputt und ist schlecht wartbar. Daran ändert es auch nichts, wenn der Browser selbst sagt wer er ist. Die Kaskaden aus CCs und unterschiedlichen Stylesheets bringen niemanden weiter, Feature-Detection funktioniert einwandfrei und sorgt für konsistente Darstellung auch auf nicht IEs.
Zudem werden Versionsnummern immer weniger eine Rolle spielen, schon daher sind CC wie bisher wenig sinnvoll. Wir wollen, dass der IE schneller upgedatet werden soll, da passt ein statisches System wie CC nicht rein, sonst haben wir bald auch CCs für IE 10, 10.1, 10.12a usw. usf. Die Büchse der Pandora, imho.
7. Juli 2011 um 8:59 Uhr
@Eric: Featuredetection funktioniert bei CSS bedingt. Denn der IE6 wird Dir natürlich zurückgeben, dass er Floats kennt und unterstützt. Den Doubled-Margin-Bug bekommst Du so nicht zu fassen. Den bekommst Du nur über Parsingfehler (Hacks) oder CC weg. Und ich gehe jedenfalls davon aus, dass Microsoft sich alle Mühe geben wird, trotzdem aber wie alle anderen Browserhersteller auch Fehler in seinem Browser haben wird. Mittels CC wären die einfach zu bekämpfen. Und ob ich mittels Featuredetection nach etwas suche und dann bekämpfe oder das mittels CC mache, macht im Verwaltungsaufwand überhaupt keinen Unterschied. Und für CC benötige ich noch nicht einmal Javascript.
7. Juli 2011 um 9:01 Uhr
Wie konsistent ist das hier denn bei Dir im Safari 5.05, der ja laut Feature-Detection box-shadows kann?
Oder wie rendern Firefox und Safari diese gekippten Elemente?
Manchmal ist Feature-Detection einfach nicht genug. Auch die hier vom W3C angedachte: http://dev.w3.org/csswg/css3-conditional/ (via @Elchi3)
Auch wüsste ich angesichts dieser Argumentation gerne, wieso wir gleichzeitig ein Loblied auf @media (Queries) und @viewport singen sollten? Das ist dann keine Kaskade schlecht wartbaren CSS‘? Streng genommen doch ebenso.
Meinetwegen dürfen CCs gerne dann sterben, wenn wir einen (standardisierten) Ersatz in den @media Queries bekommen. Gehst Du da konform?
7. Juli 2011 um 9:07 Uhr
@Michael Serverseitig User-Agent-Detection fliegt Dir i.d.R aber um die Ohren, sobald sich ein Proxy zwischen Deinen Server und den Besucher hängt. Abgesehen von den ganzen Fehlern, die dabei passieren können. Deshalb gehört UA-Sniffing für immer geknebelt und in ein dunkles Verlies geworfen 🙂
7. Juli 2011 um 9:08 Uhr
Ich schließe mich Eric an: CCs und andere Techniken der Browser-Erkennung via Name und Version sind allerspätestens seit der Einführung von Rapid Browser Development keine sinnvolle Sache mehr.
Feature Detection ist, was man will. Gerne auch als CSS Feature Query (nicht Media Query, weil ein Feature ja kein Ausgabemedium ist), um unabhängig von JavaScript zu sein. Also eher etwas wie:
@feature box-shadow and (box-sizing: border-box) { … }7. Juli 2011 um 9:14 Uhr
@Marc: Wenn ich Features so ansprechen könnte, wär das klasse. Geht aber nicht. Und selbst wenn: transportiere mein Beispiel mit Floats bitte darauf. Das Feature „Float“ existiert im IE6. Dummerweise ist es aber nicht fehlerfrei umgesetzt. Und wenn ich dann einfach nur alle mit diesem Feature behandele, erreiche ich auch diejenigen, die es können. Zudem gibt es einige Browser, die bei Featuredetection „ja, kenne ich“ rufen, aber damit nur meinen, dass ein Programmierer da schonmal was geschrieben hat. Das Feature ist aber nicht wirklich implementiert.
CC und Featuredetection sind in meinen Augen prima Werkzeuge für völlig unterschiedliche Einsatzgebiete.
7. Juli 2011 um 9:09 Uhr
Oh, CSS Conditional Rules kannte ich noch nicht – Danke für den Hinweis! 🙂
7. Juli 2011 um 11:42 Uhr
Ich seh’s eher pragmatisch. In manchen Fällen is UA sniffing völlig in Ordnung, CCs werden meist gerne verwendet und feature detection wo passend auch. Hat alles seinen Platz.
7. Juli 2011 um 13:14 Uhr
Das läuft doch ganz sicher auf einen epic fail hinaus :-/
7. Juli 2011 um 13:27 Uhr
ich mag mich Eric anschließen,
denn es ist in sich logisch, wenn der IE6 nicht mehr im Programm ist kann er floats können wie er mag, falsch darstellen wie er mag,
er ist einfach nicht mehr im Programm…
und je mehr wir noch darauf eingehen, desto weniger wird er endgültig das zeitliche segnen,
bei der Fülle an Ausgabe Geräten werden die Kunden -zumindest meine- auch immer mehr bereit zu akzeptieren, dass somancher Browser nicht alles kann.
also unbedingt nötigst sind die CC nicht,
manchmal ne hilfreiche Krücke, aber mit sehr engen Grenzen.
7. Juli 2011 um 23:55 Uhr
@Jens: Den IE6 mit dem IE10 zu vergleichen ist wohl wenig sinnvoll (2002 vs 2012). Zudem unterbindet der IE10 nicht die MediaQueries für irgendwelche IE6.
Für IE8 und 9 benötige ich in meiner täglichen Arbeiten selten CCs und wenn, dann nur aus Faulheit, gravierende Bugs a la double margin gibt es doch kaum noch.
8. Juli 2011 um 4:52 Uhr
Warum sollte IE10 die CC denn haben – welchem Standard zufolge?
http://dev.w3.org/csswg/css3-conditional/ wird vermutlich grob unterscheiden helfen, und der Rest sind Bugs wie bei jedem anderen Browser auch. Bis IE9 inkl. guckt MS zurück im Zorn mit seinen CC, aber wenn MS meint, der IE10 sei gut genug ohne sie, ist das doch ein Statement, was wir unterstützen sollten.
8. Juli 2011 um 6:16 Uhr
@Eric, @Ingo: Mein Vertrauen bzgl. der Korrektheit irgendeiner technischen Implementierung muss sich Microsoft erst noch erarbeiten. Zuviel haben sie bislang falsch gemacht, auch bewusst falsch.
Bis dahin bin ich froh, wenn ich einen Weg habe, um Fehler auszubügeln, die nur der IE hat, nicht aber alle anderen. CC sind der einfachste Weg. Ich muss dann wohl auf Parsingfehler wie beim Star-Hack hoffen.
8. Juli 2011 um 11:40 Uhr
Zu CC allgemein:
Auch ich finde die Möglichkeit, clientseitiges Browsersniffing bereits auf HTML-Ebene und nicht erst auf JS-Ebene zuverlässig betreiben zu können, sinnvoll. Dies gilt nicht nur für IE, sondern für alle Browser.
Allerdings wird die ganze Diskussion hier etwas zu hitzig. Beispiele und Grundannahmen sind etwas danneben:
1. aktuelle IEs können zwar wenig sind aber solide:
Bereits der IE8 ist was CSS2.1 angeht so gut, dass man auf CC praktisch verzichten kann. Hauptanwendungsfall für CC bei diesem Browser, ist für mich vor allem die Verwendung von pie.htc und ähnlichem (htc ist übrigens auch ein feature, was weggefallen ist).
Wenn man moderne Features – insbesondere HTML5 – verwendet, wird man derzeit regelmäßig von allen Browsern (insbesondere Opera und Safari) im Stich gelassen. Ich sehe da keinen großen Unterschied zwischen IE und den anderen.
2. Die Verwendung von CCs um Bugs wie den genannten double margin bug zu umschiffen, ist in 90% aller Fälle ein handwerklicher Fehler. Man sollte hier allen Browsern dann ein display: inline zu kommen lassen. Nur so wird sichergestellt, dass es nicht zu „Anschlußfehlern“ kommt, da in manchen Browsern das Element als block und in anderen als inline gerendert wird. D.h. Möchte man schon konkrete Beispiele verwenden, muss erstmal ein Beispiel aufgezeigt werden, bei dem der Einsatz sinnvoll ist.
3. Feature-Detection von CSS mit JS
Es ist grundsätzlich möglich den double margin bug mit JS zu erkennen. Ich erwähne dies nur, da es den Anschein hat, dass dies hier bezweifelt wird. Dies ist natürlich nicht sinnvoll, da JS dem CSS gegenüber nachrangig ist (Mein Hauptproblem mit Modernizr.). Außerdem kennen wir die IE-Version, in welcher der Bug gefixt wurde. (Das Testen von korrekter Implementierung, ist in Fällen in denen man die Version nicht kennt, mit welcher der zu testende Bug gefixt wurde, schlichtweg alternativlos.)
9. Juli 2011 um 7:54 Uhr
Offen gesagt finde ich es einen Logikbruch, einerseits generell dafür zu trommeln, dass Webseiten nicht in jedem Browser gleich aussehen müssen, und andererseits maximale Steuerung kleinster Details in einzelnen Browsern einzufordern.
Möglicherweise liegt es an meinen spezifischen Projekten und Kunden, aber ich komme mit feature detection mittels Modernizr sehr gut aus und habe in letzter Zeit von den conditional body classes auch nur .ie7 wirklich benutzt. Im Übrigen brüllt auch niemand nach speziellen Zugriffen für etwa Opera, insofern hat Alexander sehr Recht: die allgemeingültige Zuweisung von etwa
display:inline;o.Ä. ist der „richtige“ Weg.Das wirkliche Problem, wie ich gerade an den Statistiken eines Projektes mit einer sehr speziellen Zielgruppe sehe, ist ohnehin nicht der IE – das ist die immer noch erschreckend hohe Verbreitung von Windows XP.