51 Security and future development?

It seems strange that nobody has mentioned potential security holes in maintaining old rendering engines and them being implemented into new browsers. Wouldn’t certain changes sometimes affect the rendering engine in future releases of software which could impact a small minority of sites that browser vendors may not be aware of?

Another issue that I can see emerging if this is put into practice is that business website owners stop updating their site with newer standards. We already have enough trouble convincing them that re-writing a site with accessibility and standards compliance in mind, how will this change when a site currently works in all browsers plus all future ones and therefore costs little to maintain, whereas embracing newer standards would lead to training costs and re-design costs?

The maintenence costs for this would be phenominal, imagine changes to the DOM 10 years down the line, imagine minor changes in browser behaviour that affect server-side issues, how would the browser-type be detected and so forth…

posted at 05:28 pm on January 22, 2008 by Gavin Mannings

52 WHO DOES THIS BENEFIT?

I read through most of the comments, thinking I was in agreement with most people, cursing Mr Zeldman for entertaining this as a good idea for even a second – but then I re-thought. It’s not as bad an idea as all that, seeing as there is a hole that needs to be plugged (legacy sites coded for IE6 by chiefly .NET developers), but surely this is just a leaky and mostly perished plug, applied when most of the water has already drained clear of the sink.

The time to add this meta declaration was on the release of IE7, because there was a much greater disparity between the standards support of that browser and that of IE6. IE8 seems to be shaping up to be pretty compliant. So as a web author I’m happy to serve mark-up/CSS in conditional comments for versions less than 8, and then wait for the IE8 release. If I’m coding according to standards and declaring DOCTYPE correctly, why won’t my code be future-compliant?

Furthermore, this IE7-compatible mode in IE8 won’t be the same as real IE7, but will just be a patch to avoid any predictable gotchas, or at least any predicted by the dev team of that browser. And as IE9 is released, the IE7-compatibility mode will likely just have even more quirks. So your putative bank will tell you, the agency, that all you have to do is put in this magic meta tag and their app won’t break in the new browser, when there’s no way that can possibly be predicted – and as Mr Gustafson pointed out in comment #43, it only takes one edge case. Would you as the agency warn the bank that the declaration is only a bad sticking plaster or would you allow yourself to carry the can once the app fails regardless?

And anyway, what’s the point? There are bugs in IE7, but we should already be writing to the standards and hacking back for specific browsers. Because Microsoft looks like it’s going to bring out the goods in IE8, more or less, that’s a strategy that should work well today even for IE. So what exactly is this fixing?

posted at 05:29 pm on January 22, 2008 by Douglas Greenshields

53 Untitled

I am not a browser vendor nor have I ever made a browser, so I don’t know what percentage of browser code is specifically devoted to rendering and scripting support, but I can say that it would seem reasonable to me that browsers may retire certain rendering modes as time passes. Broswers will have the ability to read the rendering modes of pages and report on that. If, over time, certain rendering modes start to take up a smaller and smaller piece of the content pie, it may be justifiable to end support for them. But, again, I’m not a browser maker.
…
That said, I am as concerned as anyone with code bloat and hope that knowing these engines will need to exist well into the future will provide the impetus needed to keep developers honest and their code clean.

I understand that some apparently simple changes to a layout engine require wide-ranging alterations to source code. Sometimes keeping code clean means throwing out the old stuff and starting again.

On a related note, computers (including those that drive mobile devices) are becoming exponentially faster and storage is much cheaper than it has ever been. If maintaining support for a legacy rendering and/or scripting engine adds an additional 5-10% to the size of the app, I don’t see that being a huge problem.

What about mobile phones? Where I work we have to account for every kilobyte of data and code that gets put into ROM. This simply would not fly.

[B]ut would like to bring up the fact that browsers may not implement a new rendering or scripting engine between releases, so IE9 may be the same as IE8, meaning no extra bloat would be added to the application. The same goes for any browser.

They may take the opportunity of a new browser release to modify the user interface, but I cannot think of any a situation where changing the browser’s major version number that hasn’t been accompanied by a change in the rendering characteristics of that browser.

posted at 05:30 pm on January 22, 2008 by Jonathan Price

54 Why put the burden on us?

Wouldn’t it be possible to reverse this?
Let IE8 work by default in standard compliance mode as it should but give the option of adding a metatag to regress to stupid-mode.
This way devs who can’t be bothered/are stupid/have stupid management/don’t have money or time to code to standards can use the metatag as a simple band aid while the rest of us can keep doing what we want to do; code to standards.

