- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 17 Mar 2010 19:03:17 -0700
- 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