RE: Possible Compromise solution for namespaces in HTML5

Ah. That makes sense.

Several thoughts:

* If an extension is a vendor-specific experimental extension, then it should probably be using an "x-" extension rather than a registered prefix. Registered prefixes should be reserved for vendor-neutral standards that have been thought through a bit and are expected to stay around for a while. Rather than "moz:" and "ie:", I'd rather see "x-moz:" and "x-ie:". It should be syntactically clear to a user when they are using an experimental or vendor-specific extension.

* If an extension is provided by a registered extension, and the standard is good, then it's not clear that one needs to ever fold it into the HTML namespace. It may be best to just keep using it with the prefix. Why not keep svg with an "svg:" prefix?

* I like Maciej's suggestion, and think it should be possible to combine it with this model. For example, you could declare that any tool that supports a tag name with an "x-" prefix, must also support any tag that has an attribute with the same name. This would then allow things like <svg:wibble x-moz:wibble> (using the HTML5 boolean attribute shorthand). 


Thoughts?

-Rob


> -----Original Message-----
> From: Tab Atkins Jr. [mailto:jackalmage@gmail.com]
> Sent: Friday, November 20, 2009 8:20 PM
> To: Ennals, Robert
> Cc: public-html@w3.org; Carr, Wayne; Tran, Dzung D
> Subject: Re: Possible Compromise solution for namespaces in HTML5
> 
> On Fri, Nov 20, 2009 at 8:51 PM, Ennals, Robert
> <robert.ennals@intel.com> wrote:
> > Are you referring to the problem where random company X creates an
> extension which has a big flaw, that extension gets widely adopted, and
> then we are forced to accept a broken feature into the standard since
> we can't change it without breaking stuff?
> 
> Nope, I'm referring to the problem where Company X creates a
> namespaced extension, <foo:element>, and this then works its way up to
> becoming a standard <element>.  Authors are now stuck.  They can use
> <foo:element> and be compatible with existing browsers that support
> this but not the upcoming ones, they can use <element> and be
> compatible with upcoming browsers but not the current ones, or they
> can try to compromise somehow and hack together something that shows
> <foo:element> to some browsers and <element> to others.  This gets
> even worse if, somewhere between these two states, another browser
> decides to try out their own implementation and names it
> <bar:element>.
> 
> Element names are not extensible in a pretty way when you're dealing
> with the standardization process.  They don't have the appropriate
> kind of fallback.  We'd prefer something vaguely like CSS's fallback
> system, where you can provide multiple vendor-specific versions of a
> property, and they just get ignored by UAs that don't recognize them.
> 
> This is the reasoning behind Maciej's suggestion for doing
> element-level extensibility in attributes instead.  Instead of
> <foo:element>, you'd do <div -foo-element> or similar.  Then when the
> second browser puts out their experimental implementation, you can
> just change it to <div -foo-element -bar-element>.  When it gets
> standardized, switch it to <element -foo-element -bar-element>.  This
> gives you support for both legacy experimental implementation and
> current standardized implementations.  As an added bonus, it requires
> no changes to the current parsing rules, as unknown attributes are
> already dealt with in an appropriate way.  It just prevents you from
> validating, same as using vendor-specific additions in CSS.
> 
> Again, this is not a general critique on your proposal, just a
> rebuttal of one specific point.  Namespaces of any variety are not the
> answer for developing experimental implementations of new elements in
> a distributed fashion - it just doesn't play nice with the
> standardization process for us authors.  This does not affect their
> viability for solving other problems, of course.
> 
> ~TJ

Received on Monday, 23 November 2009 21:12:42 UTC