Re: Deciding in public (Was: SVGWG SVG-in-HTML proposal)

Julian Reschke wrote:
> James Graham wrote:
>> There is no problem with Apple (or whoever) creating an experimental 
>> implementation of a feature like <canvas>. The problem is if they 
>> bypass community review by shipping the feature before it is taken 
>> through a standards process. When that happens the vendor is often 
>> constrained to 
>  > ...
> 
> 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 
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 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.

> 
>> not change their legacy implementation and so any problems found (e.g. 
>> the lack of a path object on <canvas>) become immutable and add yet 
>> more rough edges in the web platform. Fortunately with <canvas> some 
>> of the most egregious problems, such as the lack of text-based 
>> fallback, could be fixed up afterwards. I would suggest not relying on 
>> this working in general, however.
> 
> 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

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

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

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

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

>> It is possible that distributed extensibility in the case where the 
>> extension has no impact on the browser — e.g. for adding metadata — is 
>> less bad. However some of the above problems still apply and, by and 
>> large, this use case can already be solved in HTML using e.g. 
>> classnames (I think we should allow the data-* attributes to be used 
>> for this purpose as well; IIRC it is explicitly forbidden at the 
>> moment but I'm sure authors will do it anyway).
> 
> 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.

-- 
"Eternity's a terrible thought. I mean, where's it all going to end?"
  -- Tom Stoppard, Rosencrantz and Guildenstern are Dead

Received on Friday, 1 August 2008 16:58:18 UTC