Re: xdash name prefixes (was Re: Component Model Update)
On Fri, Aug 26, 2011 at 11:18 AM, Adam Barth w...@adambarth.com wrote: Doesn't it seem more likely that the third-party will do the registration in whatever script you include that implements the Like button, or whatever? That's just a matter of convention, no? I don't think it's unreasonable to frame it as in order to use a component you need to load its source and register a suitable element name for it.. OTOH, there's nothing to prevent a package from doing the registering in one go. But if such a package then really leads to a clash, I'd prefer to first ask the authors to sort it out. Cheers, - Roland
Re: xdash name prefixes (was Re: Component Model Update)
I think for convenience registration probably should be carried around with the component, because: 1. It is convenient for the author using the component. 2. If the component library reuses its own abstractions, it probably expects them to have a specific element name. Putting registration in the hands of the author using the component jeopardizes that. However I don’t think the imperative API is right, or at least not enough, for these reasons: (assuming you accept that registration happens in the component library—the death before inconvenience premise): 1. The imperative registration API is *not* OK for confined components, because if you run script out of the library in your context to do the registration, you are hosed. 2. There’s no way for the author to manage conflicts or namespace pollution. Something declarative like module imports and exports, with scoped renaming, for registered tag names would be nice. This avoids these two problems, and is pretty convenient (particularly if import * gets you all of the exports by default.) Dominic On Wed, Aug 31, 2011 at 10:54 AM, Roland Steiner rolandstei...@google.com wrote: On Fri, Aug 26, 2011 at 11:18 AM, Adam Barth w...@adambarth.com wrote: Doesn't it seem more likely that the third-party will do the registration in whatever script you include that implements the Like button, or whatever? That's just a matter of convention, no? I don't think it's unreasonable to frame it as in order to use a component you need to load its source and register a suitable element name for it.. OTOH, there's nothing to prevent a package from doing the registering in one go. But if such a package then really leads to a clash, I'd prefer to first ask the authors to sort it out. Cheers, - Roland
Re: xdash name prefixes (was Re: Component Model Update)
On Wed, Aug 31, 2011 at 12:57 PM, Dominic Cooney domin...@chromium.orgwrote: I think for convenience registration probably should be carried around with the component, because: 1. It is convenient for the author using the component. 2. If the component library reuses its own abstractions, it probably expects them to have a specific element name. Putting registration in the hands of the author using the component jeopardizes that. That is actually a good point. Something declarative like module imports and exports, with scoped renaming, for registered tag names would be nice. This avoids these two problems, and is pretty convenient (particularly if import * gets you all of the exports by default.) Wouldn't that be effectively namespaces by another name/mechanism? Also, there's probably a limit to how far renaming can avoid clashes, e.g., if a sub-components can also be utilized by a page's author. In any case, until modules become a reality I think teaching component authors to use pseudo-namespaces (e.g., x-rogersoft-button vs. x-delilahsoft-button) for stuff that might clash is not unreasonable. Cheers, - Roland
Re: xdash name prefixes (was Re: Component Model Update)
On Thu, Aug 25, 2011 at 9:12 AM, Adam Barth w...@adambarth.com wrote: 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 Since the components that are used on a page are under the control of the page's author, it should be possible to avoid clashes by separating a component's definition (potentially pulled from third party) from its tag registration (done by page author), e.g. // Importing component definition for Facebook Like button // Importing component definition for Google+ +1 button // ... later: Element.register(x-fb, Facebook.LikeButton) Element.register(x-gg, GooglePlus.PlusOneButton) 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. We could use namespaces... *ducks and runs* :D Cheers, - Roland
Re: xdash name prefixes (was Re: Component Model Update)
On Fri, Aug 26, 2011 at 1:07 AM, Roland Steiner rolandstei...@google.com wrote: On Thu, Aug 25, 2011 at 9:12 AM, Adam Barth w...@adambarth.com wrote: 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 Since the components that are used on a page are under the control of the page's author, it should be possible to avoid clashes by separating a component's definition (potentially pulled from third party) from its tag registration (done by page author), e.g. // Importing component definition for Facebook Like button // Importing component definition for Google+ +1 button // ... later: Element.register(x-fb, Facebook.LikeButton) Element.register(x-gg, GooglePlus.PlusOneButton) Doesn't it seem more likely that the third-party will do the registration in whatever script you include that implements the Like button, or whatever? Adam 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. We could use namespaces... *ducks and runs* :D Cheers, - Roland
Re: xdash name prefixes (was Re: Component Model Update)
On Wed, Aug 24, 2011 at 5:18 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Aug 24, 2011 at 5:12 PM, Adam Barth w...@adambarth.com wrote: On Wed, Aug 24, 2011 at 2:30 PM, Dominic Cooney domin...@google.com wrote: On Thu, Aug 25, 2011 at 2:03 AM, Dimitri Glazkov dglaz...@chromium.org wrote: On Tue, Aug 23, 2011 at 9:19 PM, Adam Barth w...@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
xdash name prefixes (was Re: Component Model Update)
On Wed, Aug 24, 2011 at 2:30 PM, Dominic Cooney domin...@google.com wrote: On Thu, Aug 25, 2011 at 2:03 AM, Dimitri Glazkov dglaz...@chromium.org wrote: On Tue, Aug 23, 2011 at 9:19 PM, Adam Barth w...@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
Re: xdash name prefixes (was Re: Component Model Update)
On Wed, Aug 24, 2011 at 5:12 PM, Adam Barth w...@adambarth.com wrote: On Wed, Aug 24, 2011 at 2:30 PM, Dominic Cooney domin...@google.com wrote: On Thu, Aug 25, 2011 at 2:03 AM, Dimitri Glazkov dglaz...@chromium.org wrote: On Tue, Aug 23, 2011 at 9:19 PM, Adam Barth w...@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
