Re: Overall strategy (Was Re: Proposal to Adopt HTML5)

On Apr 10, 2007, at 3:17 AM, Henrik Dvergsdal wrote:

>
> On 10. apr. 2007, at 11.36, Maciej Stachowiak wrote:
>> I could give my personal opinion on these points if you are  
>> curious but I don't think it is relevant to the question of  
>> adopting HTML5. And I certainly would not be speaking for everyone  
>> who signed the letter.
>
> On 10. apr. 2007, at 11.39, Dao Gottwald wrote:
>> I don't follow your reasoning. Using HTML5 as a /starting point/  
>> doesn't mean that any resolution of the WHATWG is set in stone.
>
> OK. I get your point, but there seems to be a common vision here  
> and I think it will be useful to get a sense the whole picture. It  
> would at least help putting the decision into perspective.
>
> So  what is your *personal* opinion on this then? Do you think this  
> seems like a good strategy:

I don't think anyone is proposing exactly this strategy except you.  
Maybe you should get opinions from the people you quoted, to see if  
you accurately presented their point of view. I don't think you did.

But since you asked, here are my personal opinions, speaking only for  
myself.

> 1. We start with HTML5 in its current state.

Obviously, I agree.

> 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.

Not exactly. The elements that would have to be specified are ones  
that current web content depends on to a significant degree.

To address the ones you mentioned: <marquee> would have to be  
included, it is supported at least by IE, Mozilla and Safari and is  
apparently used extensively on various Asian-language sites. <blink>  
is not supported by IE and there doesn't seem to be significant  
content depending on it - supporting it with actual blinking would be  
more likely to break content. <blackface> is a proprietary tag only  
supported by MSNTV in their variant of XHTML for walled garden  
content. It is not relevant to the web.

Given these examples, I assume this was meant to be some kind of  
reductio ad absurdum. But I think we can distinguish unappealing but  
needed features, like <marquee>, from unneeded (and possibly  
counterproductive) ones like <blink> or <blackface>.

I think there is considerable flexibility on what exactly to include,  
for such implementation-only elements.

> 3. We organize the standard into sets of "recommended", "right"   
> components, and sets of forbidden, "wrong" components:
>
> This "effectively means that we discourage people from using the  
> elements (it's forbidden, the elements don't event exist as far as  
> authors are concerned), but "require" user agents to support them  
> so they don't lose market share, render the web and such" (van  
> Kesteren, offlist).

Using terms like "right" and "wrong" makes this needlessly  
moralistic. I would instead say that there is one set of elements and  
attributes that are allowed in conforming documents, and strict  
superset of this that must be supported by conforming user agents.  
One could take this as an application of the IETF principle of "be  
lenient in what you accept and strict in what you send". It's not a  
moral issue, just a case of features that are needed for  
compatibility but that would not be recommended as good practices for  
new content. Again, by using such a moralizing tone, I assume you  
meant to make this proposition sound foolish.

> 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).

I don't agree with this. Changes should include:

- Correcting errors
- Adjusting to match what is interoperably implemented, even that  
contradicts what past spec versions said
- Adding new elements/attributes/APIs in a compatible way
- Possibly moving things from being conforming for documents to just  
being things that implementations must support, if there is a good  
reason to remove them from conformance

I don't think new features would have to actually be used before they  
can get in the spec, but obviously things that are used would be  
candidates. There is also the W3C requirement of two interoperable  
implementations to become a full REC, so in that sense, any spec  
feature would have to at least be implemented before it is final.

> 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.

If indeed lots of people use it, then other browsers will have to  
follow anyway, so better to have a spec than require us to reverse  
engineer IE and each other.

Anyway, if your proposal was meant to be an exercise in sarcasm, I  
hope you will make your point more directly.

Regards,
Maciej

Received on Tuesday, 10 April 2007 10:53:37 UTC