posted at 05:38 pm on January 22, 2008 by paul steffens

55 WHAT?

it’s not often i’m left speechless…

here’s a thought: if a site properly separates content from presentation (and behaviour, though admittedly that can complicate things slightly), then even if the rendering isn’t exactly “how the author intended”, the content (which is really what we’re trying to preserve in terms of digital preservation?) is still perfectly clear? and if somebody really needs to see it as it would have been rendered in an old browser, maybe it’s a case of making sure emulators are easily available? (i’m thinking along the lines of MAME, Amiga/Atari emulators, for instance)

and i agree with some of the previous comments that this sounds dangerously like an MS solution to a problem that MS created in the first place…

posted at 05:39 pm on January 22, 2008 by patrick lauke

56 solutions to problems

like an MS solution to a problem that MS created in the first place

Well, we want MS to come up with solutions for problems they’ve created. We just want the solutions to be tenable ones, not ones that require anyone who wants to do the right thing to do the wrong thing.

posted at 05:42 pm on January 22, 2008 by Robin Whittleton

57 Untitled

You said:

On a related note, computers (including those that drive mobile devices) are becoming exponentially faster and storage is much cheaper than it has ever been. If maintaining support for a legacy rendering and/or scripting engine adds an additional 5-10% to the size of the app, I don’t see that being a huge problem.

My response was:

What about mobile phones? Where I work we have to account for every kilobyte of data and code that gets put into ROM. This simply would not fly.

I realise that you did mention mobile devices, so simply assume I didn’t include the question, and just consider my substantive point.

posted at 05:42 pm on January 22, 2008 by Jonathan Price

58 Agree!

I agree with paul steffens.

To combine this with my proposal some comments before, why not add a new mime type for Microsoft css and then set the version info as metatag or http header:

<meta http-equiv=â€?Content-Style-Typeâ€? content=â€?text/mscssâ€?; version=“6” />

This would advise clients to use the Microsoft interpretation of css as in IE6. Any browser (including IE8) might then use this buggy css interpretation, or try to nevertheless use a standard css version, choke, not use any css or not render the page at all. This way even a FF4 might try to support that broken engine.

And, if that info is not present, the default should always be the w3c standard.

posted at 05:46 pm on January 22, 2008 by Siegfried Gipp

59 Browser identity

If old pages are rendered correctly by FF Opera and other “standard” browser, but not by IE, the source of the problem is probably “browser sniffing”. Pages are made to detect IE out of the crowd.
Now, what if MS changes the user-agent string (MSExplorer/8.0 instead of Mozilla/5.0, please don’t use “IE” in the UA string), and the variables names used in conditional comments (to counter-effect the bad use of <!—[if anyTest IE 6.0]>), replacing them with newer ones, wouldn’t it work better?
Old pages would see it as a new browser. Most of them won’t segregate it and display a lower version, but use the same version sent to FF and others. And with CC still available in the new version, new pages will still be able to test the current “new” browser.

If IE8 encounters – <!—[if lte IE 6.0]> ignore, just play like FF – <!—[if MSIE 8.0]> use it

same in js with “if (@_jscript_version > 5.6)”
change the variable name to something else and start fresh.

This, assuming that IE8 doesn’t need any of the corrections, or special settings driven by CC (CSS and JS).

One last fix: get rid of any IE-specific CSS hack, to ensure that old hacks won’t take effect.

IE8 can keep its quirks mode for pages without doctype.

posted at 05:49 pm on January 22, 2008 by Marc Boucher

60 How about "No"

My mother always taught me that if you don’t have anything nice to say, don’t say anything at all. I admit that I feel a bit guilty about what I am about to write, but I must get this off my chest.

As a motorist, I don’t want policies put in place that make it safer for other motorists to drive drunk. I want policies that smack them upside the head and then teach them the error of their ways.

Same thing here.

We shouldn’t be making it OK to write poor markup, just because someone once built a browser that would render that markup OK.

We should be educating these people as to why standards matter, and why their code should follow them.

To me this just sounds like a cop-out. One more step toward the argument, “Who needs standards when my non-sensical, half-assed markup looks just fine on my computer.”

posted at 06:09 pm on January 22, 2008 by Adam Connor

Got something to say?

Discuss this article. We reserve the right to delete flames, trolls, and wood nymphs.

Create a new account or sign in below if you’d like to leave a comment.

Forgot your password?

Subscribe to this article's comments: RSS (what’s this?)