The New Standards Compliance Mode | The Coffeehouse

Massif
aim stupidly high, expect to fail often.

stevo_ wrote:
Dunno, perhaps we could get around this shti in the future by actually agreeing on a standard, and then a browser can only attempt to handle the standard once it's been signed off as 'yea, this is ok'..

This way, if a standards change is nec because something is hugely wrong with it, all the browsers are in the same boat, and the fix can be issued as a new version of the standard that would go through the same thing..

I know this is the way these things were intended.. but right now we're in a huge fcuking sandbox where nothing is complete, nothing is fully implemented and it's really god damn infuriating..

Well, that does rather mean that browser developers can only innovate fringe features, and not push forward development of the interesting stuff. They'll be at the mercy of the W3C for general advancement.

stevo_
Human after all

Not really, for one the W3C isn't the be all and end all for this kinda thing..

Look at it this way, a few years ago, nvidia implemented this feature into their GPU that became a minor controversy.. it was the ability to render HDR..

ATI at the time didn't have this because their GPU's lacked certain accuracy of components that make up HDR compositioning..

It wasn't so much of a mistake because they were saying, look we want HDR.. but what was ensured then was that the vendors and Microsoft would discuss standardization of features when targeting a DX 'x' compliant video card..

The consortium is already setup like I said, they all talk about future features and the implementation.. but there doesn't seem to be any 'laws' out there to enforce UA developers don't handle content they cannot hold..

It's almost like a certification.. congrats IE8 you can now handle this that and the other.. the certification comes from the consortium and so everyone works together..

We all talk about open source collaboration, yet one of the places that would benefit most from developer groups working together and sharing ideas for the good of the 'web' rather than for the sake of saying... AHAHAH look at us we have a fking well ace feature.. that only works on our UA

Edit, developers now aren't in any better place now than we would be 'at the mercy of W3C'.. not many people dare touch 'new' features..

They call these browsers IE8, FF3, Opera 9000?.. we're all still beta testers while they finish the implementation.. it's like launching a boat at sea by throwing all the wood and tools into the sea and expecting everything to be built as it goes along.. developers end up huddling onto the biggest safest pieces and wait for the mercy of the 'sea' to bring some other pieces along to make their raft bigger and more interesting..

evildictaitor
if( !succeed( try() ) ) { while(true) try(); }

Sven Groot wrote:

I have to add my vote that this is a bad idea.

It means that standards-compliant sites that exist today won't work as they should in IE8. Standards mode should be the default. You've set the precedent now with IE7 that people shouldn't rely on browser bugs. Continue that precedent.

The rule for sites should become: if it's a browser (or a version of a browser) I don't know, I give them the most standards-compliant version of my content I have.

IE more than any other browser has the power to enforce this.

I really really really don't like this idea. If they want a different switch, make it the XHTML 1.1 (or newer) DOCTYPE, or even the application/xhtml+xml MIME type. Don't introduce yet another arbitrary new meta tag.

Please everyone here who can talk to the IE team, please beg them to reconsider.

EDIT: Since it's a meta http-equiv, does that mean we can also configure our servers to send an actual header with that name? That'd be a bit better already. Still a bad idea though.

I suspect you'll be able to send a header, and presumably you'll be able to ask IIS or equivilent to just send it out with all of your pages.

The reason they can't enable standards compliance by default is that it means that lots of pages which don't get regularly updated will suddenly break.

Standards compliant pages as the stand won't "break" because of the lack of standards compliance that's available at the moment, because they've either already got some nasty hack to let IE work on their site, or they don't care about IE.

