IE8 en Acid2: Super standards vs backwards compatibility

Mwa, ACID2 is een behoorlijk uitgebreide test. Er word geroepen dat het enkel om foute HTML/CSS gaat, maar dat is niet zo. Dat is slechts een van de vele aspecten die in de test meegenomen worden. Als je hier kijkt zie je dat ongeveer alle belangrijke CSS-features getest worden, dus ook de basis waar je dagelijks mee bezig bent. Ik kan me voorstellen dat zulke tests ook ideaal zijn om nieuwe browser releases te testen.

Natuurlijk moet ACID2 geen doel opzich worden en is het nu wat gehypt, maar het is zeker nuttig om snel te kijken waar een browser (nog) de mist ingaat. Dat is ook het uiteindelijke doel:

quote:

Acid2 is a test page, written to help browser vendors ensure proper support for web standards in their products.

Volgens mij heeft men nooit gezegt dat dit alles-omvattend is ofzo...

JanDM wijzigde dit bericht 21-12-2007 14:42 (20%)

De enige goede tests zijn unit tests die één specifieke CSS property of een specifieke combinatie van properties testen. Dit is gewoon waardeloze rommel en zet web authors niet aan om standaarden beter te gaan interpreteren.

Maar even verder in dit topic...

Gister kwam ALA al met dit artikel over een of andere wazige nieuwe META tag die gebruikt gaat worden in IE8 om standard mode te gaan triggeren

quote:

Keeping the syntax simple
One key to ensuring that this browser “version targeting” was easy for developers to adopt was to make it easy to implement by hand or in an authoring tool. We considered many syntax options, including a conditional comment-like syntax, processing instructions a la the XML prolog, and even HTML profiles such as those adopted by the Microformats community, but few seemed to fit the job as well as the meta element.

Using a simple meta declaration, we can specify the rendering engine we would like IE8 to use. For example, inserting this:
code:

<meta http-equiv="X-UA-Compatible" content="IE=8" />

into the head of a document would make IE8 render the page using the new standards mode. This syntax could be easily expanded to incorporate other browsers as well:
code:

<meta http-equiv="X-UA-Compatible" content="IE=8;FF=3;OtherUA=4" />

In the interest of speeding up the processing of the lock instruction, it is important to prioritize the version targeting meta element in much the same way as we prioritize the character encoding information. In order to work, the meta element will need to be placed in the head of your document, as close to the top as possible. It can be preceded by other meta elements and the title element, but will need to be placed above any other elements—and you can’t add it into the DOM via JavaScript.

As those of you with keen eyes probably noticed, the meta element we are using here is of the HTTP-equivalent variety, which means we can set the following header on the server to get the same effect:
code:

X-UA-Compatible: IE=8;FF=3;OtherUA=4

We can also use both methods in concert. For example, it is possible to set a baseline lock on a whole site using the header method and then override that header on individual pages, as needed, using the meta element.

quote:

Extra credit: living on the “edge”
For those willing to throw caution to the wind, let the chips fall where they may, or any other manner of colloquialism for coding with reckless abandon, IE will support a keyword value of “edge:”
code:

<meta http-equiv="X-UA-Compatible" content="IE=edge" />

This option, though strongly discouraged, will cause a site to target the latest IE browser versions as they release. It is a far cleaner alternative than the inevitable hack of setting an arbitrarily high value—IE=1000, anyone? But with all of the benefits of version targeting, the “edge” value is probably not practical for anything but experimental websites. That’s because even Eric Meyer can’t predict layout or scripting bugs that may be accidentally introduced by a new browser version.

Vandaag kwamen deze 2 links binnen in mn rss reader;
MDSN post
en een rant van anne

Maar goed het komt er dus op neer dat we wéer *al* onze sites mogen gaan aanpassen om zeker te weten dat het werkt in IE8

Even een laatste quote uit het laatste comment op ALA wat volgens mij precies de spijker op de kop slaat:

quote:

25 Disastrous
I am sorry, but this can only be described as madness. We are talking about browser sniffing and code forking here, are we not? Although I appreciate the problem of dealing with legacy web documents, any solution that allows browser vendors to drift away from web standards and do their own thing is wrong, wrong, wrong.

