Re: Overall strategy

On Tue, 10 Apr 2007, Henrik Dvergsdal wrote:
> 
> 2. We add all that's necessary to define "exactly how to handle the web 
> as it is today" (Hunt). This means all components that are being used in 
> current web pages, including, for instance, elements like <blink>, 
> <blackface> and <marquee> and all the "undocumented, unspecified, frozen 
> set of bugs" (Hickson) that people rely on out there.

The "undocumented, unspecified, frozen set of bugs" to which I referred 
was the hypothetical set of bugs that a versioned browser with no further 
updates would introduce; I didn't mean to imply anything about my 
preferred development model for the specification. (Incidentally, feel 
free to call me "Ian" or "Hixie". Also, it's considerd good practice in 
W3C mailing lists to cite the actual e-mail in question using an e-mail 
to the archives, so that others can read quotes in context.)

My personal preference, and also the model that the WHATWG has been using, 
is to balance compatibility with existing content, good logical consistent 
design, the needs of authors, and the needs of all the various 
implementors when creating the specification. It's not a matter of trying 
to specify exactly what one particular browser does, nor is it a matter of 
ignoring the legacy content, nor is it a matter of considering author 
needs paramount, or any other extreme. It's a matter of careful design, 
research, and judgemental calls, all based on the design principles which 
Maciej and others have written up in the wiki:

   http://esw.w3.org/topic/HTML/ProposedDesignPrinciples

Some features do not need to be implemented by browser vendors, like 
<blackface>, and could and should be forgotten and not mentioned in the 
specification. Others, like <marquee> or <font>, need to be specified 
since they are required to browse the Web and interoperability is desired 
for those features, but they do not need to be allowed (i.e. while 
browsers have to support them, authors musn't use them).


> 4. We then freeze the standard and let evolve in two ways only: (1) by 
> bug fixing and (2) by incorporating new components once they are 
> actually being used - "we cannot afford to change behavior, nor can we 
> afford to remove features from browsers once they are used" (Hickson).

By "change behaviour" in the above quote I refer to changes from currently 
implemented behaviour for features that are widely used. As an extreme 
example, we couldn't make <tr> tags in HTML into comment syntax -- <tr> 
has to introduce a table row.

I see no reason to freeze the specification, nor do I think that we should 
rely exclusively on implementations to create new features (though 
naturally implementation feedback is critical to the specification design 
process). I do not believe I have ever proposed such a radical design 
methodology; the text quoted above doesn't mean to imply this.


> This means that if, for instance, Microsoft implements some new element 
> in IE and people start using it, it will automatically be included in 
> the standard and all the others will have to follow.

There should not be any "automatically" about it, certainly. However, if a 
feature implemented by a browser becomes widely used, it is in our 
interests to study it and consider whether we should specify it (thus 
encouraging interoperability when others browser implement it as well).

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 10 April 2007 11:16:19 UTC