Re: Possible Compromise solution for namespaces in HTML5

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

No, I'm definitely not talking about extensibility in general.
Different types of extensibility have different requirements, and
Maciej's suggestion is completely unsuitable for most of them.  It's
meant to patch the failings in particular area to make extensibility
easier.

And I'm not commenting on Robert's specific solution.  I'm merely
disputing one particular claim Robert made which I believe is
incorrect.  This discussion has been a tangent from my first post.

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

In terms of multiple experimental versions of the same element,
providing with distinct names?  No, this has never happened.  When new
elements have been experimented with, browsers have just added them in
directly; this has caused trouble, as you know, which is why we're
trying to make this easier.

In terms of the general problem of multiple experimental
implementations of a feature given different names, I've already
provided an example.  CSS deals with this heavily, with a multitude of
properties implemented in prefixed form by multiple browsers at once.
CSS handles it properly, so that they play nicely with each other and
the eventual standardized (and prefixless) version.  The properties of
CSS that allow this should be obvious (though I can enumerate them if
necessary), and it should be equally obvious that element names do
*not* have analogous properties.

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

This still has nothing to do with the problem I'm citing - it's an
entirely different issue.

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

That's explicitly not the situations I'm talking about - I'm
addressing the issue of multiple experimental implementations of a
feature, leading to an eventual standardization of it.  This is a very
likely scenario, as it is used and useful in CSS; HTML currently
doesn't possess the correct characteristics to allow it to work
properly, however.

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

No, what's feared is a <ms:cc> element, plus a <moz:cc> element, plus
a <webkit:cc> element - all of them performing the same purpose and
wanting to be used at the same time on the same data.  There are many
bad ways to handle this - you could repeat the data multiple times,
once in each element, and come up with some way (probably js-based) of
hiding all but the correct element for each UA; you could hope that
the content model for the elements are set up such that you can nest
them and then just insert the data once, and hope that any problems
caused by this can be smoothed out by CSS and js; you can connive to
serve different pages to different UAs, each delivering a different
element in that area.  There are no good ways to handle it currently.
When the element gets standardized as <cc>, there's significant
pressure not to update - you have to either pursue one of the above
methods, or just write off legacy clients.

This is not a good situation for authors.

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

Of course, that would be silly.  Why would we use attributes when
element names suffice?  The only reason we're even *considering* using
attributes as a substitute for element names is because, in this
particular situation, element names do not suffice, as I explained
above.

~TJ

Received on Sunday, 22 November 2009 05:46:12 UTC