Re: xdash name prefixes (was Re: Component Model Update)

On Wed, Aug 24, 2011 at 5:18 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Wed, Aug 24, 2011 at 5:12 PM, Adam Barth <w3c@adambarth.com> wrote:
>> 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...
>
> Yes, the data-* attributes are the correct thing to draw parallels to here.
>
>
>> 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...
>
> These are fine as well; the important case where prefixing causes
> problems is when one of the parties is the browser itself, where it
> will eventually want to change from recognizing the prefixed name to
> recognizing the unprefixed name.

That's a pretty narrow view.  :)

Adam

Received on Friday, 26 August 2011 02:39:02 UTC