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 Saturday, 21 November 2009 04:20:33 UTC