JD on EP

I think you're right on here.

This becomes an acute concern with regard to archiving and preservation of digital objects too. Emulation is a dubious way to expect future preservation and it would be good to have a solid, well-specified publicly-known representation instead.

Looking at the Zeldman and Gustafson posts, it seems that the biggest problem is that the system is so broken that there may be no technical way out of it.

Maybe some new doctype would be one that must be strictly enforced by browsers and sites that get it wrong won't render. But I somehow doubt we will get to that. Ah, playing the Nazi DOCTYPE card, are we orc?

Here's more grist for these ruminations:
http://www.quirksmode.org/blog/archives/2008/01/the_versioning.html

This is a new angle. Because HTML is under-specified and because there is this problem of the DOCTYPE not actually being definitive in actual use, a different mechanism is being used for the version-of-rendition determination in IEx. I bet the meta-tag will be abused (i.e., used incorrectly) too, and treating it strictly will be very interesting.

This strikes my geekness as making the best of a bad situation. My prudent self suggests that this is at a level of detail that is below most people's degree of carefulness and it might simply fail. We'll see.

Drew McLellan (and commenters) chime in here:
http://www.webstandards.org/2008/01/22/microsofts-version-targeting-proposal/

I want to amplify my observation above about degree of carefulness. There are details that are simply below our level of attention and concern (like protecting our passwords, choosing them well, etc.). The problem has to do with the devil being in the details and details not being what most of us are attentive to when they are incidental to our main concerns (writing cool new code or whatever).

The additional problem in an interoperability situation is that our work is subject to the lack of care of others. Most people don't know what DTD gets slapped onto Blogger posts and whether or not the RSS feed from the same post lies about the format of the content (i.e., HTML vs. XHTML), and so on. So even if I wanted to take care of the details, my tools mess it up anyhow because they leak abstractions, fail to enforce their own claims, etc. Incoherence as the result of a chain of conflicting carelessly-introduced behaviors is not much most of us can do anything about.

Here is where I wring my hands and wonder how to make a post of my own about this. Thanks for the sounding board.

Thanks for the followups. I'm glad I'm not responsible for all this.... ;-)

jd

John,

I completely agree with you - HTML should essentially be versionless (with HTML5, which was published as a First Public Working Draft today).

By the way, I'd like to point out that this proposal is mostly because of Microsoft's policy on not breaking the web in their unique situation of having let the dominant web browser stagnate in the marketplace without moving it forward in terms of standards support. Yes the proposal mentions other browsers, but so far all talk from them seems to pan this idea.

Regards,
Jeff

I think lots of people agree with you, Jeff... in addition to the links from Dennis above, the IEBlog is pretty hot today, and Slashdot got into it a few hours later.

Seems like there are two different issues here:

(a) How "should" a standards process work?

(b) Now that we're in this situation, how should we get out?

Today I was thinking about how Dreamweaver started... the big selling point at its launch was "it leaves your code alone", but a major reason for its development was to reconcile the JavaScript functionality originally offered by Netscape Navigator, and the different functionality later offered by Internet Explorer. Overall, though, I'd rather have document creation be a lot more accessible to a lot more people.

Forgive me if I'm being naive, but we're currently surviving pretty well with the problem rooted in place: IE7 busts pages that declare a DOCTYPE, then deviate from it by depending on IE6 quirks.

The web has not ground to a halt as a result of this.

The sensible thing to do, is LEAVE IT BE.

For five years, the panic line graph was steady, because IE6 didn't change rendering behaviors. It blipped when Firefox gained marketshare. It's gone a little sporadic with IE7 actually checking DOCTYPES.

Adding yet another condition is just going to create more disruption, extending the amount of time the panic line graph will oscillate instead of smoothing out. Give developers more time to fix things up.

IE8 should behave like IE7, 2 modes: quirks and standards. Developers who've already fixed declarations for IE7 will actually be ahead of the game. IE8 will be the second wake up call for those who haven't. However, the fixes needed will remain the same.

Spec'ing a run-time environment for your HTML is a horrible idea, it is almost impossible to account for all the available runtimes on the market now with mobile and desktop-offline clients like AIR and Prism. The future is only going to generate more.

Introducing a 3rd behavior only introduces more chaos and disruption, especially since it's introducing an MS spec, not a W3C standard. Unless this is what MS wants.

Lots more discussion overnight.

I like how clearly and neutrally Maciej Stachowiak describes how Webkit approaches the issue, the impact on mobile browsing:
http://webkit.org/blog/155/versioning-compatibility-and-standards/

Joe Wilcox, of Microsoft Watch, has pulled together highlights from varied conversations, and ends up not quite buying the proposal:
http://www.microsoft-watch.com/content/web_services_browser/fliipping_the_ie8_kill_switch.html

Joe Clark laid out the situation clearly too, although he does close with a startling call to end-of-life Internet Explorer:
http://www.isolani.co.uk/blog/standards/EndOfLineInternetExplorer

Lots more "day after" comment is brought together at this Techmeme record:
http://www.techmeme.com/080123/p97#a080123p97

Daniel Goldman also collects pullquotes from browser makers and web luminaries:
http://operawatch.com/news/2008/01/opera-mozilla-and-safari-react-to-ies-solution-for-browser-compatibility-issues.html

Me, I'm still thinking about the same as yesterday. I don't know what "the answer" is, but I do still believe that -- if we want to encourage everyone to follow a certain set of behaviors -- that it's easiest when those standards are as direct, as understandable, and as accessible as possible. Complexity imposes costs.

I think the big problem with this new meta-tag is waisting time of hordes of web developers, each of them now must participate in the IE versions incompatibility task solution in explicit manner.

Let's estimate the time:

a) Total time web developers must spend on changing their code according to this "solution" from Microsoft.

b) Total time needed for few talented programmers to make the real solution by coding the right IE browser, compatible with previous.

I guess time "a" will be much times bigger that time "b". It's about human life time.

I hope Microsoft will fail with this "innovation".