That’s because even Eric Meyer can’t predict layout or scripting bugs that may be accidentally introduced by a new browser version.

There shouldn’t be a need to do that. If a new browser version emerges with such bugs, the developer community should notify the browser vendor so that they can roll out an update that fixes the problems.

This kind of feature also opens up the possibility of allowing browsers vendors to start creating device-specific browsers. Already, I see completely unnecessary iPhone-specific sites springing up all over the place – a slap in the face for CSS standards designed to cope with many devices.

No. This seems to be something conjured-up for the benefit of Microsoft, and not for the benefit of the web or the developer community.

posted at 01:04 pm on January 22, 2008 by Simon Jessey

SchizoDuckie wijzigde dit bericht 22-01-2008 14:21 (16%)

Dit is echt wel een van de minder goede ideeën die ik de afgelopen tijd heb gehoord:

quote:

If you (the page developer) really want the best standards support IE8 can give, you can get it by inserting a simple <meta> element. Aaron gives more details on this in his article.

Na meer dan een jaar werken heeft het IE-team nu een plaatje van smiley laten zien en een meta-tag bedacht die voor web-ontwikkelaars op de lange termein alleen maar meer werk oplevert.

Ik las het bericht op het IEblog en op ALA. In het begin was ik nog niet zo heel erg op tegen. Nu heb ik echter de artikelen gelezen, de reacties doorgenomen en ook zelf nog eens zitten denken. Ik word steeds minder positief. Ik ben benieuwd want andere er van denken, maar ik vraag me toch sterk af of dit de beste optie is op de lange termijn.

quote:

OkkE schreef op dinsdag 22 januari 2008 @ 14:40:
Ik ben benieuwd want andere er van denken, maar ik vraag me toch sterk af of dit de beste optie is op de lange termijn.

Dat hoef je je niet af te vragen. Legacy is altijd k*t op de lange termijn.

Zeuren helpt toch niet, dus het positieve wat ik er aan zie:

Als een document ge-version-target is op IE=8 en IE8 heeft een of andere rare bug (zeg de <marquee>-tag loopt altijd de verkeerde kant op) dan kan Firefox er tenminste voor kiezen om dit gedrag te emuleren om zo het beste de intenties van de ontwikkelaar weer te geven.

Het vervelendste is nog dat het nu lijkt dat als je geen version target voor IE dat je dan in de IE7 modus vast zit, wat zoveel betekent als dat je wel moet gaan version-targetten in een document wat zich aan de standaard houdt.

quote:

Voutloos schreef op dinsdag 22 januari 2008 @ 14:46:
[...]
Dat hoef je je niet af te vragen. Legacy is altijd k*t op de lange termijn.

Amen. De gevolgen kan ik nog niet helemaal overzien (daar moet ik vanavond maar eens over denken), maar ik krijg gewoon een vreselijk naar gevoel van de verschillende posts.

Zoals ik op de frontpage een quote plaatste:

quote: http://www.readwriteweb.com/archives/firefox_3_plans.php

