- From: Adam Barth <w3c@adambarth.com>
- Date: Thu, 25 Aug 2011 19:38:01 -0700
- To: "Tab Atkins Jr." <jackalmage@gmail.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: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