RE: [Shadow] URL-based shadows?

2015-03-26 Thread Travis Leithead
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?

2015-03-26 Thread Anne van Kesteren
On Fri, Mar 20, 2015 at 10:23 PM, Travis Leithead
travis.leith...@microsoft.com 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?

2015-03-20 Thread Travis Leithead
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 script src 
the platform takes measures to ensure that the imported content (the code) 
can't be easily observed if it doesn't choose to be.

It seems clear so far that we all want to enable scenarios for both same-origin 
and cross-origin components. I think we understand that cross-origin components 
will need to be more restricted. It also seems like there is agreement to want 
to align the developer experience for the same-origin and cross-origin models 
as closely as possible (rather than having two very different models).

I'd like to get a sense for what folks' thoughts are on the current 
non-URL-based creation model (createShadowRoot)? Are we OK with a non-URL-based 
creation model (as used today) being fairly different from a URL-based creation 
model? If so, then we can work on figuring this out later and/or separately 
from the current approach. If not, and we want to have non-URL and URL-based 
models behave similarly, then it seems like we are signing up to potentially 
change the current shadow DOM creation model--a breaking change for existing 
implementations.

Perhaps there's another approach I haven't considered. My preference is not to 
start over, but to work within the existing creation model framework with 
incremental changes, not major re-designs. Adding in an isolated scripting 
environment for shadow dom (of some form) is a fairly large change in my view.


From: Anne van Kesteren ann...@annevk.nl
Sent: Thursday, March 19, 2015 1:24 AM
To: Travis Leithead
Cc: Ryosuke Niwa; Dimitri Glazkov (dglaz...@google.com); WebApps WG; Arron 
Eicholz
Subject: Re: [Shadow] URL-based shadows?

On Thu, Mar 19, 2015 at 12:08 AM, Travis Leithead
travis.leith...@microsoft.com 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?

2015-03-20 Thread Travis Leithead
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 input or 
 select 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?

2015-03-18 Thread Travis Leithead
 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?

2015-03-18 Thread Dimitri Glazkov
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


RE: [Shadow] URL-based shadows?

2015-03-18 Thread Travis Leithead
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?

2015-03-18 Thread Ryosuke Niwa

 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?

2015-03-16 Thread Anne van Kesteren
On Fri, Mar 13, 2015 at 6:44 PM, Dimitri Glazkov 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.


-- 
https://annevankesteren.nl/



Re: [Shadow] URL-based shadows?

2015-03-16 Thread Dimitri Glazkov
On Mon, Mar 16, 2015 at 3:55 AM, Anne van Kesteren ann...@annevk.nl wrote:

 On Fri, Mar 13, 2015 at 6:44 PM, Dimitri Glazkov 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?

2015-03-13 Thread Dimitri Glazkov
... 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 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 
 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?

2015-03-13 Thread Dimitri Glazkov
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?

2015-03-13 Thread Travis Leithead
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 dglaz...@google.com
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 
dglaz...@google.commailto: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 
travis.leith...@microsoft.commailto: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?

2015-03-12 Thread Travis Leithead
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?

2015-03-12 Thread Dimitri Glazkov
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?