RE: Extensibility strategies, was: Deciding in public (Was: SVGWG SVG-in-HTML proposal)

On Sat, 2 Aug 2008, Justin James wrote:
> 
> I think that the history of HTML and browsers has made it abundantly 
> clear that browser vendors will extend the spec when it is in their best 
> interests, even if HTML does not provide these mechanisms. It is also 
> pretty clear from history that these extensions have a significant 
> chance of causing a lot of chaos.
> 
> Initially, I was quite against the idea of providing an extension 
> mechanism. But the more I considered this simple truth, the more I came 
> to understand that we are faced with two options here:
> 
> 1) Provide some sort of defined extensibility mechanism that is simple 
> enough for people to use, and flexible enough to actually be used.
> 
> 2) Continue to try to prevent browser vendors from extending HTML in 
> non-standard ways, and then retroactively add the best extensions into 
> the HTML spec, sometimes years later.
> 
> I think that choice #1 is the correct approach; if choice #2 were a good 
> path, why are we still having problems with browser vendors extending 
> HTML, 15 or so years later?

Are the problems caused by browser extensions caused by the syntax, or by 
the extensions themselves?

Would <marquee> have been ok it was really <ie:marquee>?
Would <blink> have been ok if it was really <nn:blink>?
Would <canvas> have been ok if it was really <wk:canvas>?

It seems to me that we would be in a _worse_ state right now if all these 
extensions had become widely spread while having extra syntax around them.

The problem, IMHO, is not that these extensions step into the vocabulary 
of HTML. <marquee> and <blink> haven't prevented us from creating new 
elements or anything like that. We could easily have called <canvas> 
something else in the standardisation stage, we didn't have to use 
<canvas>. The problems, as far as I can tell, were with the features 
themselves, regardless of their name. They didn't have enough peer review 
before being shipped.

The solution to a lack of peer review is peer review, not syntax.


> So let's figure out something better. I would suggest something much 
> more like CSS, but instead of providing presentational information, 
> provided handling and semantic information. It would also be able to 
> include the ARIA stuff too, for that matter.

What would you say the requirements of such a system were? What is the 
problem being solved?

Before solving this kind of problem, we need a very clear idea of what 
we're trying to solve, how to determine if we've solved the problem, and 
what the requirements are. Then we can look to see if we already have a 
solution, and if we don't, we can design one and evaluate it in terms of 
those requirements.

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

Received on Saturday, 2 August 2008 05:43:28 UTC