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

Re: Proposed Design Principles review

From: Maciej Stachowiak <mjs@apple.com>
Date: Thu, 26 Apr 2007 23:30:50 -0700
Message-Id: <1C25DC47-5640-4312-9EA3-21CE056D8F32@apple.com>
Cc: Doug Schepers <doug.schepers@vectoreal.com>, public-html@w3.org
To: "Preston L. Bannister" <preston@bannister.us>

On Apr 26, 2007, at 10:35 PM, Preston L. Bannister wrote:

> On 4/26/07, Maciej Stachowiak <mjs@apple.com> wrote:
> For these reasons, HTML5 has to handle the vast majority of legacy
> content, or at the very least be compatible with doing so. These
> three issues vastly outweigh the benefits of simplifying the
> language. I agree with you that a simpler, cleaner language would be
> more elegant. But, unfortunately, it would be far less useful.
>
> You are in effect asking browser vendors and maintainers of existing
> content to pay a large development cost for the aesthetic benefits of
> a simpler, more elegant spec. And I don't think that is a reasonable
> request. We're talking potentially billions of dollars in development
> costs across the industry.
>
> I can certainly understand (and agree with) the desire to avoid  
> over-complicating the browser implementations - though I rather  
> doubt costs adds up to billions.

The billions would be counting the cost of recoding existing content  
to be able to use new features.

> At the same time, the programming model on the client side for web  
> applications is an incredible mess - and the cost this incurs over  
> time may well add into the billions.

That's true, but I think the majority of the complexity is due to  
divergence between implementations, not the basic model itself. I  
also think that the most troublesome areas are CSS and DOM, not HTML.

> Can we clean up the programming model while maintaining versionless  
> backwards compatibility?   Seems rather unlikely.  This leads us to  
> a fork - well described IE-behaviors so other browsers can become  
> more compatible.  A better described, more coherent (hopefully),  
> and more carefully compliance-checked version of HTML for use in  
> the future.  Merging the two forks ... seems unlikely to work.

I'm not sure that's true. HTML5 is a lot stricter about what is  
conforming for documents than about what must be accepted by user  
agents. So simply using a conformance checker automatically puts you  
in a simpler model embedded in the full system that can handle legacy  
content.

> On an almost-irrelevant note - the "Microsoft is evil" meme has  
> shown a few times on this list, but in fact there is a bit of  
> "evil" in the non-IE browsers chasing IE-behaviors.

I think putting things in moralistic terms is unhelpful to the  
discussion. That being said, no, I don't see how trying to make more  
web content work right for your users can be called evil, especially  
when it goes along with improving interoperability with other  
browsers. We do our best to stick to standards, but being 100%  
sticklers for the current standards as written would result in a  
browser that can't browse the real web and will rapidly have no  
users. There is no glory in being a market share martyr.

> Imagine a super-advocate who convinced his organization to adopt a  
> non-IE browser - say Opera since they have been in use longer than  
> Safari or Firefox.  Likely some of their in-house applications were  
> adapted to work with Opera.  The applications work, the  
> organization is happy, and the programmers are gone (not unusual).
>
> Now a new version of Opera comes out.  Many web applications that  
> worked in IE now work (or work better) in the new Opera.  But  
> behavior is changed ... and at least one of the organization's in- 
> house web applications is broken in Opera.  Now the super-advocate  
> is in a tough spot.  Fixing their application(s) could be expensive  
> and risky.

The developers of non-IE browsers generally do not recommend  
developing against a single browser. We recommend developing against  
standards and testing in multiple browsers. On the Safari team, even  
for content that is only ever expected to run in custom WebKit apps  
like Dashboard, we recommend to developers that they test in multiple  
browser engines. We want them to reduce the risk of inadvertently  
depending on WebKit bugs or quirks. It's true, there might be those  
rare super-advocates who don't listen, but we think most advocates of  
non-IE browsers recognize the benefits of a healthy and competitive  
browser market.

> Are there many of these super-advocates?  Probably not.  Is there  
> at least one?  Probably.  What you will have done to that guy is  
> indeed "evil".  For that guy the safest choice may be to dump  
> Opera, and adopt IE.
>
> So ... a little bit of evil versus a big benefit to the majority of  
> customers.  Not exactly a "nice" choice.

It may be an ugly choice, but it's also an easy and indeed inevitable  
one. The browsers that work better for more users are the ones that  
will survive, in the long run.

Regards,
Maciej
Received on Friday, 27 April 2007 06:31:11 UTC

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