Re: Proposed Design Principles review

Hi Doug,

On Apr 26, 2007, at 9:00 PM, Doug Schepers wrote:

> I certainly can't speak for Microsoft, but from what Chris Wilson  
> has said, I'd expect that they would agree with this need not to  
> break even non-conforming pages (as do I).
>
> How we go about this is another matter.  I'm convinced that a  
> version attribute is the way to go, while others contend that the  
> language itself must incorporated (almost) all the features of past  
> implementations.

I think these are two separate issues. A version attribute doesn't  
necessarily give us license to drop features from past versions, nor  
is one necessary to do so. HTML5 already has a dinstinctive doctype  
that could be used to distinguish it from all past versions of HTML.  
But I don't think we really do want to do that.

> To me, the idea of a version that clearly identifies that the page  
> will be treated strictly according to the HTML5.0 standard, and  
> which will produce visible problems if not coded correctly, gives  
> us leeway to be less inclusive of past quirks.  If the language is  
> designed correctly (and I have no doubt this group could do so),  
> then the leaner syntax would still degrade gracefully in older  
> browsers.

I think there are a few problems with this:

1) For a new language to degrade gracefully in older browsers, it  
fundamentally has to include a lot of past quirks. You could remove  
past features entirely (or deprecated them, or remove them from  
conformance for documents but still require them for UAs, as the  
WHATWG draft does). But you couldn't change the behavior of existing  
features, which is often where a lot of the more annoying quirkiness  
lies.

2) Other than Internet Explorer, browser vendors generally do not  
want to have a multiplicity of modes. In Safari, for HTML alone, we  
already have quirks mode, standards mode, almost standards mode and  
XHTML. That's already four different modes. I really don't want to  
add two more modes for the HTML and XML serializations of HTML5.  
Every additional mode is extra cost in development, maintenance and  
testing. It is also increased security risk due to increased  
potential bug surface area.

3) We don't want the use of new HTML5 features to be blocked on  
making unrelated changes to your document to avoid deprecated  
features from older versions of HTML. An author shouldn't have to  
change their doctype string and fix all validation failures to play  
around with <canvas> or <video> or the client-side storage API.  
That's just asking too much. Authors will just go with proprietary  
solutions like Flash or Silverlight that don't require them to make  
unrelated changes to their markup. Or if they do use HTML5 features,  
they will pay significant development cost to make the other changes  
to their site to be able to do so.

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.

Regards,
Maciej

Received on Friday, 27 April 2007 04:35:07 UTC