RE: [Shadow] URL-based shadows?
>From: Anne van Kesteren [mailto:ann...@annevk.nl] > >Depending on the changes we make based on > https://github.com/w3c/webcomponents/wiki/Shadow-DOM:-Contentious-Bits > >this might already be the case. Also, I believe currently the Web >Components polyfill makes some assumptions about all of Web Components >being supported if you support one of them. So you can't e.g. ship >Custom Elements without HTML Imports... So API changes might already >be necessary just to avoid breaking the web. I'm looking forward to the meet-up!
Re: [Shadow] URL-based shadows?
On Fri, Mar 20, 2015 at 10:23 PM, Travis Leithead wrote: > Are we OK with a non-URL-based creation model (as used today) being fairly > different from a URL-based creation model? I think so. > [A] breaking change for existing implementations. Depending on the changes we make based on https://github.com/w3c/webcomponents/wiki/Shadow-DOM:-Contentious-Bits this might already be the case. Also, I believe currently the Web Components polyfill makes some assumptions about all of Web Components being supported if you support one of them. So you can't e.g. ship Custom Elements without HTML Imports... So API changes might already be necessary just to avoid breaking the web. -- https://annevankesteren.nl/
Re: [Shadow] URL-based shadows?
> On Mar 20, 2015, at 2:34 PM, Travis Leithead > wrote: > >> Ryosuke Niwa [mailto:rn...@apple.com] wrote: >> >>> Travis wrote: >>> 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. >> >> This approach works for same-origin use cases but we couldn’t come up with a >> good imperative API for cross-origin scenarios. > > Focusing on the imperative API for cross-origin scenarios sounds like a > useful endeavor to continue. Can you refer me to older proposals to review? I don't recall any public proposal made. >>> 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 or >>> in order to extend its host's feature set. >> >> That use case comes up frequently on this list but I think that needs to be >> addressed by CSS-based decorators. If we let custom “appearance” add a JS >> API, then UA wouldn’t be able to rip it apart for accessibility or for new >> platforms. > > Can you clarify what you mean by that last sentence? I don't follow...? Let me restate what I tried to say: I think the reason attaching a shadow DOM on input and select elements come up as a use case is because people think it's a mechanism by which we can replace the appearance of those from control elements while preserving semantics and keeping them accessible. Some people have also argued that such an approach will let future platforms to ignore the shadow DOM and use a more platform-appropriate appearance instead. However, I'd argue that's a fraud concept because we can't assume the ARIA role of the shadow DOM to be that of the host element since the shadow DOM can contain multiple "controls" that the user needs to interact with; e.g. input[type=date], for example, may show a calendar widget with a control to select year, month, etc... inside its shadow DOM. We can't ignore the shadow DOM entirely either if it's interacting with scripts since the rest of the page can make depend on the side effects of shadow DOM being there; e.g. updating some global state or sanitizing the value. It's particularly problematic in the case the author intended the shadow DOM to extend the builtin elements because that's precisely when the author assumes the script that attached the shadow DOM to be doing extra work or even providing extra methods and properties on the element via custom elements. - R. Niwa
RE: [Shadow] URL-based shadows?
>Ryosuke Niwa [mailto:rn...@apple.com] wrote: > >> Travis wrote: >> 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. > >This approach works for same-origin use cases but we couldn’t come up with a >good imperative API for cross-origin scenarios. Focusing on the imperative API for cross-origin scenarios sounds like a useful endeavor to continue. Can you refer me to older proposals to review? >> 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 or >> in order to extend its host's feature set. > >That use case comes up frequently on this list but I think that needs to be >addressed by CSS-based decorators. If we let custom “appearance” add a JS >API, then UA wouldn’t be able to rip it apart for accessibility or for new >platforms. Can you clarify what you mean by that last sentence? I don't follow...?
Re: [Shadow] URL-based shadows?
Yes, loading components via imports today is "use at your own risk" since you pull that content directly into your trust boundary. At least with
Re: [Shadow] URL-based shadows?
On Thu, Mar 19, 2015 at 12:08 AM, Travis Leithead wrote: > 5. I like this. Though it's really only necessary for the cross-origin use > case. I think it's worth mentioning that the existing setup further encourages the rather dangerous practice of including and trusting cross-origin scripts. E.g. if you include an HTML import from angularjs.org you are effectively surrendering all the user's localStorage, non-protected cookies, indexed DB, etc. to that origin. Finding ways to move away from such practices while retaining most of the functionality has significant value. -- https://annevankesteren.nl/
Re: [Shadow] URL-based shadows?
On Wed, Mar 18, 2015 at 10:25 PM, Ryosuke Niwa wrote: > [1] https://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0418.html So one flaw with this approach is that a cross-origin custom element would have no visible API surface. That part is very much unlike what et al offer today. I remember at one point having the idea that we could make attributes and methods instantiated in some declarative manner and that when they are invoked they would use a behind-the-scenes postMessage()-based protocol instead. But that would require some kind of block-on-other-global semantics. Or in other words, you can communicate with a component through postMessage(), and getter/setter/methods would be sugar for that to make it look a bit more normal on the outside. -- https://annevankesteren.nl/
Re: [Shadow] URL-based shadows?
> On Mar 18, 2015, at 4:08 PM, Travis Leithead > wrote: > >> 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). We’re still very much interested in pursuing this use case. > 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. The reason I made that proposal was because we didn’t want to have two completely separate APIs for defining same-origin and cross-origin components. In the ideal world, we would have single component model that works across same-origin as well as cross-origin with varying degrees of freedom and restrictions. I agree that same-origin components that run in the context of the hosting document/page is a lot more interesting from spec and implementation complexity because it involves more complicated features of shadow DOM such as insertion points but that doesn’t preclude us from making sure cross-origin scenario works just as well. > 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. This approach works for same-origin use cases but we couldn’t come up with a good imperative API for cross-origin scenarios. > 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 or > in order to extend its host's feature set. That use case comes up frequently on this list but I think that needs to be addressed by CSS-based decorators. If we let custom “appearance” add a JS API, then UA wouldn’t be able to rip it apart for accessibility or for new platforms. - R. Niwa
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 or 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 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: https://webkit.org/components.html"; defines="like-button”> and using it in the same document (that imported components.html): https://build.webkit.org/";>Like build.webkit.org 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 >
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
Re: [Shadow] URL-based shadows?
> On Mar 12, 2015, at 5:46 PM, Travis Leithead > 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: https://webkit.org/components.html"; defines="like-button”> and using it in the same document (that imported components.html): https://build.webkit.org/";>Like build.webkit.org 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 Mon, Mar 16, 2015 at 3:55 AM, Anne van Kesteren wrote: > On Fri, Mar 13, 2015 at 6:44 PM, Dimitri Glazkov > 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 et al > today. > Agree. :DG<
Re: [Shadow] URL-based shadows?
On Fri, Mar 13, 2015 at 6:44 PM, Dimitri Glazkov 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 et al today. -- https://annevankesteren.nl/
Re: [Shadow] URL-based shadows?
On Fri, Mar 13, 2015 at 12:57 PM, Travis Leithead < travis.leith...@microsoft.com> wrote: > Ah, thanks Dimitri. > > > After reading that, I'm also receiving it rather "coolly". It's a very > interesting idea, but as it relates to web components, its errs strongly on > the side of isolation to the degree that the component would be more > isolated than an iframe today; at least in same-domain, non-sandboxed > iframes, you can directly access the document via the contentWindow > property if desired; furthermore styling of this DOMWorker thing which is > running in a separate thread would be complex to say the least from an > implementation standpoint. I definitely want to stay firmly on the same > thread for Shadow DOMs [image: 😊]. > Threads don't necessarily come into play here. The proposal doesn't mention it, but Elliott specifically wanted to stay on the same thread. This is not technically a "worker", more like an "isolator". But anyway -- it does sound different from your idea, which I captured into https://www.w3.org/Bugs/Public/show_bug.cgi?id=28211. :DG<
Re: [Shadow] URL-based shadows?
Ah, thanks Dimitri.
After reading that, I'm also receiving it rather "coolly". It's a very
interesting idea, but as it relates to web components, its errs strongly on the
side of isolation to the degree that the component would be more isolated than
an iframe today; at least in same-domain, non-sandboxed iframes, you can
directly access the document via the contentWindow property if desired;
furthermore styling of this DOMWorker thing which is running in a separate
thread would be complex to say the least from an implementation standpoint. I
definitely want to stay firmly on the same thread for Shadow DOMs ??.
Back to what I'm thinking...
The way I see it, an HTML Import is already a shadow DOM builder (from a URL).
Imports point to a URL, fetch it, parse it (in the context of the parent's
scripting global environment), and then drop the completed document (and it's
dependents) in the 'import' property of the Link element. HTML Imports don't
render the imported document anywhere ('cause it ain't bound to an element
yet--where would you render it?).
If ShadowRoot constructors had the ability to load from a URL, I would propose
that the good parts of HTML Imports be used as the model for the loaded shadow
dom. There would be a few tweaks of course, but the model appears sound to me.
Why is this alluring to me?
* Loading a custom element is more... componentized. The element's shadow dom
(and behavior) can be imported locally in relation to the element host. >From
what I have heard recently, custom elements (of sufficient complexity) without
shadow dom doesn't make much sense.
* The URL can be the basis for script-level access control to the component's
shadow dom (a known and well-established pattern that exists for iframe).
* We can reuse much of the existing investment in imports
* Shadow dom components are allowed to independently load resources (e.g.,
notably stylesheets) behind a potentially access-controlled boundary
* Existing patterns for synchronously loading a shadow dom as work today
(without a URL) may be largely unaffected.
From: Dimitri Glazkov
Sent: Friday, March 13, 2015 10:44 AM
To: Travis Leithead
Cc: WebApps WG; Anne van Kesteren (ann...@annevk.nl); Arron Eicholz; Elliott
Sprehn
Subject: Re: [Shadow] URL-based shadows?
... found it:
https://docs.google.com/document/d/1V7ci1-lBTY6AJxgN99aCMwjZKCjKv1v3y_7WLtcgM00/edit?pli=1
:DG<
On Thu, Mar 12, 2015 at 6:05 PM, Dimitri Glazkov
mailto:dglaz...@google.com>> wrote:
Yep. Elliott (cc'd) had a proposal like this a while back. It was coolly
received (can't remember the details).
:DG<
On Thu, Mar 12, 2015 at 5:46 PM, Travis Leithead
mailto:travis.leith...@microsoft.com>> wrote:
Dimitri et al.,
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.
Thoughts?
Re: [Shadow] URL-based shadows?
... found it: https://docs.google.com/document/d/1V7ci1-lBTY6AJxgN99aCMwjZKCjKv1v3y_7WLtcgM00/edit?pli=1 :DG< On Thu, Mar 12, 2015 at 6:05 PM, Dimitri Glazkov wrote: > Yep. Elliott (cc'd) had a proposal like this a while back. It was coolly > received (can't remember the details). > > :DG< > > On Thu, Mar 12, 2015 at 5:46 PM, Travis Leithead < > travis.leith...@microsoft.com> wrote: > >> Dimitri et al., >> >> >> >>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. >> >> >> >> Thoughts? >> > >
Re: [Shadow] URL-based shadows?
Yep. Elliott (cc'd) had a proposal like this a while back. It was coolly received (can't remember the details). :DG< On Thu, Mar 12, 2015 at 5:46 PM, Travis Leithead < travis.leith...@microsoft.com> wrote: > Dimitri et al., > > > >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. > > > > Thoughts? >
[Shadow] URL-based shadows?
Dimitri et al.,
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.
Thoughts?
