Re: Possible Compromise solution for namespaces in HTML5

On Fri, Nov 20, 2009 at 10:19 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 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>.
>

Though you responded to Robert, not me, I hope you won't mind me jumping in.

Isn't the whole purpose behind the use of namespaces such that one can
have the same element name within multiple namespaces, without
conflict?

If somehow an element magically works its way into being part of the
default HTML namespace, which is what you seem to be suggesting, other
uses of the element from other namespaces still won't be impacted. Or
I could be missing something in Robert's proposal: is there something
specific in it that makes this situation worse?

I looked back at Robert's proposal, and can't see how what you're
describing would be a problem in his proposal or with traditional
namespaces.

As for somehow the namespaced elemen
> 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.
>

The same can be said about new elements within the existing HTML5
namespace. After all, we have to use JavaScript to get IE6/IE7 to
recognize article and section and apply CSS, and this without the use
of namespaces.

> 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.
>

First, Maciej's suggestion is not compatible with the use of
namespaces in the XHTML version of HTML5. Second, the two, elements
and attributes, are not interchangeable. If they were, why don't we
have <div article> or <div newstyle="article">? Or even <div
class="article">? In fact, we generally  have <div id="article"> right
now, and it seems to work in all browsers: we could probably cut out
several new HTML5 elements, if we consider attributes and elements are
the same thing.

As for the validation issue, frankly, other than issues with
differences in the the DOM, we can use namespaced elements right now
in HTML5, if we weren't concerned about validating.

> 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.
>

This author disagrees with you.

> ~TJ
>
>

Shelley

Received on Saturday, 21 November 2009 14:12:16 UTC