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

Re: Versioning and html[5]

From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
Date: Sat, 14 Apr 2007 13:59:54 +1000
Message-ID: <462051BA.4090709@lachy.id.au>
To: Chris Wilson <Chris.Wilson@microsoft.com>
CC: "public-html@w3.org" <public-html@w3.org>

Chris Wilson wrote:
> Content developers will never be happy if anything breaks,  and they
> will blame us.  We CAN make our browsers interoperable in the future. 
> If you want other browsers to be interoperable with today's content, 
> there is nothing else for it than for them to go implement all IE's 
> bugs and foibles as currently released.

While it may have been true that all sites only depended on IE's 
behaviour 7 years ago, there are an increasing number of sites that are 
built with standards compliance in mind.  I can guarantee you that if 
Mozilla, Opera and Safari change some of their more standards compliant 
behaviour to match IE (particularly with CSS and DOM), many sites would 
also break.   IE is not the only browser that sites depend on today, and 
cannot be the only browser that doesn't make any changes.

In the interest of interoperability for the web today (assuming you have 
any interest in that, though, despite your claims to the contrary, you 
clearly don't), there has to be compromises made somewhere, in *ALL* 
browsers!  IE's monopoly does not grant you an exemption from playing by 
the rules.

If we are to make any progress at all, we have to try and break as 
little as physically possible.  But it is absolutely unrealistic, 
anti-competitive, anti-web-standards and insane to think that any effort 
to standardise the mess we find ourselves in today can result in 100% 
pixel-perfect rendering and behaviour for 100% of all web sites in 
existence today.  We should not be striving for the impossible!  But, 
while being *realistic*, we absolutely can and *must* do the best we can 
to work together and minimise the damage as much as physically possible.

e.g. look at <button>, for instance.  In IE, it defaults to type=button, 
in other browsers it defaults to type=submit.  Maciej already pointed 
out that there are some sites that depend on it defaulting to submit, 
but you claim there are many that depend on it defaulting to button.

Obviously, for interoperability, browsers can't retain their differing 
behaviour, so it has to be defined one way or the other.  Sites that 
depend on the behaviour that isn't chosen will break, and there's 
nothing that can be done about it.  But by working together and doing 
research on what sites depend on the most, we can avoid breaking the 
majority.  In this case, it may turn out that IE's behaviour is depended 
on more, and so IE's behaviour could be chosen.

But in the case of, say, IE's broken DOM, I seriously doubt that there 
are any sites that absolutely depend on the non-tree structure of IE's 
DOM in certain cases.  I strongly believe that IE could implement the 
adoption agency parsing algorithm in the HTML5 spec and produce a proper 
DOM tree without significantly breaking anything.  (If there are 
problems with the algorithm, they can be fixed in the spec based on 
implementation experience).

The fact that other browsers are compatible with the web without having 
a broken DOM proves beyond all *reasonable doubt* that sites don't 
widely rely on a broken DOM.  If you have evidence to prove otherwise, 
please present it.  But making bogus claims based on market share and 
other fallacious arguments are not welcome.

Setting ultimatums about not making any changes whatsoever will not get 
us anywhere and if that's the case, we may as well all pack up and go 
home now!  I, and I'm sure many others too, have absolutely no interest 
in writing a spec that only defines how to handle future content, 
leaving today's content to rot.  If that's what you want, you're welcome 
to join the XHTML2 WG.  But in this group, we have real work to do.

-- 
Lachlan Hunt
http://lachy.id.au/
Received on Saturday, 14 April 2007 04:00:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:15:53 GMT