Re: Possible Compromise solution for namespaces in HTML5

On Sat, Nov 21, 2009 at 9:18 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 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).
>

You're talking about issues to do with extensibility in general, not
Robert's specific solution. And I'm not sure that this is a risk.

Do you have specific instances where this has occurred that you can
provide so we can look at how this has happened in the past?

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

Point taken, but to the web page author, to all intents and purposes,
people perceive that IE ignores the elements. There is no fallback, we
have to do something in the web page to make them work.

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

I think you're using an unlikely scenario. A typical namespaced
element in the future would probably be something like the creative
commons license, or Inkscape's elements within SVG: they won't require
anything from specific user agents.

To me, extensibility doesn't mean that all user agents will be equally
interested in the extended elements. But that there is a means to
record the extended elements in a web page, without causing other
elements to break, and to be available for those user agents that are
interested.

If, for some reason, Mozilla, Opera, Apple, Google, and IE decide to
implement their own creative commons element, named cc, or some such
thing, then I don't think we'll see a proliferation of apple-cc:
moz-cc: and so on.

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

But I'm looking at what will work in HTML5 AND work in the web at
large, which is why I return to namespaces. But, OK, we'll leave
namespaces out for now.

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

The point I was making is that attributes do not always provide the
same capability. If they did, we wouldn't supposedly need article or
section, we could just create an article attribute or a section
attribute and attach to a div element.

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

Sure, and that's a valid suggestion for figure. But I think we may be
straying a bit far from Robert's proposal.

Have you thought about submitting a formal proposal for the
figure/details issue, detailing using attributes rather than separate
elements?

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

Ah, OK. Makes sense.

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

I accepted the corrections, but no, I don't agree with the basic premise.

> ~TJ
>

Shelley

Received on Saturday, 21 November 2009 16:13:18 UTC