71 The doctype ISN'T broken

I must preface by saying that I am wholly in shock at the suggestion of going back to browser specific rendering. This seems a giant step back in time.

Browser sniffing by any other name is still browser sniffing. And it stinks.

Keep in mind that all the hacks and workarounds for IE are just that – hack and workarounds used to compensate for IE’s lack of ability to implement relatively straightforward simple clear standards. Therefore it falls upon web developers to fix their hacks – not browser manufacturers. Be responsible for your work. New meta directives are not needed to correct this.

Implementing a new meta directive to select which browser versions that you want your site to work in strikes at the very heart of web standards. How does this in any way, shape manner or form help standardize anything? It does not. In fact it is difficult to imagine anyone that values a web industry based on standards and open access even contemplating a scheme like this.

It does seem that IE is promising a holy grail, beckoning us to come up from the swamp that we wallow in, hoping all the while that we forget that it is they who made the swamp in the first place.

Does all this seem patently absurd to anyone else?

posted at 09:18 pm on January 22, 2008 by David Cocuzzi

72 See a few Problems

While I see where the author is coming from with this idea a few this bother me.

I worry about new set vulnerabilities that could appear with this browser lock idea. Lets look at this with the eyes of a hacker. Using the mixing of browser versions on one page, or browser window, can I use the security vulnerabilities, or standard abilities, from one browser version to take over, hijack, steal, or obfuscate the data in another version.

You think XSS is a problem, now all the browsers will have to deal with XBS (cross browser scripting)

I think this might be a can of worms that might be best not opened.

posted at 09:20 pm on January 22, 2008 by David Gutierrez

73 A little confused

Okay. After thinking about this for a while, I’m confused.

What is a browser supposed to do with this tag. We have one use case at the moment: IE8 only renders fully standards compatible if and only if the web page is marked compatible with IE8.

Does that mean IE8 acts like IE6 otherwise? Are transparent PNGs broken? Does it pollute the global JS namespace? In what way does it work like IE6?

So if FF3 applied this, would it act like FF2 unless FF3 is marked compatible?

I’m confused. Is this meant to lock the web to it’s current version?

Regarding the amount of work needed to leave quirks available: It’s hard and requires a lot of code. A lot of the quirks are actually bad architecture decisions. If you change the architecture, that means you have a whole ‘nother code base to manage. I imagine the hasLayout() was fixed by actually fixing the design. That means that they have to emulate the old architecture. How can a web designer be sure that they will emulate hasLayout() correctly?

I think emulating old bugs is a waste of browser developer time and will just lead to wonderful hacks like “Well, if you use IE=6 compatibility, you have to work around hasLayout() like this, but if you actually are IE=6, then you need to do this instead so you can detect if this is IE6 or not by….”

Ciao!

posted at 09:29 pm on January 22, 2008 by Christian Holtje

74 OS Versioning

This versioning seems to assume that a browser is the same across all platforms, as well. Shouldn’t there also be versioning of the operating system? We know from the past that, for example, IE5 for Mac was quite different than IE5 for Windows: doesn’t this versioning assume that Firefox 9 (and all browsers) is the same across all platforms? Or does the versioning get more complex?

posted at 09:30 pm on January 22, 2008 by Vincent Murphy

75 DITTO ON THE OPT-IN THING

When I wrote my previous comment (ungrammatical subject header and all) I hadn’t read the part yet where it was explained that a web author would need to declare this meta tag in order for pages not to render like IE7 (or IE6?). So what percentage of the pages published to the web are likely to render any different in IE8? If that percentage were as low as I expect it will be, much of the world will then be running a hobbled browser in emulation mode, and if that percentage were high, wouldn’t we just be polluting the web with what is effectively proprietary MS declarations (as the other browser vendors surely won’t touch this suggestion with a hundred foot pole)? And won’t we have to then change our meta tags when IE9 is released so it can properly render what was already perfectly compliant, validating mark-up? When will it end (it will end, right)?

Nope, this is all the very epitome of that which is bass-ackwards.