By enabling this mechanism either by a meta tag or by a header field (which I sincerely hope they do use as well) then ACID2 will work without modification of the HTML (because of the header) and sites that are currently standards compliant and work on IE will continue to work in IE8 (if they work in IE7, they'll work in IE8 quirks mode), and lots of sites with nasty hacks for IE will be able to start removing the hacks and switching over to standards compliancy with the standards compliant bit.

And it's not even as if this is such a terrible idea, because if this new header is available, it's not just available for IE8, it's also available for Firefox 3, so it'll be able to also distinguish between pages that should be rendered in standards compliance mode and ones to be rendered in quirks mode.

brian.shapiro
things go on as always

Sven Groot wrote:

I have to add my vote that this is a bad idea.

It means that standards-compliant sites that exist today won't work as they should in IE8. Standards mode should be the default. You've set the precedent now with IE7 that people shouldn't rely on browser bugs. Continue that precedent.

The point is for conscientious web developers to be able to code their site to look the same on any web browser, which they can do.

The standards-compliant sites that exist today, if they're worth anything, have been hacked to display properly on IE7, so there's nothing to worry about.

Standards for standards' sake isn't the point.

All future versions of HTML standards will render in standards mode by default

evildictaitor
if( !succeed( try() ) ) { while(true) try(); }

YearOfTheLinuxDesktop wrote:
couldn't just have enabled standards mode by default and then letting people who rely on quirks specify which version of the browser their page is "optimized", or should I say crippled, for so IE knows when to use the backward compatible rendering?

You're assuming that the sites which rely on quirks mode are being actively developed on. Many of the sites out there rely on Internet Explorer features that were deprecated absolutely ages ago, but if people keep using them, the IE team can't just remove them, or these sites will just break.

And if Vista is anything to go by, even a tiny amount of backwards compatability breaking will cause massive lashback on Microsoft.

Sites currently being built are being built for IE's quirks mode and Firefox 2. When IE8 and Firefox 3 become mainstream, people will start migrating wholesale (hopefully) towards standards compliance, but this means that the new sites with standards compliance will be able to be developed with this added switch on - if you're building an entire site like this, you can probably just ask ASP.NET or IIS to throw the header down with all of your pages anyway.

Once people have migrated away from quirks mode, turning down the option to use IE's deprecated "features" becomes a plausible option, but I don't see this happening for at least the first three to four years after IE8.

YearOfTheLinuxDesktop
Seven of Niner! Resistance is Futile!

couldn't the IE team just have enabled standards mode by default and then letting people who rely on quirks specify which version of the browser their page is "optimized", or should I say crippled, for so IE knows when to use the backward compatible rendering?

they can't go on like this forever with each IE version requiring a new tag, it's lame. they probably think that this way if the newer IE versions could introduce rendering bugs older pages wouldn't not be affected because developers specified which version of IE their targeting however they could still support a tag to specify which version of the browser is being targeted for webmasters that want to make sure everything will work well in the future.

Sven Groot
My name has 9 letters. Coincidence? I think not...

One disadvantage of using the header, I realised, would be that if people save the page and then open it locally it would look completely different. So you'd pretty much have to use the meta tag. Sad

Sven Groot
My name has 9 letters. Coincidence? I think not...

YearOfTheLinuxDesktop wrote:
IE7 despite being touted as backward compatible still breaks things even when it's being used in IE6 compatible mode. I've had to fix plenty of pages for IE7 despite I never enabled IE7 standards mode with the xml tag.

There is no IE7 standards mode. That was the point. IE6 had a standards mode and a quirks mode (quirks mode uses the completely broken box model from IE5). Standards mode was enabled using a DOCTYPE switch (basically pages with a new enough DOCTYPE get standards mode). IE7 left quirks mode alone but changed standards mode, which apparently broke pages coded for IE6 but which did have the DOCTYPE.

IE8 will have three modes:
- Quirks mode (IE5 behaviour, broken box model)
- Standards mode (IE7 behaviour)
- IE8 standards mode (ostensibly standards-compliant behaviour)

Current websites developed for web standards, which should have a DOCTYPE, will get standards mode, but not IE8 standards mode, so should continue to work as they did in IE8.

Unless the pages you referred to used quirks mode, and you're saying they made changes in that for IE7 as well, I think we can assume at least the backwards-compatibility part should work reasonably well.

elmer
I'm on my very last life.

Agreed, Standards mode should be the default for IE8, and for asp[.net] sites at least, injecting a quickmode metatag is easy enough to do at a site level... I dare say that if I needed to run my various sites in an IE7 legacy mode I could do it with a one liner before the page is rendered.

drhowarddrfine

Why this is bad.
Microsoft smoke.
IE is locking you in.

YearOfTheLinuxDesktop
Seven of Niner! Resistance is Futile!

evildictaitor wrote:
You're assuming that the sites which rely on quirks mode are being actively developed on. Many of the sites out there rely on Internet Explorer features that were deprecated absolutely ages ago, but if people keep using them, the IE team can't just remove them, or these sites will just break.

And if Vista is anything to go by, even a tiny amount of backwards compatability breaking will cause massive lashback on Microsoft.

Sites currently being built are being built for IE's quirks mode and Firefox 2. When IE8 and Firefox 3 become mainstream, people will start migrating wholesale (hopefully) towards standards compliance, but this means that the new sites with standards compliance will be able to be developed with this added switch on - if you're building an entire site like this, you can probably just ask ASP.NET or IIS to throw the header down with all of your pages anyway.

Once people have migrated away from quirks mode, turning down the option to use IE's deprecated "features" becomes a plausible option, but I don't see this happening for at least the first three to four years after IE8.

you're assuming that everybody will be informed of the standards compatibility tag while instead there will be a lot of people making pages that still target the IE6 rendering mode (by not placing the "standards compatibility" tag), intentionally ("my old page still works!") or not, and using quirks to get it working anyway. when in the future a new version of IE will drop IE6 compatibility mode all those websites will be screwed.

IE7 despite being touted as backward compatible still breaks things even when it's being used in IE6 compatible mode. I've had to fix plenty of pages for IE7 despite I never enabled IE7 standards mode with the xml tag so even if they make lots of efforts I think the backward compatibility will never be perfect.

I think that choosing to leave the crippled IE6/7-rendering mode by default is just postponing a choice that is unavoidable and is a bad example for for lazy developers that will just continue serving pages full of quirks made for previous IE versions thinking that the retrocompatibility will last forever.

the IE developers in order to mantain compatibility could still support a META tag that developers could use to specify which version of the IE the page was designed for to make sure their pages will be future proof however I believe it's better that they leave the standards mode as default or things will never start moving. after all we're talking of a browser that thinks that all pages were designed 8 years ago by default, it can't go on forever.

YearOfTheLinuxDesktop
Seven of Niner! Resistance is Futile!

Sven Groot wrote:

YearOfTheLinuxDesktop wrote:IE7 despite being touted as backward compatible still breaks things even when it's being used in IE6 compatible mode. I've had to fix plenty of pages for IE7 despite I never enabled IE7 standards mode with the xml tag.

There is no IE7 standards mode. That was the point. IE6 had a standards mode and a quirks mode (quirks mode uses the completely broken box model from IE5). Standards mode was enabled using a DOCTYPE switch (basically pages with a new enough DOCTYPE get standards mode). IE7 left quirks mode alone but changed standards mode, which apparently broke pages coded for IE6 but which did have the DOCTYPE.

I think I've got confused, the pages were made for IE5, I've made them compatible with IE6 by using the HTML 4.0 transitional doctype. I didn't use the xml tag used on IE6 to enable IE5-quirks mode that on IE7 instead triggers the standard mode but instead I used the doctype so on IE7 they should have been still compatible but they weren't since some divs had weird margings that I had to correct.

Sven Groot wrote:

IE8 will have three modes:
- Quirks mode (IE5 behaviour, broken box model)
- Standards mode (IE7 behaviour)
- IE8 standards mode (ostensibly standards-compliant behaviour)

Current websites developed for web standards, which should have a DOCTYPE, will get standards mode, but not IE8 standards mode, so should continue to work as they did in IE8.

but how will that encourage people to write standards-compliant page rather than writing them for the IE default standards-rendering mode? people could be writing seriously screwed up code because they're adapting it to the older rendering mode that IE is using by default without knowing it and someday when the compatible mode will change they will break.

Sven Groot wrote:

Unless the pages you referred to used quirks mode, and you're saying they made changes in that for IE7 as well, I think we can assume at least the backwards-compatibility part should work reasonably well.

no they used and they're still using quirks mode. I'm waiting for IE7 to replace almost entirely IE6 so I will finally be able to convert the standards-compliant firefox version of the page to IE7 without having to target IE6 too.

Sven Groot
My name has 9 letters. Coincidence? I think not...

YearOfTheLinuxDesktop wrote:
I think I've got confused, the pages were made for IE5, I've made them compatible with IE6 by using the HTML 4.0 transitional doctype. I didn't use the xml tag used on IE6 to enable IE5-quirks mode that on IE7 instead triggers the standard mode but instead I used the doctype so on IE7 they should have been still compatible but they weren't since some divs had weird margings that I had to correct.

That makes no sense. The HTML 4.01 Transitional DOCTYPE (if it includes a system identifier) will trigger standards mode on both IE6 and IE7. No "xml tag" is needed in either case. If you are referring to the XML declaration, that should never be used on non-XHTML documents and due to a bug in IE6 would prevent standards mode even if the DOCTYPE is present (this was fixed in IE7).

If your documents had a HTML 4.01 DOCTYPE and that DOCTYPE was the first line in the document, then your pages were using standards mode, not quirks mode, in both IE6 and 7. That's the mode that changed which they found broke compatibility. And that's the reason they don't want to change it again for IE8. Quirks mode should've remained the same for both browsers.

EDIT: I agree with your other arguments: remember, I'm not in favour of this meta tag switch. I'm just explaining why they're doing it.

YearOfTheLinuxDesktop
Seven of Niner! Resistance is Futile!

Sven Groot wrote:

YearOfTheLinuxDesktop wrote:I think I've got confused, the pages were made for IE5, I've made them compatible with IE6 by using the HTML 4.0 transitional doctype. I didn't use the xml tag used on IE6 to enable IE5-quirks mode that on IE7 instead triggers the standard mode but instead I used the doctype so on IE7 they should have been still compatible but they weren't since some divs had weird margings that I had to correct.

That makes no sense. The HTML 4.01 Transitional DOCTYPE (if it includes a system identifier) will trigger standards mode on both IE6 and IE7. No "xml tag" is needed in either case. If you are referring to the XML declaration, that should never be used on non-XHTML documents and due to a bug in IE6 would prevent standards mode even if the DOCTYPE is present (this was fixed in IE7).

If your documents had a HTML 4.01 DOCTYPE and that DOCTYPE was the first line in the document, then your pages were using standards mode, not quirks mode, in both IE6 and 7. That's the mode that changed which they found broke compatibility. And that's the reason they don't want to change it again for IE8. Quirks mode should've remained the same for both browsers.

EDIT: I agree with your other arguments: remember, I'm not in favour of this meta tag switch. I'm just explaining why they're doing it.

I used HTML 4.0 (not 4.01) Transitional that triggers quirks mode on both IE6 and 7. HTML 4.01 Transitional instead triggers standards mode. by the way this is getting more confusing with each browser version.

punkouter

i have another idea. how about changing the user agent identifier into something like: "interplanetary exploder" and make it always renders in standard mode? this will bypass almost all detection scripts that tries to fix ie quirks mode and have almost zero impact on users. Tongue Out

stevo_
Human after all

The reason this is there:

IE8 comes out, I make a site that targets it, IE8 still has some bugs in its implementation, and I work around them or use these bugs by mistake to get what I want..

Update comes out (ie9?):

My site no longer works because the bug doesn't work anymore..

This is how it's always been, so while I see the sense in 'freezing' the site to a specific 'renderer version', its depressing because its almost like saying 'standards will never be usable, so here's the hack'..

And its that which is depressing overall, where as my previous posts so far seem to really make sense to me, the web would move along at a consistent rate..

Its sad however, because nobody would listen to this, and perhaps a lot of people also have their thoughts on this idea, maybe its a bad one, maybe lots of other people want it to but its not happening..

I just really wish some of the people in power for opera, w3c, ie, firefox would comment on this and tell me their doing this, or something better..

Otherwise I think standard web (css/html/js) will never settle and be truly usable ..

AndyC

stevo_ wrote:
its depressing because its almost like saying 'standards will never be usable, so here's the hack'..

And the cold, harsh, truth of the matter is that's by far the most pragmatic approach to take. Every mail/ftp/DNS/whatever server out there probably has the odd hack to deal with a buggy old client or a vague section of a spec that could be interpreted in multiple ways. Ultimately accepting that, no matter how hard everyone tries, the standards will never be perfect is a big step towards moving the web forwards.

Now all it needs is for the W3C to finally cave in and provide a reference implementation so that browser developers and page authors can know how any given content is supposed to look.

W3bbo
The Master of Baiters

AndyC wrote:
Now all it needs is for the W3C to finally cave in and provide a reference implementation so that browser developers and page authors can know how any given content is supposed to look.

The stlyesheet specifications do come with "reference rendering" diagrams for many topics, but CSS is meant to be flexible. Different platforms are allowed to (nay, are meant to) render some things differently.

But yeah, perhaps a "baseline standard" needs to be devised for the "screen, desktop, graphical" media profile which has strict definitions. Whilst the W3C's goals of "usable" content are admirable, it runs against 99.9% of designers' intentions for it to "look the same", even if it isn't necessarily usable. (Think: people who believe you need a separate "mobile edition" of websites when stylesheets cover it fine already).