- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 24 Aug 2011 17:18:46 -0700
- To: Adam Barth <w3c@adambarth.com>
- Cc: Dominic Cooney <dominicc@google.com>, 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 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. ~TJ
Received on Thursday, 25 August 2011 00:19:36 UTC