W3C home > Mailing lists > Public > www-archive@w3.org > April 2007

Re: Versioning and html[5]

From: Mike Schinkel <w3c-lists@mikeschinkel.com>
Date: Sat, 14 Apr 2007 06:03:40 -0400
Message-ID: <4620A6FC.6020408@mikeschinkel.com>
To: www-archive@w3.org

Chris & Ian/Lachlan/et.al.:

I've read this entire thread on versioning HTML and from the "outside" 
it seems Chris has valid reasons why Microsoft can't break the web, and 
Ian/Lachlan/et.al. have valid reasons why their approach make sense. But 
it also seems everyone is talking past each other and have created a 
rock and a hard place where nobody is really listened to the other's 
perspective. Worse, what I don't see is anyone trying to think outside 
the box in an effort to address everyone's concerns.

The crux of the problem appears to be that the web is full of tag soup, 
and that means IE has to render tag soup including those things that 
deliberately make use of bugs in IE. And that's fair. But I've now heard 
both sides about how that problem should be addressed, ad nauseum. What 
I've not heard is any discussion of how to minimize the tag soup problem 
itself. So let's start with that, shall we?

I believe that vast majority of improper use of HTML on the web is 
because site owners and web developers don't know any better. And I 
don't mean that they don't know any better in the abstract, most 
probably do, but when they look at their company's home page or the web 
page they just developed nothing tells them it is invalid unless they 
just finished proactively validating it.  And my guess is that 
0.0000135% of pages on the web have been proactively validated (give or 
take a few hundred thousandths of a percent. ;-)

I'll further bet that if the main browsers in the market (i.e. IE, 
et.al.) were to have a green/yellow/red page validity icon where green 
means valid, yellow means deprecated tags in use, and red means invalid 
then most web developers would take is as a badge of honor to make all 
their pages on their site shine green.  These little icons, when clicked 
could provide the user with a full description of why it is green (and 
maybe even suggest they inform the site owner <evil grin>.)

Now the above proposal would be necessary but not sufficient as it 
doesn't resolve the debate, it just minimizes the problem. Next let's 
*really* think outside the box and, please, do me a favor and spend some 
time first trying hard to think about how my proposal *might* work 
instead of immediately telling me every reason why it won't.

To date, every discussion of rendering the web assumes that a browser 
assumes any given web page renders only one way. Why not provide an 
explicit set of multiple rules for rendering web pages and let users 
toggle between them? By default IE could chose to render in the safest 
mode possible but the advanced user could set it to by default render in 
the strictest possible mode. And if a web page is found that doesn't 
render correctly the user is but a keystroke away from toggling to a 
mode that would render it well. And when they change to a different mode 
the browser could remember it for that URL, for that URL path, and/or 
that domain (the user could select this too.)

Yes, most people would never opt for the explicit mode, but some people 
would and combine with the embedded validator within the browser I think 
we'd quickly see a large number of the "broken" pages fixed.

And Chris, yes this is radical but realize that most people get pissed 
because Microsoft gives them no control. This puts the control in users 
hands and, if blessed by the W3C, is a lot less likely to see people 
pissed at Microsoft.  And I think this would see everybody winning.

Again, please really think about this before shooting it down (as a 
similar proposal of mine was shot down in the WHATWG, which is why I'm 
bracing for being target practice.)

-Mike Schinkel
http://atlanta-web.org - http://t.oolicio.us
"It never ceases to amaze how many people will proactively debate away 
attempts to improve the web..."
Received on Saturday, 14 April 2007 10:04:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:33:05 UTC