Re: [webcomponents] How about let's go with slots?

2015-05-15 Thread Steve Orvell
With respect to Dimitri's *unpacking* notion, we think it can work. In most cases today the redistribution tree is not large; however, if there were a lot of final destination points in that tree, unpacking would be cumbersome because you need to define a slot at every level for every final

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

2015-04-27 Thread Steve Orvell
such that if parent distributes elements to its shadowRoot, elements in the shadowRoot will see the event? On Mon, Apr 27, 2015 at 1:45 PM, Ryosuke Niwa rn...@apple.com wrote: On Apr 27, 2015, at 11:47 AM, Steve Orvell sorv...@google.com wrote: Here's a minimal and hopefully simple proposal that we can flesh

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

2015-04-27 Thread Steve Orvell
it is just another element from his perspective. How can I, the author of x-foo, craft my element such that I don't violate Bob's expectations? Does your proposal support this? On Mon, Apr 27, 2015 at 3:42 PM, Ryosuke Niwa rn...@apple.com wrote: On Apr 27, 2015, at 3:15 PM, Steve Orvell sorv

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

2015-04-27 Thread Steve Orvell
that the shadowRoot author can be aware of this change since the author is causing it to happen. On Mon, Apr 27, 2015 at 7:01 PM, Ryosuke Niwa rn...@apple.com wrote: On Apr 27, 2015, at 5:43 PM, Steve Orvell sorv...@google.com wrote: That might be an acceptable mode of operations. If you

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

2015-04-27 Thread Steve Orvell
Here's a minimal and hopefully simple proposal that we can flesh out if this seems like an interesting api direction: https://gist.github.com/sorvell/e201c25ec39480be66aa We keep the currently spec'd distribution algorithm/timing but remove `select` in favor of an explicit selection callback.

Re: [webcomponents]: The Shadow Cat in the Hat Edition

2013-09-19 Thread Steve Orvell
For context here's another thread about ::part where we start to look a little into the rabbit hole: http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0012.html One wants the expressiveness of css applied to ::part but things get complicated very fast and the 'shadow cat' starts to

Re: [webcomponents]: Naming the Baby

2013-03-27 Thread Steve Orvell
The word component will be used as a synonym for a custom element. Since this spec is designed to load various html resources that may include custom element definitions, attaching the word component to this spec is just confusing. We're loading html so rel=html is most straightforward. The name

Re: [webcomponents]: Naming the Baby

2013-03-27 Thread Steve Orvell
of import or include, especially seeing that other web developers are aligned with this lingo. My 0$.02 On Wed, Mar 27, 2013 at 11:29 AM, Steve Orvell sorv...@google.com wrote: The word component will be used as a synonym for a custom element. Since this spec is designed to load various html

Re: [webcomponents]: First stab at the Web Components spec

2013-03-08 Thread Steve Orvell
at 12:22 PM, Steve Orvell sorv...@google.com wrote: I also find the name confusing. It's common to use the term 'component' when describing the functionality of a custom element. What about HTML Modules? Then we probably need to rename link rel=module for consistency? :DG

Re: [webcomponents]: First stab at the Web Components spec

2013-03-08 Thread Steve Orvell
Also, it sounds like this specification should be titled Fetching components or some such as that's about all it defines. I also find the name confusing. It's common to use the term 'component' when describing the functionality of a custom element. What about HTML Modules? On Fri, Mar 8,