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

Hi Sam, Ian,

Ian wrote (emphasis mine):

>> Indeed, and <canvas>, another good example of why it is really bad
>> for people to go and invent their own elements *without working with
>> the wider 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*.

Sam replied:

> Would HTML5 have canvas at all if Apple hadn't created it?

Of course not. But that's not the point. The point is that we have a
functional extensibility mechanism for adding elements and attributes to
the language: bringing your proposals to this community. It's a social
mechanism for extensibility, not a syntactic one. Given the global
importance of HTML, I think it's a pretty reasonable arrangement.

Ian's point is that Apple didn't bring their canvas proposal to the
community before shipping, and things would have turned out better had
they done so. (To be fair to Apple, I'm fuzzy on the relevant
timeline--I'm unsure if the WHATWG existed prior to <canvas> shipping.)

>> IMHO that's too high a cost. Given the reactions of utter fear when
>> people even suggest that browser vendors might invent some new tag, I
>> believe that I am not the only one who thinks that it is too high a
>> cost.
>
> And, undoubtedly, I am not the only one who thinks that a closed
> vocabulary that does not plan for extensions is a too draconian
> solution.

HTML5 contains several points from which you can build extensions:
@class, <div>, <span> etc.

Yes, these extension mechanisms don't allow users to add their own
elements or attributes (excepting @data-*). I think this is entirely
reasonable given the importance of the vocabulary in question. If you
want to add a <foo> element, is using <div class="foo"> or <span
class="foo"> instead really that much of a pain in the ass? I don't
think it is.

> The one exception to this that I am aware of is microformats.

Microformats are a great example of a community coming together and
taking advantage of HTML's existing extensibility points.

> If one looks at microformats, one can see that there is a strong
> desire for decentralized extensibility, one that will not wait for
> this workgroup, and one that is greatly hobbled by the limitations I
> have cited.

On the contrary, microformats thrive within the constraints of HTML's
existing extensibility points. In the *one* case where things have been
very painful within those constraints--representing datetimes--the HTML5
effort has answered the need by providing the <time> element.


-- 
Edward O'Connor

Received on Friday, 1 August 2008 15:57:47 UTC