This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Currently, my understanding is that you would have to add a script tag, effectively to the head of your document containing the registration of the custom components and then use them throughout with something like <div is="blah">. This is less than ideal from a user's perspective as we'd like to be able to take things like, say, a FaceBook "Like" component or a Google "+1" button and just use it - sometimes in big enterprises, for example, the head comes from some larger system which is out of your control and pieces of the page are cobbled together. Further, when I see is="blah" I am at a loss to know where the related component script comes from... Can we draw a page from things like <embed> and provide a simple means to tie the relationship together and "prime the pump" just once for a particular uri? We have an open source project called hitchjs which lets you do all of this via a url pattern, something like: <div data-hitch-widget="http://www.hitchjs.com/use/bkardell.social#fb-like"><div> But you could easily break that down into something like <div is="fb-like" package="http://www.hitchjs.com/use/bkardell.social"><div> I understand that this may cause new security concerns with injection and needs a lot more thought, but perhaps there is some inspiration that you could draw in terms of adding some sort of whitelist trust declaration to the header or something where you could say "I trust the stuff from xyz domain" or something... In the very least, you could restrict them to standard SOP and that would let you use them in your own site a little clearer.
+1 Firstly, I believe the success of the <iframe> is largely due to its simplicity--just set src to a URL and done--the component loads. Doing this declaratively also lends to its ease-of-use. What we have going with web components is not an iframe of course, but by now we have a well-understood notion of what the pieces are: a shadow dom, a custom element and its binding, and imports. These are great imperative mechanisms. I think we are ready for the next step--the declarative part, and that this will start to tie it all together and bring web components forward independently of script libraries. I'm decidedly in favor of stronger component isolation. There is much more that can be secured and guaranteed if the component and its internals are more isolated. Using a URL directly from the host element to load a component seems like the most direct mechanism to rally around to provide that isolation. I'm not saying that the components need the same isolation as provided by <iframe>, but using a URL closely associated with the host element on which the component is loaded makes it much more direct to initially flag things like style, script, and document markup access/isolation, since you might not require script to get things setup using today's defined primitives. I see the ShadowRoot as an object that looks a lot like the gateway to a component, but which lacks any of the access-control mechanics because it is always at the mercy of the host. A URL model would [in theory] be able to bring a ShadowRoot into existence with appropriate access control. Otherwise, you have to somehow convey the <link rel=import>'s URL-based restrictions into all created components, which is possible, but seems overly complicated. Such a proposal to use a URL to directly load a component's shadow dom does require a bit of tweaking of some existing ideas. For example, it might need to bring some of custom elements's binding mechanisms into place for the host element (or how does the component interface/create the host OM?).
I don't mind this type of syntax sugaring conceptually, but I would like to make sure that all of the hooks to do by the browser are exposed to the web developer, so that they could do the same exact thing, but with a different type of sugar (cane vs. beet, I guess)
(In reply to Dimitri Glazkov from comment #2) > I don't mind this type of syntax sugaring conceptually, but I would like to > make sure that all of the hooks to do by the browser are exposed to the web > developer, so that they could do the same exact thing, but with a different > type of sugar (cane vs. beet, I guess) ...and I think you are very close--most of the basic concepts are already defined. There still some missing pieces in CSS and I think that's where the most work is needed.
Moved to https://github.com/w3c/webcomponents/issues/146