Re: Possible Compromise solution for namespaces in HTML5

On Sat, Nov 21, 2009 at 8:11 AM, Shelley Powers <shelley.just@gmail.com> wrote:
> 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?

Indeed!  That's not where the problem lies, though.  It's not an issue
about conflicts over a name, it's about conflicts over a *purpose*.
Part of experimental extensibility is that you'll have multiple
implementations hitting the same idea-space.  If you want to
accommodate all of them at once, like you can do today with
experimental CSS properties, just using namespaced elements doesn't do
the job, as I explained in the previous post.  At best you can hack
together a really ugly implementation-targetting solution to only
server the specific version of the element that the implementation
supports.  At worst it's impossible, and you're stuck with using only
a single version, shutting out other experimental implementations and
possibly the standardized one (and if you do switch to the
standardized one, legacy clients with only support for the
experimental one are not shut out, which makes it painful to upgrade).


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

Incorrect.  IE6 and IE7 *never* ignore new elements, they just respond
to them in an unacceptable manner (by treating the start and end tags
like separate void elements).  The js shims just trick them into
treating them in a saner manner.

That's still a separate issue, however.  There was never a
<ms:article> element, along with a <moz:article> and <opera:article>
and <webkit:article> all offering experimental support for these
elements.  If there was, it would be blatantly obvious what the
problems are.  Just imagine the contortions you'd have to go through
to use them all at once.

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

It has nothing to do with namespaces.  Namespaces may be a tool used
to ensure better disambiguation, but they are not a necessary aspect
of Maciej's suggestion.

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

Indeed, they are not.  Unfortunately, there's not a lot we can do
about that.  Element names do not have the type of fallback we need to
enable easy experimental implementations.  This is a plain fact.
Attributes do.  A few other things do as well, but attributes are the
closest to what we want.

There's nothing stopping us from making attributes affect the
semantics of an element.  In fact, we do so right now, with <time
pubdate>.  That is also my preferred solution to the <figure> issue -
I'd like to see a @caption attribute that can be added to any child of
<figure>.  There's even precedence for changing the API that an
element exposes based on attributes - that's exactly how <object>
works.  It's a little distasteful, but it doesn't stray into the
higher sin of making parsing depend on attributes.

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

Sure, I was just pointing it out, and explaining why the validation
issue shouldn't be a problem (because it's how CSS currently works,
and people find that generally acceptable).

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

I disagree.  ^_^  You disagreed with an incorrect interpretation of my
words.  Hopefully I've been able to express myself more clearly.

~TJ

Received on Saturday, 21 November 2009 15:19:10 UTC