W3C home > Mailing lists > Public > public-html@w3.org > August 2008

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

From: James Graham <jg307@cam.ac.uk>
Date: Fri, 01 Aug 2008 16:54:39 +0100
Message-ID: <489331BF.3070509@cam.ac.uk>
To: Sam Ruby <rubys@us.ibm.com>
CC: Ian Hickson <ian@hixie.ch>, 'HTML WG' <public-html@w3.org>

Sam Ruby wrote:
>> community. We're _still_ dealing with the problems Apple caused with
>> <canvas>, for example the lack of a Path object, which we could have
>> avoided if they had had wider peer review before shipping.
> 
> This is a glass is half-empty point of view, perhaps?
> 
> Would HTML5 have canvas at all if Apple hadn't created it?
> 

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

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.

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

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

-- 
"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 15:55:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:21 GMT