RE: [Shadow] URL-based shadows?
From: Ryosuke Niwa [mailto:rn...@apple.com] I think this idea resonates well with the cross-origin use case / API change proposal we made two years ago [1]. In that proposal, we went a step further and tied custom elements with URLs so that those shadow DOM can be automatically instantiated by simply using those custom elements. Thanks for the referral Ryosuke! In reading the proposal [1], I understood the following points (that interested me anyway): 1. Separate (isolated) script engine (your point #1 wanting to modify imports). Facilitates iframe-like isolation between host and root to enable cross-origin use case. 2. Importing document manually declares the desired custom elements. Very elegant. 3. Shadow DOMs limited to custom elements. 4. Many declarative extensions to template to enable custom element bindings. I see you recognized template's powers at creating a non-rendered shadow-dom already, and just took the leap to figure out how to auto bind them to custom elements :-) 5. Expose dataset to the root (even cross-domain) I'm not sure if you are still interested in pursuing all of these features, or what their importance/weight is at this point (two years later). Some of my opinions, matching the numbering up to the above list: 1. I think one of the things that makes web components separate and interesting from existing iframes is the fact that they load and run in context, in other words, in the context of the global script engine of the hosting page. I don't think there's anything inherently wrong with how components loaded via iframes work today, so the cross-origin use case for web components is not something I'm motivated to solve (using web components). I suspect that a cross-origin use case is important, but its level of integration will of necessity be more limited, and I suspect it will lead to a different design than what we have with current web components. 2.4. I keep running into trouble when thinking about a declarative model for web components because declarative models are based on persistent objects in the DOM, and those persistent objects are fully mutable. In other words, you have to either accept and spec accordingly what happens when key attributes are changed (e.g., your defines and interface attributes), or you have to limit mutability such that changes are only read-once (for example). I prefer to let frameworks write the declarative syntactic sugar in the case of web components, and steer clear of declarative models unless the mutability works in favor of the proposal. 3. I don't have an opinion here yet. It seems like limiting to custom elements makes shadow dom easier to implement. But I can also imagine cases where the component really wants to hook up to an element like input or select in order to extend its host's feature set. 5. I like this. Though it's really only necessary for the cross-origin use case. [1] https://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0418.html From: Ryosuke Niwa [mailto:rn...@apple.com] Sent: Wednesday, March 18, 2015 2:26 PM To: Travis Leithead Cc: Dimitri Glazkov (dglaz...@google.com); WebApps WG; Anne van Kesteren (ann...@annevk.nl); Arron Eicholz Subject: Re: [Shadow] URL-based shadows? On Mar 12, 2015, at 5:46 PM, Travis Leithead travis.leith...@microsoft.com wrote: Has the idea of loading/parsing a Shadow DOM directly from a URL been discussed already? (e.g., a sort-of “micro-import” or an import that parses its document directly into the ShadowRoot container?) I’m curious to know if there’s some obvious flaw that I’m missing. element.createShadowRoot(“path to my component”); This is an idea around building components from the “inside out”, and using the URL as the basis for script-level access control to the Shadow contents. Hi Travis, I think this idea resonates well with the cross-origin use case / API change proposal we made two years ago [1]. In that proposal, we went a step further and tied custom elements with URLs so that those shadow DOM can be automatically instantiated by simply using those custom elements. e.g. if “like-button” element was defined in https://webkit.org/components.html, then we can use that component by simply importing the definition: link rel=import href=https://webkit.org/components.html; defines=like-button” and using it in the same document (that imported components.html): like-button data-url=https://build.webkit.org/;Like build.webkit.org/like-button We thought this model was more developer friendly than having each user of the component manually create shadow root. We also didn’t want to make component authors deal with situations like a shadow root being attached to an iframe, input, etc.. [1] https://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0418.html - R. Niwa
Re: [Shadow] URL-based shadows?
On Wed, Mar 18, 2015 at 2:35 PM, Travis Leithead travis.leith...@microsoft.com wrote: I think ‘Worker’ threw me off at first J. My original use case was to make the current model of loading components more “local”, as AFAIK, these components can only presently be loaded by code you trust, e.g., via some script library somewhere imported via a script tag, or by way of link rel=import which pulls in same-origin or CORS-approved cross-origin content. I hadn’t considered cross-domain components, which is another interesting use-case, I agree. The bit of magic in this proposal that improves on the iframe experience is the SharedWorker-like single instance across related components. Generally speaking, is cross-origin components something that we should be looking to address? The strong isolation is a good model, but very restrictive and not that far-different from iframes IMO. I also can’t help thinking how the discussion of closed vs. open component access relates to cross-origin (or not) components. I think it's worth trying. And it's the only custom controls use case from the original list that we didn't yet address: http://www.w3.org/2008/webapps/wiki/Component_Model_Use_Cases#Custom_Controls We can discuss the priority of this relative to other use cases. :DG
Minuts IndieUI Teleconference 18 March 2015
http://www.w3.org/2015/03/18-indie-ui-minutes.html
Re: template namespace attribute proposal
On Mar 16, 2015, at 3:14 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: [Sorry for the reply-chain breaking; Gmail is being super weird about your message in particular, and won't let me reply directly to it. Some bug.] Karl Dubost said: The intersection seems to be: ['a', 'style', 'script', 'track', 'title', 'canvas', 'source', 'video', 'iframe', 'audio', 'font'] Whoops, sorry, forgot about title. We can resolve that conflict in favor of SVG; putting an html title into a template is, I suspect, exceedingly rare. That may be true but the added complexity of title inside a template element being special (i.e. it’s treated as SVG instead of HTML) may not be worth the effort. HTML parser is already complex enough that using a simple rule of always falling back to HTML if element names are ambiguous may result in a better overall developer ergonomics. - R. Niwa
Re: template namespace attribute proposal
On Wed, Mar 18, 2015 at 2:06 PM, Ryosuke Niwa rn...@apple.com wrote: On Mar 16, 2015, at 3:14 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Karl Dubost said: The intersection seems to be: ['a', 'style', 'script', 'track', 'title', 'canvas', 'source', 'video', 'iframe', 'audio', 'font'] Whoops, sorry, forgot about title. We can resolve that conflict in favor of SVG; putting an html title into a template is, I suspect, exceedingly rare. That may be true but the added complexity of title inside a template element being special (i.e. it’s treated as SVG instead of HTML) may not be worth the effort. HTML parser is already complex enough that using a simple rule of always falling back to HTML if element names are ambiguous may result in a better overall developer ergonomics. Possibly, dunno. I could go either way. Consistently resolving ambiguity in one direction could be simpler, but so could resolving in favor of the massively-more-likely one. Spec/impl complexity isn't really of concern here; impls would need an explicit list of elements/namespaces anyway. The spec could possible get away with a blanket statement, but that opens up the possibility of ambiguity, like image (which should clearly be SVG, despite the parser turning it into img for you). ~TJ
Re: template namespace attribute proposal
On Mar 18, 2015, at 2:19 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Mar 18, 2015 at 2:06 PM, Ryosuke Niwa rn...@apple.com wrote: On Mar 16, 2015, at 3:14 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Karl Dubost said: The intersection seems to be: ['a', 'style', 'script', 'track', 'title', 'canvas', 'source', 'video', 'iframe', 'audio', 'font'] Whoops, sorry, forgot about title. We can resolve that conflict in favor of SVG; putting an html title into a template is, I suspect, exceedingly rare. That may be true but the added complexity of title inside a template element being special (i.e. it’s treated as SVG instead of HTML) may not be worth the effort. HTML parser is already complex enough that using a simple rule of always falling back to HTML if element names are ambiguous may result in a better overall developer ergonomics. Possibly, dunno. I could go either way. Consistently resolving ambiguity in one direction could be simpler, but so could resolving in favor of the massively-more-likely one. Spec/impl complexity isn't really of concern here; impls would need an explicit list of elements/namespaces anyway. The spec could possible get away with a blanket statement, but that opens up the possibility of ambiguity, like image (which should clearly be SVG, despite the parser turning it into img for you). Implementation complexity isn’t my concern. Exception for title will be yet another random fact Web developer needs to be aware of. In general, we have too much tolerance for complexity and exceptions to rules on the Web platform. We should strive to make the Web platform as simple as possible so that humans can comprehend. - R. Niwa
RE: [Shadow] URL-based shadows?
I think ‘Worker’ threw me off at first ☺. My original use case was to make the current model of loading components more “local”, as AFAIK, these components can only presently be loaded by code you trust, e.g., via some script library somewhere imported via a script tag, or by way of link rel=import which pulls in same-origin or CORS-approved cross-origin content. I hadn’t considered cross-domain components, which is another interesting use-case, I agree. The bit of magic in this proposal that improves on the iframe experience is the SharedWorker-like single instance across related components. Generally speaking, is cross-origin components something that we should be looking to address? The strong isolation is a good model, but very restrictive and not that far-different from iframes IMO. I also can’t help thinking how the discussion of closed vs. open component access relates to cross-origin (or not) components. From: Dimitri Glazkov [mailto:dglaz...@google.com] Sent: Monday, March 16, 2015 8:07 AM To: Anne van Kesteren Cc: Travis Leithead; WebApps WG; Arron Eicholz; Elliott Sprehn Subject: Re: [Shadow] URL-based shadows? On Mon, Mar 16, 2015 at 3:55 AM, Anne van Kesteren ann...@annevk.nlmailto:ann...@annevk.nl wrote: On Fri, Mar 13, 2015 at 6:44 PM, Dimitri Glazkov dglaz...@google.commailto:dglaz...@google.com wrote: https://docs.google.com/document/d/1V7ci1-lBTY6AJxgN99aCMwjZKCjKv1v3y_7WLtcgM00/edit?pli=1 That seems really cool. I'm not sure worker is the right terminology since at the moment worker sort of implies there's no node tree available due to the complexity that would give. But an isolated global for a set of reusable components that are mixed into the document seems roughly in line with what we have with input et al today. Agree. :DG
Re: [Shadow] URL-based shadows?
On Mar 12, 2015, at 5:46 PM, Travis Leithead travis.leith...@microsoft.com wrote: Has the idea of loading/parsing a Shadow DOM directly from a URL been discussed already? (e.g., a sort-of “micro-import” or an import that parses its document directly into the ShadowRoot container?) I’m curious to know if there’s some obvious flaw that I’m missing. element.createShadowRoot(“path to my component”); This is an idea around building components from the “inside out”, and using the URL as the basis for script-level access control to the Shadow contents. Hi Travis, I think this idea resonates well with the cross-origin use case / API change proposal we made two years ago [1]. In that proposal, we went a step further and tied custom elements with URLs so that those shadow DOM can be automatically instantiated by simply using those custom elements. e.g. if “like-button” element was defined in https://webkit.org/components.html, then we can use that component by simply importing the definition: link rel=import href=https://webkit.org/components.html; defines=like-button” and using it in the same document (that imported components.html): like-button data-url=https://build.webkit.org/;Like build.webkit.org/like-button We thought this model was more developer friendly than having each user of the component manually create shadow root. We also didn’t want to make component authors deal with situations like a shadow root being attached to an iframe, input, etc.. [1] https://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0418.html - R. Niwa
[Bug 27222] [Shadow]: Define how attributes are handled in shadow DOM
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27222 Koji Ishii kojii...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #23 from Koji Ishii kojii...@gmail.com --- I'm resolving this bug as there seems to be no further comments. -- You are receiving this mail because: You are on the CC list for the bug.
