W3C home > Mailing lists > Public > public-html@w3.org > April 2007

Re: Versioning and html[5]

From: Kornel Lesinski <kornel@geekhood.net>
Date: Fri, 13 Apr 2007 23:38:05 +0100
To: "Chris Wilson" <Chris.Wilson@microsoft.com>
Cc: "public-html@w3.org" <public-html@w3.org>
Message-ID: <op.tqquhrisptj49s@g5.local>

On Fri, 13 Apr 2007 18:54:25 +0100, Chris Wilson  
<Chris.Wilson@microsoft.com> wrote:

> The real problem with this, as we have discovered it particularly with  
> IE7, is that we have no idea how bad the real-world problem is until we  
> ship, given the amount of content in intranets.

Could you implement a separate opt-in for intranets via zone-based  
configuration (and domain-based opt-out for web applications)?


I hope "Don't break the Web" can be achieved in a better way than strictly  
opt-in for all new fixes and features.

The problem is that many authors aren't aware that detail like DOCTYPE (or  
version attribute) can affect rendering of entire document (I still keep  
seeing developers convinced that IE can't handle CSS box model or that IE7  
doesn't support any new selectors). Authors tend to copy whatever they've  
used for previous project or accept whatever their authoring tools output.

There are still tools, templates, code libraries and tutorials that date  
back to early Netscape times. This is a catch-22: authors (and tools) will  
continue to use whatever works for them and browsers will have to keep  
bugs forever because pages continue to rely on them.

"Don't break the Web" is almost the same as "Keep the Web broken". With  
versioning browsers may build up layers over layers of bugs and Web will  
end up relying on _all_ of them. I hope we don't end up with IE10 keeping  
all the bugs since IE5 and forcing competitors to reverse-engineer bugs of  
5 or more browsers.


I think the shock and angst about changes in IE7 was because IE hasn't  
changed at all for so many years and authors forgot what happens when you  
rely on bugs. But sites get fixed quickly and it won't be a problem soon.

It's also in interest of content creators to be compatible with the  
dominant browser - no matter how broken, or how good it is. If IE gets  
fixed, the web will have to get fixed too. I'm not saying that IE should  
just ignore backwards-compatibility, but that not fixing any current bugs  
should not be considered as the best solution.


Microsoft could focus on making it easier for webmasters to recognize  
their mistakes and fix the code and then any necessary breakage wouldn't  
be affecting so many sites.

Many authors don't have slightest idea that there's something wrong with  
their code. This can be solved - make standard IE distribution warn about  
deprecated features and problems exposed by invalid code. Warnings don't  
have to be obnoxious, they just have to be noticeable in the standard IE,  
because very few authors will download additional toolkits/SDKs, but all  
of them test their websites in a vanilla IE version.
When a potentially important bug is planned to be axed in a future version  
of IE, you can display more prominent warning in an earlier version. Then  
nobody will get surprised when next version comes out and probably most  
websites will be fixed by then.

It's not completly transparent to users and maybe not the easiest strategy  
for Microsoft, but I think in the long term it's better than just waiting  
until buggy sites get fixed, because they won't - there won't be anything  
to fix until browsers break it.

-- 
regards, Kornel Lesinski
Received on Saturday, 14 April 2007 15:09:07 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:42 UTC