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

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?

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

> By contrast consider the <video> element. Opera released a paper and an 
> experimental implementation. Instead of just shipping their experimental 
> implementation they brought the idea to the WHATWG where the feature has 
> undergone considerable change reflecting the additional uses cases 
> brought forward, as well as the broad range of expertise available. As a 
> result the <video> element will be considerably better designed and more 
> useful.

Again: the spec is not finished, but browsers are shipping with support. 
It may be better to ship something that is in a W3C Working Draft (as 
compared to what Apple did with canvas), but it is still risky.

How to prevent things like that? Ensure that people *can't* damage the 
process by shipping early by using URI based naming, and assign the 
final namespace only when the spec ships. See the Atom feed format.

> By it's nature distributed extensibility of core platform features only 
> lends itself to innovations taking the path of no review because people 
> planning to get community feedback before they ship may as well forgo 
> the extensibility mechanism in favour of putting their features into the 
> core language. Indeed, as Henri has pointed out, distributed 
> extensibility (at least of the namespaces-in-XML kind) can lead to the 
> problems associated with vendor-extensions becoming worse as the name of 
> the vendor becomes attached to the extension, causing political 
> difficulties for other vendors looking to adopt the feature (e.g. how 
> likely would Apple be to implement <video> if it had to be written 
> <opera:video> or even <video xmlns="http://opera.com/ns/video">?).

Unlikely. So Apple and Opera would have had motivation to standardize 
the feature somewhere else, such as in the WhatWG or W3C.

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

Best regards, Julian

Received on Friday, 1 August 2008 16:07:36 UTC