W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

xdash name prefixes (was Re: Component Model Update)

From: Adam Barth <w3c@adambarth.com>
Date: Wed, 24 Aug 2011 17:12:13 -0700
Message-ID: <CAJE5ia9CRpD_9Vgtk-2=4M1GTOW+26eVB5Bxw+C2ERzT0EM_PQ@mail.gmail.com>
To: Dominic Cooney <dominicc@google.com>
Cc: Dimitri Glazkov <dglazkov@chromium.org>, public-webapps <public-webapps@w3.org>, Maciej Stachowiak <mjs@apple.com>, Jonas Sicking <jonas@sicking.cc>, Boris Zbarsky <bzbarsky@mit.edu>
On Wed, Aug 24, 2011 at 2:30 PM, Dominic Cooney <dominicc@google.com> wrote:
> On Thu, Aug 25, 2011 at 2:03 AM, Dimitri Glazkov <dglazkov@chromium.org> wrote:
>> On Tue, Aug 23, 2011 at 9:19 PM, Adam Barth <w3c@adambarth.com> wrote:
>>> This section <http://wiki.whatwg.org/wiki/Component_Model#Performance>
>>> says "When an unknown DOM element with an "x-"-prefixed tagName is
>>> encountered ...". †It seems unfortunate to special-case tag names that
>>> begin with "x-". †The IETF has a lot of experience with "x-" prefixes,
>>> and they're somewhat unhappy with them:
>>>
>>> http://tools.ietf.org/html/draft-saintandre-xdash
>>
>> I can't seem to draw a parallel between prefixing author-defined
>> custom DOM elements and prefixing HTTP parameters -- other than the
>> prefix itself, that is. There's a clear meaning of the prefix in the
>> Component Model -- this element was defined by an author.
>> Additionally, we are explicitly trying to avoid a registry-like
>> situation, where one has to announce or qualify for the right to use a
>> tag name. Can you help me understand what your concerns are?
>
> That RFC is interesting, but I didnít find it a perfect parallel either.
>
> In protocol headers, clients and servers need to agree on the meaning
> of headers, and require migration from non-standard to standard
> headers with attendant interoperability issues. Components are
> different, because both the x-name and its definition are under
> control of the author. The intent is that if HTML standardizes an
> x-name, it will be christened with the un-prefixed name; the UA can
> continue supporting old x-names and definitions using the generic
> component mechanism.
>
> I guess we could get into interoperability difficulties if user agents
> start to rely on specific x-names and ignoring or augment their
> definitions. For example, if a crawler ignores the scripts that define
> components but interpret a common x-name a particular way. Or if a
> browser automatically augments the definition of a given x-name for
> better security or accessibility.

Yeah, the parallel breaks down a bit because in HTTP the "X-" names
are used by two parties and here we're only talking about one party.
Maybe a better parallel is data attributes, which are also segmented
into their own namespace...

On the other hand, it seems likely that some of these xdash names will
come into multi-party use.  For example, the following use cases
involve xdash names chosen by one party and then used by another:

http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Widget_Mix-and-Match
http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Contacts_Widget
http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Like.2F.2B1_Button

That's something like 40% of the use cases...

I don't have much of a better suggestion.  You're running up against
all the usual distributed extensibility issues.

Adam
Received on Thursday, 25 August 2011 00:13:25 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:47 GMT