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

James Graham wrote:
>> Wait a second. Opera, Mozilla and Apple are including HTML5 features 
>> right now, without them being "through" the standards process. What 
>> happens if future Working Drafts of HTML5 change things in an 
>> incompatible way?
> 
> Generally the things that they are including have been in the spec for a 
> while and so have undergone significant review. Getting actual shipping

That may be the case for some, but not for all. In particular I'm 
concerned by the fact that the story I hear is "nothing is cast in stone 
until the *HTML WG* has accepted it", but in practice, we will be 
constricted by what early adopters are shipping.

> implementations does make it much harder to then change those sections 
> of the spec, but it also leads to issues being caught that do not come 
> up in theoretical discussions alone. It also gets features into the 

I totally agree that trial implementations are good. But it should be 
understood that features can change, so relying on them may not be a 
good idea.

Of course it would help if we had a modular spec, so that things like 
<audio> and <video> could ship independently of things like local SQL 
storage.

> hands of users which is, after all, the only point of developing them in 
> the first place. In short there is a trade off between shipping with too 
> little peer review and never shipping at all. I think we're treading 
> that line about right at the moment.

I'm not convinced.

>> Correct. Letting everybody play within their namespaced sandbox is one 
>> way to do that.
> 
> Not really. Let's say Opera had shipped <opera:video> and content had 
> started using it. Then the standards process comes along and defines an 
> incompatible <video>. Now there are several possibilities none of which 
> are very nice:
> 
> * Other vendors implement <opera:video> instead of <video> in order to 
> be compatible with existing content

That's not really a problem.

> * Opera decides to drop <opera:video> and so breaks existing content

Whether that is a problem depends on the amount of content, and how 
Opera would have "sold" that feature in the first place.

> * Opera decides to ship both <opera:video> and <video> (something that 
> implementors have been historically unhappy about, but forced to do e.g. 
> I believe Apple still have a slightly different implementation of 
> <canvas> depending on whether you are a widget or web content). This 
> increases the surface for bugs, etc.

It does, but it also makes it *possible* to do the right thing the 
second time.

Example: MS still suffers from having once shipped with "WD-xsl" support 
in IE 5.5. But things would be *worse* if XSLT 1.0 would have been in 
the same XML namespace, making it impossible to distinguish the two 
dialects.

> * Opera don't implement <video> but decide to just keep shipping 
> <opera:video>

That is very unlikely if the new specification is better, and other 
vendors support *that*.

> The essential problem is that as soon as there is legacy content for a 
> feature it becomes rather difficult to drop it because it breaks sites. 

Putting things into a separate namespace at least makes it *possible* 
not to drop it.

> It also creates a pressure for other vendors to implement the namespaced 
> version of the feature (to be compatible with existing sites) and so 
> tends to lead to fragmentation of who supports what, which isn't in 
> anyone's best interests.

That can happen, but I think it's superior to not having the choice.

>> Authors use whatever works. And authors want to add metadata. Instead 
>> of forcing it into containers that haven't been designed for it 
>> (@title, @data-*), let them do it properly.
> 
> For the specific case of data-* one could allow for the kind of 
> sandboxes that you like by doing something like data--prefix-value and 
> maintaining a registry of prefixes. That would at least be less awful 
> than URI-based namespaces and allow e.g. microformats to unambiguously 
> rope off a section of data-* space for themselves.

A hack on top of a hack, instead of adopting allowing a vocabulary that 
has been built for that very purpose (RDFa comes to mind, and BTW, that 
use case *is* in our charter).

BR, Julian

Received on Friday, 1 August 2008 17:25:07 UTC