While IE7 and Firefox 2 were more alike than different (feature-wise they're practically identical!), with IE8 and FF3 we will likely see the two biggest browsers head off into different directions.

quote:

CyberSnooP schreef op dinsdag 22 januari 2008 @ 14:53:
Zeuren helpt toch niet, dus het positieve wat ik er aan zie:

Als een document ge-version-target is op IE=8 en IE8 heeft een of andere rare bug (zeg de <marquee>-tag loopt altijd de verkeerde kant op) dan kan Firefox er tenminste voor kiezen om dit gedrag te emuleren om zo het beste de intenties van de ontwikkelaar weer te geven.

Het vervelendste is nog dat het nu lijkt dat als je geen version target voor IE dat je dan in de IE7 modus vast zit, wat zoveel betekent als dat je wel moet gaan version-targetten in een document wat zich aan de standaard houdt.

Dat is toch geen optie Dat is intentioneel een bug in een andere browser naboosen. Dan moet MICROSOFT fixen dat die troep het gewoon doet in IE 8.0.0.1 en dan werkt alles weer goed. Dit is de omgekeerde wereld wat je nu voorstelt. Dan moeten dus Opera, Mozilla en Safari ontwikkelaars hun browser aan gaan passen zodra microsoft weer een of andere wazige bug heeft die optreedt zodra de stand van de zon en de maan niet kloppen?

Wat wél een goed idee zou zijn imo is deze zelfde meta tag implementeren voor sites die dan zo nodig (door IE8+) volgens een oud rendermodel van IE gerenderd willen worden en verder dat ding automagishc in standards mode schoppen. Dan hoeft alleen alle legacy troep die in weet ik veel welk wazig geval niet goed werkt aangepast te worden en dan kan het nieuwe web gewoon meegroeien zoals het hoort.

SchizoDuckie wijzigde dit bericht 22-01-2008 15:07 (6%)

quote:

JanDM schreef op donderdag 20 december 2007 @ 08:43:
[...]
Als het via een opt-in switch gaat betekent dat wel dat ze de ACID2 test gewijzigd hebben, en dat ze 'm dus eigenlijk niet halen

Okee. IE8 slaagt dus niet voor de ACID2 test

quote:

SchizoDuckie schreef op dinsdag 22 januari 2008 @ 14:57:
Dat is toch geen optie Dat is intentioneel een bug in een andere browser naboosen.

Wat is quirks mode in Firefox nu dan?

quote:

CyberSnooP schreef op dinsdag 22 januari 2008 @ 15:04:
[...]

Wat is quirks mode in Firefox nu dan?

Dat is proberen van iets wat bagger is toch nog iets te maken, inherent aan HTML en het web zoals het er nu staat. Quirks mode garandeert *NIET* dat het er exact hetzelfde uit ziet als in IE.

quote:

SchizoDuckie schreef op dinsdag 22 januari 2008 @ 14:57:
Wat wél een goed idee zou zijn imo is deze zelfde meta tag implementeren voor sites die dan zo nodig (door IE8+) volgens een oud rendermodel van IE gerenderd willen worden en verder dat ding automagishc in standards mode schoppen. Dan hoeft alleen alle legacy troep die in weet ik veel welk wazig geval niet goed werkt aangepast te worden en dan kan het nieuwe web gewoon meegroeien zoals het hoort.

Juist, dan heb je vooruitgang en een manier om (een tijdje) aardig te doen richting oude applicaties als men dat expliciet aangeeft.

euh?

quote:

We can also use both methods in concert. For example, it is possible to set a baseline lock on a whole site using the header method and then override that header on individual pages, as needed, using the meta element.

sinds wanneer gaan META-elementen voor op HTTP headers?

en verder hoef ik hier geen woorden meer aan vuil te maken, Microsoft heeft gewoon alle eerdere waarschuwingen en bezwaren die geuit zijn sinds Chris Wilson op de HTML-WG mailinglist al hintte naar deze waanzin naast zich neergelegd en doet gewoon wat ze wil. Dit is inderdaad een 'slap in the face' van alle serieuze webdevelopers...

quote:

crisp schreef op dinsdag 22 januari 2008 @ 15:16:
euh?

[...]

sinds wanneer gaan META-elementen voor op HTTP headers?

Microsoft kennende gaat dat op volgorde van verwerking Http headertje komt eerst binnen en kan daarna nog overschreven worden

quote:

CyberSnooP schreef op dinsdag 22 januari 2008 @ 14:53:
Het vervelendste is nog dat het nu lijkt dat als je geen version target voor IE dat je dan in de IE7 modus vast zit, wat zoveel betekent als dat je wel moet gaan version-targetten in een document wat zich aan de standaard houdt.

Jawel, je kan IE8 targeten met de meta-tag. IE7 door simpelweg in standards-mode te werken, zonder de meta-tag. IE6 door niet in standards-mode te werken. IE5 en IE5.5 zijn niet te targeten, maar dat kan nu ook al niet geloof ik. Daarnaast kan je nog met conditional comments dingen regelen, toch?

Nu ik dat zo schrijf: wat is nu precies het verschil tussen deze meta-tag en de conditional comments? In beide gevallen ben je expliciet IE8 aan het targeten toch? Of werkt een conditional comment voor IE8 weer niet als je IE8 niet als meta hebt?

conditional comments zijn puur bedoelt voor het opgeven of laten negeren van bepaalde elementen in een document, deze 'switch' dicteert de complete redermodus van de browser (inclusief JScript, CSS, DOM etc. behaviour).

quote:

Harm schreef op dinsdag 22 januari 2008 @ 15:27:
CyberSnooP: als je geen version target voor IE dat je dan in de IE7 modus vast zit

Jawel, je kan IE8 targeten met de meta-tag. IE7 door simpelweg in standards-mode te werken, zonder de meta-tag.

Dat is wat ik bedoel. Werk je in de standaard zonder iets IE-specifieks (zoals de version target), dan werkt IE in zijn IE7 modus, terwijl (waarschijnlijk) IE8 dichter bij de rendering komt die de standaard voorschrijft.

Wil je in IE8 dus gewoon de meest-standard-compliant-modus hebben, dan moet je mee doen aan deze version targetting puinhoop.

Ik vind het ook niet erg prettig dat er weer een nieuwe trigger wordt toegevoegd. Ik wil gewoon standard compliant coden en me vervolgens geen zorgen hoeven te maken over welke browser mijn website bezoekt, of welke browser in de toekomst mijn website zal bezoeken.

De ideale situatie is dat er geen enkele rendering trigger is, en dat alle websites en browsers zich volledig aan de standaarden houden. Door een extra trigger te maken in de vorm van het meta element drijf je verder af van deze ideale situatie.

Met IE legacy kan je (waar nodig) voorlopig rekening houden in de vorm van conditional comments en doctypes. Niet óók nog met het meta element.

quote:

Harm schreef op dinsdag 22 januari 2008 @ 15:27:
[...]
Nu ik dat zo schrijf: wat is nu precies het verschil tussen deze meta-tag en de conditional comments?

Een conditional comment word door andere browsers gezien als, surprise, commentaar. Enkel IE doet wat met dat gedeelte, en enkel de versie die je target. De meta-tag is anders. Een document met een compatible-with-IE8 meta-tag zal IE9+ en andere browsers 'dwingen' om IE8 (inclusief de bugs, 'features', etc.) na te doen.

Elke IE-versie zal dus praktisch gezien een nieuwe render-variant met zich meebrengen. Wil jij over 5 jaar een nieuwe browser bouwen, dan kun je beginnen met het implementeren van de IE8, IE9 en IE10 quirks voor docs met deze meta-tags...

JanDM wijzigde dit bericht 22-01-2008 15:58 (18%)

quote:

CyberSnooP schreef op dinsdag 22 januari 2008 @ 15:49:
[...]
Wil je in IE8 dus gewoon de meest-standard-compliant-modus hebben, dan moet je mee doen aan deze version targetting puinhoop.

Dat niet alleen, het is gewoon weer een complete lock-in. Dit geeft Microsoft een vrijbrief om voor elke komende versie IE de rendereigenschappen te wijzigen in plaats van implementatiebugs in de engine zelf te fixen. Bij IE versie 10 zitten we dan dus met 3 nieuwe rendermodi die niet alleen ons extra werk opleveren maar ook de andere browservendors die ook deze 3 modi moeten ondersteunen om marktaandeel te kunnen blijven houden (en dat kunnen ze dan weer alleen door de quirks en eigenschappen van elke modus te reverse-engineeren wat meestal toch nog compatibiliteits-problemen oplevert).

Microsoft zegt hiermee dus eigenlijk: wij kunnen/willen/zullen niet volledig standards-compliant zijn met IE8 (anders hadden ze bijvoorbeeld de HTML5 DTD wel als switch kunnen gebruiken) en we weten ook niet of we dat met latere versies wel zullen zijn.

Verder scheppen ze hiermee de mogelijkheid voor allerlei obscure bedrijfjes om deze 'switch' te misbruiken voor allerhande andere proprietaire renderdoeleinden wat juist weer een ondermijning is van de hele standaarden-beweging. En dan is notabene het WaSP ook nog hierbij betrokken geweest (ook al is dat nooit meer geweest dan een elite-clubje van mensen die denken dat ze de wijsheid in pacht hebben).

http://www.alistapart.com/comments/fromswitchestotargets/ meer leesvoer + achterliggende gedachtes...

Ik ben nog steeds tegen... Als IE8 een bug introduceert dan hoort 2 weken later IE 8.0.0.1 uit te komen en die moet die bug fixen. NIET IE 10.2 pas, dáár ligt de verantwoordelijkheid gewoon bij microsoft om z'n shit eens wat vaker te updaten, dat schuiven ze nu keihard af naar de gene die de webpaginas maakt Vanaf mozilla komen er ook een paar reacties die het ook zo zien gelukkig.

Ik had nou juist het idee dat we met z'n allen op weg waren naar een beter internet enzo, dat iederene z'n best deed om zich aan de standaarden te houden en alles volgens de standaarden te laten werken, Maar zoals het in bovenstaand verhaal staat, krijgen we straks IE 15, die óók de render engines van IE 14,13,12, 11, 10, 9 én 8 en 7 en 6 met zich mee draagt

SchizoDuckie wijzigde dit bericht 22-01-2008 16:12 (42%)

Da's wel fijn zo, ja. Je kunt kiezen tussen die meta-tag meesturen, of niet, en in dat laatste geval... wordt IE8 een verloren versie?

Ach, IE waar we echt wat mee kunnen, ik heb de hoop een tijdje geleden eerlijk gezegd opgegeven en IE8 lijkt die hoop niet te herstellen. Integendeel, ik zie geen reden om aan te nemen dat MS ooit echt een browser released waarvan we denken "ahh, daar is ie, perfect, eindelijk".

[edit]
uit de blogpost op mozillazine:

quote:

it seems to impose a crippling burden on IE development.

Da's ook echt iets nieuws, ja.

Cyphax wijzigde dit bericht 22-01-2008 16:23 (14%)

Wat is dan wel de oplossing volgens jullie? Standaard IE in übermodus laten renderen kan niet, dat breekt zowat het gehele web op (alle niet-conforme websites). Standaard in crappy-modus is niet elegant.

Mijn idee is dat het W3C een nieuwe HTML-versie moet maken, een pseudo-versie wel te verstaan. HTML 4.02 is dan exact hetzelfde als HTML 4.01, maar het geeft de renderengine van IE een sein dat de site conform de standaarden is gemaakt. (Evenzo voor XHTML.)

Voordelen? Nagenoeg geen extra werk voor alle andere browsers. Het web blijft leesbaar. IE kan met de tijd mee.

Nadelen? Het W3C moet een versie uitgeven die nergens op slaat. Alleen, is het W3C er om alleen standaarden te bedenken en het web vooruit de duwen of moet het W3C deze kans aangrijpen om de grote problemen met IE (en dus, hoe je het ook wendt of keert, een groot deel van het web) op te lossen?

quote:

-Lars- schreef op dinsdag 22 januari 2008 @ 16:30:
Wat is dan wel de oplossing volgens jullie? Standaard IE in übermodus laten renderen kan niet, dat breekt zowat het gehele web op (alle niet-conforme websites). Standaard in crappy-modus is niet elegant.

Wat een onzin. Firefox, Opera en Safari werken toch ook op 99.99% van de sites? Als standards-mode fouten detecteert gaat ie naar quirksmode en werkt je site nog gewoon. Het is HTML met wat CSS hoor, geen zwaar ingewikkelde binaire taal ofzo...

Die blogs van mozilla halen trouwens ook een leuke kwestie aan: Wat gaat er gebeuren als je vanuit een standards compliant IE8 document de DOM probeert te benaderen van een IE7/6 document in een iframe?

SchizoDuckie wijzigde dit bericht 22-01-2008 16:33 (17%)