(zoals ik al aangegeven heb zie ik niets in de UA-Compatible HTTP Header, zie mijn andere reactie hierover
)Als een sitebouwer wil dat zijn site er in alle versies van Mozilla goed uitziet dan moet hij alle versies testen
Je gaat er dan wel vanuit dat er grote vershillen zijn bij de diverse versies van Firefox. Dat is echter niet het geval. Zo zijn bijvoorbeeld de render-engine (Gecko 1.8) van Fx 1.5 en 2.0 dezelfde, en zijn de verschillen tussen Gecko 1.7, 1.8 en zelfs 1.9 qua HTML/CSS2 ondersteuning helemaal niet zo groot als de verschillen tussen bijvoorbeeld IE6,7 en 8.
Voor Fx is er dus, op dit moment, helemaal geen noodzaak voor een switch die aangeeft welke render-engine bedoelt is - verder heb ik niets aan de switch als de engine zelf niet aanwezig is. (Bijvoorbeeld: Ik target IE6, maar er is geen IE6 render-engine aanwezig - en dan?)
Voor IE hoeft hij dat straks dus niet meer te doen.
Dat is dus slechts ten dele waar, tenzij alle render-engines die er zijn van IE met de volgende IE versie meegelevert zal gaan worden...
Dus nieuwere versies van deze browsers zullen de huidige standaarden vermoedelijk beter implementeren en ook nieuwe standaarden (CSS3, MathML3, HTML5) langzamerhand gaan implementeren. Er is dus elke keer verschil in versies ook bij FF en Opera en dan is het als sitebouwer dus handig als je toch precies weet hoe een browsers je site zullen renderen ook als er een nieuwe versie uitkomt.
Op dit moment is de ondersteuning voor de diverse W3C/ECMA standaarden in Safari, Opera en Fx voor meer dan 95-99% correct, de kans dat er dus op dat niveau iets omvalt is zo klein dat daar (mijns inziens) geen switch voor nodig is.
Nieuwe standaarden, zoals CSS3, MathML3 en HTML5 hebben vziw geen impact op oude - deze hebben dan ook geen invloed op de rendering van een bestaande website.
Als ik dus een HTML4/CSS2/JS1.5 website maak dan zal deze er in Fx 4.0 hetzelfde uitzien als in Fx1.5 - omdat HTML5, CSS3 en JS2.0 compatible zijn met hun voorgangers...
Als ik expliciet een HTML5 site bouw dan kan een oude browser deze toch niet correct renderen - wat heb ik dan aan een versie-switch die aangeeft dat ik IE9 nodig heb terwijl op mijn computer ie8 staat?
Op dit moment is de ondersteuning voor de diverse W3C/ECMA standaarden in Safari, Opera en Fx voor meer dan 95-99% correct, de kans dat er dus op dat niveau iets omvalt is zo klein dat daar (mijns inziens) geen switch voor nodig is.
De exacte mate van ondersteuning is moeilijk te meten.
De ondersteuning voor HTML/XHTML, DOM levels en CSS2.1 in FF en Opera ligt zo tussen de 80% en 95% als je kijkt naar de ondersteuning gvan de individuele spec elementen. Zeker niet in de buurt van de 99%.
Zo ligt de ondersteuning voor HTML 4.01 elementen bij
IE6 op 80% IE7 op 81% , FF2 op92% en opera op 86%
(met name de CSS ondersteuning ligt bij IE lager dan bij de anderen)
Die cijfers zeggen niet alles want als je hele obscure elementen niet ondersteunt dan heeft dat minder effect dan dat je populaire elementen niet ondersteunt.
Veel mensen hebben geen idee wat voor effect het zou hebben als alle browser echt 100% compliant zouden worden. Een voorbeeld:
Stel dat bijvoorbeeld IE, FF en opera bij het veelgebruikte "target" element voortaan unreserved words beginnend met een underscore gaan ignoren (dat zou moeten als de standaard correct werd gehanteerd) dan kunnen heel wat navigatie elementen op sites gaan breken.
Dat is dus betere standaards ondersteuning maar stapels sites gaan er kapot aan en daarom worden dit niet door IE maar ook niet door FF en Opera ingevoerd.
Je kunt dat echter voortaan wel doen met deze methode omdat de sitebouwer er dan expliciet voor gekozen heeft.
[Reactie gewijzigd door hAl]
Veel mensen hebben geen idee wat voor effect het zou hebben als alle browser echt 100% compliant zouden worden.
100% compliant met wat? HTML4.01 bijvoorbeeld? Dan krijg je leuke bijverschijnselen bij XHTML geserveerd als text/html
Feit is dat HTML4 natuurlijk verouderd is en HTML5 zo opgezet wordt dat het ook meer matched met real-world usecases. Je voorbeeld mbt target-names is in HTML5 dan ook aangepast: non-reserved names beginnend met een underscore zijn daar nog steeds non-conformant, maar useragents moeten ze wel kunnen verwerken. (note overigens dat in HTML4.01 mbt het negeren een SHOULD-directive wordt gebruikt en geen MUST).
Kortom: standaarden (of specificaties of aanbevelingen of whatever) zijn geen wetten in steen. Als er goede redenen zijn om iets op een ander manier te implementeren dan kan dat ook een goede reden zijn om op dat punt de standaard aan te passen. Als iedereen daarin samenwerkt is een 100% compliance ineens een stuk haalbaarder. Punt is echter dat MS telkens de kont tegen de krib gooit en dingen toch weer op een eigen manier doet om redenen die enkel voor
hun relevant zijn maar nadelig zijn voor de webstandaarden en de adoptie daarvan in het algemeen. Daarbij zijn ze ook zo koppig om niet in samenwerking met anderen te kijken naar betere oplossingen...