W3C home > Mailing lists > Public > public-html@w3.org > March 2010

Re: TWO Change proposals for ISSUE-41 : Distributed Extensibility

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 17 Mar 2010 19:03:17 -0700
Message-ID: <63df84f1003171903p6416a969we4c1281743ca52a3@mail.gmail.com>
To: "Ennals, Robert" <robert.ennals@intel.com>
Cc: Tony Ross <tross@microsoft.com>, HTMLwg <public-html@w3.org>
>> 3) The term "vendor-specific" is used frequently in the proposal
>> details, but is a bit narrow in scope. Specifically, I want to avoid
>> implying that script libraries are excluded from defining such
>> extensions.
>
> Good point. I borrowed that phrase from the current spec, but I don't think there is any need for it to be so narrow. I see no reason why this approach should not also support specs (like e.g. SVG or RDFa) that are not specific to one vendor, but are still not part of the base HTML spec.

I would really discourage other specs, like SVG or RDFa, from using
this mechanism. With HTTP headers we see time and again that "x-"
prefixed header names become defacto standards (the last one I saw was
"x-frame-options").

If SVG for example had used <svg-circle> elements as a way to extend
HTML sites would likely pick that up fairly quickly and we'd be forced
to support that as an official name forever. This would result in
having two elements with the same meaning, <circle> in the SVG
namespace, and <svg-circle> in the HTML namespace. This is both
confusing and a pain for authors as things like getElementsByTagNameNS
would no longer allow you to get all svg circles.

Specifications already have an extension point, I don't see that this
proposal help them in any way beyond that. And only risks creating
pains for all involved parties.

/ Jonas
Received on Thursday, 18 March 2010 02:04:12 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:59 UTC