posted at 09:50 pm on January 22, 2008 by Douglas Greenshields

76 suggestion

Here’s an idea that came up on a mailing list I’m discussion this topic on:
This problem is more or less IE specific only. All other browser vendors just looks forward with the current version being the only one. So how about when IE8 renders a page that it suspects might look weird (because it’s coded correct) it will pop down one of those nifty little bars saying “This page might look weird to you. Wanna try showing it in IE7 mode? [Yes] [No] [Always for this site] [Don’t ask this again]”.

Everyone happy?

posted at 10:17 pm on January 22, 2008 by Andreas Lanjerud

77 suggestion

Oops, I messed up. This is what I intended to write: “This page might look weird to you. Wanna try showing it in IE7 mode? Yes / No / Always for this site / Dont ask this again”

posted at 10:19 pm on January 22, 2008 by Andreas Lanjerud

78 yeesh...

I’m a bit hesitant to comment so soon after reading this, but after a couple hours mulling it over it still seems like a bad idea in many ways. First of all, the goal of developing with progressive enhancement is to make things forward-compatible and embrace “enhancements” as they come out. Since we are building using web standards and fairly compliant browser rendering, we can safely assume that future browsers will not drastically “break” what we build today. For backwards compatibility we have conditional comments, and as older versions of IE slip off the traffic map we can remove the conditionals accordingly. In my experience so far, this approach actually works really well!

So assuming this idea gets implemented, aren’t we punishing the wrong people? In order to continue building using progressive enhancement, we will now have to add a new meta tag specifying “edge”? Shouldn’t it be the default for a browser to render using the latest and greatest it’s got? Does this mean we have to dig back into all our future-proof sites on the web and add this tag to keep them future-proof? For the sites out there that are breaking now because they were built for IE5, isn’t this the job of that site’s developers to update things to proper standards?

At the very least, I really hope the default behavior will be to use the current rendering engine if no override is present in the markup.

What will motivate users to upgrade their browsers if the sites they use can’t take advantage of any of its new features?

posted at 10:38 pm on January 22, 2008 by Scott Jehl

79 Browsers should not suck by default.

Aaron: For the benefit of future readers who’ll come across your article through googling and don’t know context, I think you should make it more clear in your article that FF=3; is just an example, and won’t actually work unless Gecko devs support this – which it looks like they strongly don’t intend to . (For, as you can read there, very good reasons; reasons which in due time will apply just as much to IE.)

Version targeting is a short-sighted non-solution, and any widespread use of the practice will leave the web in a worse state than it currently is in.

Personally I don’t intend to implement this silly switch in my websites unless I really have no choice. They’ll be readable just fine in old-IE, but all the real beauty is reserved for modern browsers. If MS thinks it does IE8’s users less of a disservice by having a default mode of emulating its broken predecessors than by operating to its full capability… well, then that’s just too bad for them.
In those cases where I don’t have a choice, what I’ll implement is the “edge” version. That’s the way the browser should perform by default.

posted at 11:04 pm on January 22, 2008 by Sander van Lambalgen

80 Why?

First: Most of this would already be possible using Conditional Comments. As most of the professional webdevelopers must use them already it should be easy to just skip IE8 in all those extra-shyesheets and give IE8 the version every other browser renders without problems.

Second: The DOCTYPE-Switch actually was the right solution. The problem is not the Switch itself, it is the IE. Not only the developers did not improve the rendering for websites, that webstandards would work correctly, they even implemented a standards mode, that is terrible broken. This could have been fixed with continuous releases of new versions to keep up with other browsers. Again, IE missed this oportunity and has to work around this self-made issue now.

Third: Having to support old, broken versions of some software is a pain. You at Microsoft should know that. ;-)

Fourth: Every other browser works fine in standards mode. This workaround would only help IE development. I don’t see any reason to change standards or add things to standards only because one vendor failed to do things right in the first place.

Just my 2 cents.

posted at 11:13 pm on January 22, 2008 by D D