from:"Ryosuke Niwa"

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

2015-04-25 Thread Ryosuke Niwa

Sure, I'll put the summary of discussion there later.

- R. Niwa

 On Apr 25, 2015, at 10:00 AM, Hayato Ito hay...@chromium.org wrote:
 
 Thank you, guys.
 I really appreciate if you guys could use the W3C bug, 18429, to discuss this 
 kind of specific topic about Shadow DOM so that we can track the progress 
 easily in one place. I'm not fan of the discussion being scattered. :)
 
 https://www.w3.org/Bugs/Public/show_bug.cgi?id=18429
 
 
 On Sat, Apr 25, 2015 at 9:32 AM Anne van Kesteren ann...@annevk.nl wrote:
 On Sat, Apr 25, 2015 at 12:17 AM, Ryosuke Niwa rn...@apple.com wrote:
  In today's F2F, I've got an action item to come up with a concrete workable
  proposal for imperative API.  I had a great chat about this afterwards with
  various people who attended F2F and here's a summary.  I'll continue to 
  work
  with Dimitri  Erik to work out details in the coming months (our deadline
  is July 13th).
 
  https://gist.github.com/rniwa/2f14588926e1a11c65d3
 
 I thought we came up with something somewhat simpler that didn't
 require adding an event or adding remove() for that matter:
 
   https://gist.github.com/annevk/e9e61801fcfb251389ef
 
 I added an example there that shows how you could implement content
 select, it's rather trivial with the matches() API. I think you can
 derive any other use case easily from that example, though I'm willing
 to help guide people through others if it is unclear. I guess we might
 still want positional insertion as a convenience though the above
 seems to be all you need primitive-wise.
 
 
 --
 https://annevankesteren.nl/

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

2015-04-25 Thread Ryosuke Niwa


 On Apr 25, 2015, at 9:28 AM, Anne van Kesteren ann...@annevk.nl wrote:
 
 On Sat, Apr 25, 2015 at 12:17 AM, Ryosuke Niwa rn...@apple.com wrote:
 In today's F2F, I've got an action item to come up with a concrete workable
 proposal for imperative API.  I had a great chat about this afterwards with
 various people who attended F2F and here's a summary.  I'll continue to work
 with Dimitri  Erik to work out details in the coming months (our deadline
 is July 13th).
 
 https://gist.github.com/rniwa/2f14588926e1a11c65d3
 
 I thought we came up with something somewhat simpler that didn't
 require adding an event or adding remove() for that matter:

That's the second approach I mentioned.  Like I mentioned in the gist, this 
model assumes that redistribution is done by UA and only direct children can be 
distributed.  I realized that those constraints are no longer necessary given 
we don't have content select or multiple generations of shadow DOM.

  https://gist.github.com/annevk/e9e61801fcfb251389ef
 
 I added an example there that shows how you could implement content
 select, it's rather trivial with the matches() API. I think you can
 derive any other use case easily from that example, though I'm willing
 to help guide people through others if it is unclear. I guess we might
 still want positional insertion as a convenience though the above
 seems to be all you need primitive-wise.
 
 
 -- 
 https://annevankesteren.nl/

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

2015-04-25 Thread Ryosuke Niwa


 On Apr 25, 2015, at 9:28 AM, Anne van Kesteren ann...@annevk.nl wrote:
 
 On Sat, Apr 25, 2015 at 12:17 AM, Ryosuke Niwa rn...@apple.com wrote:
 In today's F2F, I've got an action item to come up with a concrete workable
 proposal for imperative API.  I had a great chat about this afterwards with
 various people who attended F2F and here's a summary.  I'll continue to work
 with Dimitri  Erik to work out details in the coming months (our deadline
 is July 13th).
 
 https://gist.github.com/rniwa/2f14588926e1a11c65d3
 
 I thought we came up with something somewhat simpler that didn't
 require adding an event or adding remove() for that matter:
 
  https://gist.github.com/annevk/e9e61801fcfb251389ef 
 https://gist.github.com/annevk/e9e61801fcfb251389ef

```js
var shadow = host.createShadowRoot({
  mode: closed,
  distribute: (distributionList, insertionList) = {
for(var i = 0; i  distributionList.length; i++) {
  for(var ii = 0; ii  insertionList.length; ii++) {
var select = insertionList[ii].getAttribute(select)
if(select != null  distributionList[i].matches(select)) {
  insertionList[ii].add(distrubtionList[i])
} else if(select != null) {
  insertionList[ii].add(distrubtionList[i])
}
  }
}
  }
})
host.shadowRoot.distribute()
```

One major drawback of this API is computing insertionList is expensive because 
we'd have to either (where n is the number of nodes in the shadow DOM):
Maintain an ordered list of insertion points, which results in O(n) algorithm 
to run whenever a content element is inserted or removed.
Lazily compute the ordered list of insertion points when `distribute` callback 
is about to get called in O(n).

If we wanted to allow non-direct child descendent (e.g. grand child node) of 
the host to be distributed, then we'd also need O(m) algorithm where m is the 
number of under the host element.  It might be okay to carry on the current 
restraint that only direct child of shadow host can be distributed into 
insertion points but I can't think of a good reason as to why such a 
restriction is desirable.

- R. Niwa

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

2015-04-25 Thread Ryosuke Niwa


 On Apr 25, 2015, at 1:17 PM, Olli Pettay o...@pettay.fi wrote:
 
 On 04/25/2015 09:28 AM, Anne van Kesteren wrote:
 On Sat, Apr 25, 2015 at 12:17 AM, Ryosuke Niwa rn...@apple.com wrote:
 In today's F2F, I've got an action item to come up with a concrete workable
 proposal for imperative API.  I had a great chat about this afterwards with
 various people who attended F2F and here's a summary.  I'll continue to work
 with Dimitri  Erik to work out details in the coming months (our deadline
 is July 13th).
 
 https://gist.github.com/rniwa/2f14588926e1a11c65d3
 
 I thought we came up with something somewhat simpler that didn't
 require adding an event or adding remove() for that matter:
 
   https://gist.github.com/annevk/e9e61801fcfb251389ef
 
 
 That is pretty much exactly how I was thinking the imperative API to work.
 (well, assuming errors in the example fixed)
 
 An example explaining how this all works in case of nested shadow trees would 
 be good.
 I assume the more nested shadow tree just may get some nodes, which were 
 already distributed, in the distributionList.

Right, that was the design we discussed.

 How does the distribute() behave? Does it end up invoking distribution in all 
 the nested shadow roots or only in the callee?

Yes, that's the only reason we need distribute() in the first place.  If we 
didn't have to care about redistribution, simply exposing methods to 
insert/remove distributed nodes on content element is sufficient.

 Should distribute callback be called automatically at the end of the 
 microtask if there has been relevant[1] DOM mutations since the last
 manual call to distribute()? That would make the API a bit simpler to use, if 
 one wouldn't have to use MutationObservers.

That's a possibility.  It could be an option to specify as well.  But there 
might be components that are not interested in updating distributed nodes for 
the sake of performance for example.  I'm not certain forcing everyone to 
always update distributed nodes is necessarily desirable given the lack of 
experience with an imperative API for distributing nodes.

 [1] Assuming we want to distribute only direct children, then any child list 
 change or any attribute change in the children
 might cause distribution() automatically.

I think that's a big if now that we've gotten rid of select attribute and 
multiple generations of shadow DOM.  As far as I could recall, one of the 
reasons we only supported distributing direct children was so that we could 
implement select attribute and multiple generations of shadow DOM.   If we 
wanted, we could always impose such a restriction in a declarative syntax and 
inheritance mechanism we add in v2 since those v2 APIs are supposed to build on 
top of this imperative API.

Another big if is whether we even need to let each shadow DOM select nodes to 
redistribute.  If we don't need to support filtering distributed nodes in 
insertion points for re-distribution (i.e. we either distribute everything 
under a given content element or nothing), then we don't need all of this 
redistribution mechanism baked into the browser and the model where we just 
have insert/remove on content element will work.

- R. Niwa

Proposal for changes to manage Shadow DOM content distribution

2015-04-21 Thread Ryosuke Niwa

Hi all,

Following WebApps discussion last year [1] and earlier this year [2] about 
template transclusions and inheritance in shadow DOM, Jan Miksovsky at 
Component Kitchen, Ted O'Connor and I (Ryosuke Niwa) at Apple had a meeting 
where we came up with changes to the way shadow DOM distributes nodes to better 
fit real world use cases.

After studying various real world use of web component APIs as well as exiting 
GUI frameworks, we noticed that selector based node distribution as currently 
spec'ed doesn't address common use cases and the extra flexibility CSS 
selectors offers isn't needed in practice.  Instead, we propose named insertion 
slots that could be filled with the contents in the original DOM as well as 
contents in subclasses.  Because the proposal uses the same slot filling 
mechanism for content distributions and inheritance transclusions, it 
eliminates the need for multiple shadow roots.

Please take a look at our proposal at 
https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution
 
https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution

[1] https://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0151.html 
https://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0151.html
[2] https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0611.html 
https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0611.html

Re: Proposal for changes to manage Shadow DOM content distribution

2015-04-21 Thread Ryosuke Niwa


 On Apr 21, 2015, at 10:17 PM, Brian Kardell bkard...@gmail.com wrote:
 On Apr 21, 2015 8:22 PM, Ryosuke Niwa rn...@apple.com 
 mailto:rn...@apple.com wrote:
 
  Hi all,
 
  Following WebApps discussion last year [1] and earlier this year [2] about 
  template transclusions and inheritance in shadow DOM, Jan Miksovsky at 
  Component Kitchen, Ted O'Connor and I (Ryosuke Niwa) at Apple had a meeting 
  where we came up with changes to the way shadow DOM distributes nodes to 
  better fit real world use cases.
 
  After studying various real world use of web component APIs as well as 
  exiting GUI frameworks, we noticed that selector based node distribution as 
  currently spec'ed doesn't address common use cases and the extra 
  flexibility CSS selectors offers isn't needed in practice.  Instead, we 
  propose named insertion slots that could be filled with the contents in 
  the original DOM as well as contents in subclasses.  Because the proposal 
  uses the same slot filling mechanism for content distributions and 
  inheritance transclusions, it eliminates the need for multiple shadow roots.
 
  Please take a look at our proposal at 
  https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution
   
  https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution
 
  [1] 
  https://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0151.html 
  https://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0151.html
  [2] 
  https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0611.html 
  https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0611.html
 
 
 I just wanted to note that a month or two I tried to assume nothing and come 
 up with a bare essentials concept which involved named slots.  Is there a 
 proposed a way to project from an attribute value into content or from 
 attribute to attribute..?
 
 In other words, if I had x-foo blah=hello . Can I map blah into a slot or 
 identify an attribute value in my template *as* a slot?
 

Not at the moment but I could imagine that such a feature could be easily 
added. e.g.

x-foo blah=hello

!-- implementation --
template element=x-foo
  content attrslot=blah
/template

- R. Niwa

Re: Proposal for changes to manage Shadow DOM content distribution

2015-04-21 Thread Ryosuke Niwa


 On Apr 21, 2015, at 9:43 PM, Daniel Freedman dfre...@google.com wrote:
 
 Hi Ryosuke,
 
 I want to start by thanking you, Ted, and Jan for taking the time to make 
 this proposal.
 
 I read through the proposal, and had a quick question about how 
 redistribution should work with this slot concept.
 I created a quick date-range-combo-box example that would take two date 
 inputs (start date and end date) and distribute them through the example 
 date-combo-box, but I found myself stuck.
 I can't name the two date inputs with the same slot or they will end up in 
 only one of the date-combo-box content elements, but date-combo-box only 
 takes inputs with slot inputElement.
 
 How should this work?
 
 I drafted a quick gist to illustrate this: 
 https://gist.github.com/azakus/676590eb4d5b07b94428 
 https://gist.github.com/azakus/676590eb4d5b07b94428
!-- instance --
date-range-combo-box
  input type=date content-slot=start!-- (1) --
  input type=date content-slot=end!-- (2) --
/date-range-combo-box
 
!— implementation of date-range-combo-box --
template
  shadow
date-combo-box!-- (3) --
   !--
   How can input[content-slot=start] end up in the content 
slot=inputElement
   in the date-combo-box ?
   --
  content slot=start/content
/date-combo-box
date-combo-box!-- (4) --
  content slot=end/content
/date-combo-box
  /shadow
/template

Am I right in assuming that you want to re-distribute (1) into (3)'s and (2) 
into (4)'s inputElements?  If so, I'd imagine one possible syntax is as follows:

template
  shadow
date-combo-box!-- (3) --
  content slot=start content-slot=inputElement/content
/date-combo-box
date-combo-box!-- (4) --
  content slot=end content-slot=inputElement/content
/date-combo-box
  /shadow
/template

Here, the content elements are both creating slots and fulfilling slots.

- R. Niwa

 On Tue, Apr 21, 2015 at 8:19 PM, Ryosuke Niwa rn...@apple.com 
 mailto:rn...@apple.com wrote:
 Hi all,
 
 Following WebApps discussion last year [1] and earlier this year [2] about 
 template transclusions and inheritance in shadow DOM, Jan Miksovsky at 
 Component Kitchen, Ted O'Connor and I (Ryosuke Niwa) at Apple had a meeting 
 where we came up with changes to the way shadow DOM distributes nodes to 
 better fit real world use cases.
 
 After studying various real world use of web component APIs as well as 
 exiting GUI frameworks, we noticed that selector based node distribution as 
 currently spec'ed doesn't address common use cases and the extra flexibility 
 CSS selectors offers isn't needed in practice.  Instead, we propose named 
 insertion slots that could be filled with the contents in the original DOM 
 as well as contents in subclasses.  Because the proposal uses the same slot 
 filling mechanism for content distributions and inheritance transclusions, it 
 eliminates the need for multiple shadow roots.
 
 Please take a look at our proposal at 
 https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution
  
 https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution
 
 [1] https://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0151.html 
 https://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0151.html
 [2] https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0611.html 
 https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0611.html

Re: Proposal for changes to manage Shadow DOM content distribution

2015-04-21 Thread Ryosuke Niwa


 On Apr 21, 2015, at 10:23 PM, Justin Fagnani justinfagn...@google.com wrote:
 
 I do want the ability to redirect distributed nodes into a holes in the base 
 template, so that part is welcome to me. However, my first reaction to the 
 slot idea is that forcing users to add the content-slot attribute on children 
 significantly impairs the DOM API surface area of custom elements.
 
 For the single-level distribution case, how is this different from content 
 select=[content-slot=name] except that content select can distribute based 
 on features of the children that might already exist, like tag names or an 
 attribute?

At the conceptual level, they're equivalent.  However, we didn't find the extra 
flexibility of using CSS selectors compelling as we mentioned in our proposal 
[1].

[1] See points 3 and 4 in 
https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution#some-issues-with-the-current-shadow-dom-spec

- R. Niwa

Re: Proposal for changes to manage Shadow DOM content distribution

2015-04-22 Thread Ryosuke Niwa


 On Apr 21, 2015, at 11:08 PM, Domenic Denicola d...@domenic.me wrote:
 
 From: Ryosuke Niwa [mailto:rn...@apple.com] 
 
 At the conceptual level, they're equivalent.  However, we didn't find the 
 extra flexibility of using CSS selectors compelling as we mentioned in our 
 proposal [1].
 
 details is such an example, I think? Is the following a correct example of 
 what client code would have to look like for details, under the proposal?
 
 details
  div content-slot=summaryStuff/div
  div content-slot=main
pMore/p
pStuff/p
  /div
 /details
 
 or, if you wanted to avoid the wrapper div,
 
 details
  div content-slot=summaryStuff/div
  p content-slot=mainMore/p
  p content-slot=mainStuff/p
 /details

This can just be 

details
 div content-slot=summaryStuff/div
 pMore/p
 pStuff/p
/details

if our implementation had something along the line of:

template element=details
  content slot=summary/content
  content/content
/template

since we still support unnamed content element as the catch-all insertion point 
as it is today.

I'd rather not do it because it's rather confusing and arbitrary but if we 
really wanted to, it might be okay to allow element name as a slot-content 
name. e.g. the above example reduces to:

details
 summaryStuff/summary
 pMore/p
 pStuff/p
/details

That is, each element implicitly defines content-slot attribute with the value 
set to its element name.

- R. Niwa

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

2015-04-25 Thread Ryosuke Niwa

Just to clarity, I obviously haven't had a time to discuss this with my
colleagues so I don't know which one (or something else entirely) we (Apple)
end up endorsing/opposing at the end.

On Apr 25, 2015, at 12:14 AM, Ryosuke Niwa rn...@apple.com wrote:

Hi all,

In today's F2F, I've got an action item to come up with a concrete workable
proposal for imperative API. I had a great chat about this afterwards with
various people who attended F2F and here's a summary. I'll continue to work
with Dimitri Erik to work out details in the coming months (our deadline is
July 13th).

https://gist.github.com/rniwa/2f14588926e1a11c65d3
https://gist.github.com/rniwa/2f14588926e1a11c65d3

Imperative API for Node Distribution in Shadow DOM

There are two approaches to the problem depending on whether we want to
natively support redistribution or not.

To recap, a redistribution of a node (N_1) happens when it's distributed to
an insertion point (I_1) inside a shadow root (S_1), and I_1's parent also
has a shadow root which contains an insertion point which ends picking up
N_1. e.g. the original tree may look like:

(host of S_1) - S_1
+ N_1 + (host of S_2) - S_2
+ I_1 + I_2
Here, (host of S_1) has N_1 as a child, and (host of S_2) is a child of S_1
and has I_1 as a child. S_2 has I_2 as a child. The composed tree, then, may
look like:

(host of S_1)
+ (host of S_2)
+ I_2
+ N_1

https://gist.github.com/rniwa/2f14588926e1a11c65d3#redistribution-is-implemented-by-authorsRedistribution
is implemented by authors

In this model, we can add insertAt and remove on content element and expose
distributedNodes defined as follows:

insertAt(Node nodeToDistribute, long index) - Inserts nodeToDistribute to the
list of the distributed nodes at index. It throws if nodeToDistribute is not
a descendent (or a direct child if wanted to keep this constraint) of the
shadow host of the ancestor shadow root of containt or if index is larger
than the length of distributedNodes.
remove(Node distributedNode) - Remove distributedNode from the list
distributed nodes. Throws if distributedNodes doesn't contain this node.
distributedNodes - Returns an array of nodes that are distributed into this
insertion point in the order they appear.
In addition, content fires a synchrnous distributionchanged event when
distributedNodeschanges (in response to calls to insertAt or remove).

https://gist.github.com/rniwa/2f14588926e1a11c65d3#prosPros

Very simple / very primitive looking.
Defers the exact mechanism/algorithm of re-distributions to component authors.
We can support distributing any descendent, not just direct children, to any
insertion points. This was not possible with select attribute especially with
the presence of multiple generations of shadow DOM due to perfomance problems.
Allows distributed nodes to be re-ordered (select doesn't allow this).
https://gist.github.com/rniwa/2f14588926e1a11c65d3#consCons

Each component needs to manually implement re-distributions by recursively
traversing through distributedNodes of content elements inside
distributedNodes of the content element if it didn't want to re-distribute
everything. This is particularly challenging because you need to listen to
distributionchanged event on every such content element. We might need
something aking to MutationObserver's subtree option to monitor this if we're
going this route.
It seems hard to support re-distribution natively in v2.

https://gist.github.com/rniwa/2f14588926e1a11c65d3#redistribution-is-implemented-by-uasRedistribution
is implemented by UAs

In this model, the browser is responsible for taking care of redistributions.
Namely, we would like to expose distributionPool on the shadow root which
contains the ordered list of nodes that could be distributed (because they're
direct children of the host) or re-distributed. Conceptually, you could think
of it as a depth first traversal of distributedNodes of every content
element. Because this list contains every candidate for (re)distribution,
it's impractical to include every descendent node especially if we wanted to
do synchronous updates so we're back to supporting only direct children for
distribution.

In this proposal, we add a new callback distributeCallback(NodeList
distributionPool) as an arguemnt (probably inside a dictionary) to
createShadowRoot. e.g.

var shadowRoot = element.createShadowRoot({
distributedCallback: function (distributionPool) {
... // code to distribute nodes
}
});
Unfortunately, we can't really use insertAt and remove in model because
distributionPoolmaybe changed under the foot by (outer) insertion points in
the light DOM if this shadow root to attached to a host inside another shadow
DOM unless we manually listen to distributionchangedevent on every content
(which may recursively

[Shadow DOM] Use Cases for Selective Redistributions

2015-04-25 Thread Ryosuke Niwa

Hi,

Could someone give me a concrete use cases for node redistributions where the 
second and subsequent insertion points need to redistribute a subset of nodes 
that have been redistributed to an insertion point in an earlier shadow DOM?  
Maybe someone at Google working on Polymer would have one?

Wasn't this feature was needed in inheritance cases when we had multiple 
generations of shadow DOM (which we just decided to remove from the spec)?

If we don't need to redistribute a subset of nodes (at least for the majority 
of use cases we care about in v1), then we could just not worry about node 
redistributions in our imperative API.  Note that we can redistribute the 
entire content element just fine since a content element can be distributed 
along with its distributed nodes as one piece.

- R. Niwa

Imperative API for Node Distribution in Shadow DOM (Revisited)

2015-04-25 Thread Ryosuke Niwa

Hi all,

https://gist.github.com/rniwa/2f14588926e1a11c65d3
https://gist.github.com/rniwa/2f14588926e1a11c65d3

Imperative API for Node Distribution in Shadow DOM

There are two approaches to the problem depending on whether we want to
natively support redistribution or not.

To recap, a redistribution of a node (N_1) happens when it's distributed to an
insertion point (I_1) inside a shadow root (S_1), and I_1's parent also has a
shadow root which contains an insertion point which ends picking up N_1. e.g.
the original tree may look like:

(host of S_1) - S_1
+ N_1 + (host of S_2) - S_2
+ I_1 + I_2
Here, (host of S_1) has N_1 as a child, and (host of S_2) is a child of S_1 and
has I_1 as a child. S_2 has I_2 as a child. The composed tree, then, may look
like:

(host of S_1)
+ (host of S_2)
+ I_2
+ N_1

https://gist.github.com/rniwa/2f14588926e1a11c65d3#redistribution-is-implemented-by-authorsRedistribution
is implemented by authors

In this model, we can add insertAt and remove on content element and expose
distributedNodes defined as follows:

insertAt(Node nodeToDistribute, long index) - Inserts nodeToDistribute to the
list of the distributed nodes at index. It throws if nodeToDistribute is not a
descendent (or a direct child if wanted to keep this constraint) of the shadow
host of the ancestor shadow root of containt or if index is larger than the
length of distributedNodes.
remove(Node distributedNode) - Remove distributedNode from the list distributed
nodes. Throws if distributedNodes doesn't contain this node.
distributedNodes - Returns an array of nodes that are distributed into this
insertion point in the order they appear.
In addition, content fires a synchrnous distributionchanged event when
distributedNodeschanges (in response to calls to insertAt or remove).

https://gist.github.com/rniwa/2f14588926e1a11c65d3#prosPros

Each component needs to manually implement re-distributions by recursively
traversing through distributedNodes of content elements inside distributedNodes
of the content element if it didn't want to re-distribute everything. This is
particularly challenging because you need to listen to distributionchanged
event on every such content element. We might need something aking to
MutationObserver's subtree option to monitor this if we're going this route.
It seems hard to support re-distribution natively in v2.

https://gist.github.com/rniwa/2f14588926e1a11c65d3#redistribution-is-implemented-by-uasRedistribution
is implemented by UAs

In this model, the browser is responsible for taking care of redistributions.
Namely, we would like to expose distributionPool on the shadow root which
contains the ordered list of nodes that could be distributed (because they're
direct children of the host) or re-distributed. Conceptually, you could think
of it as a depth first traversal of distributedNodes of every content element.
Because this list contains every candidate for (re)distribution, it's
impractical to include every descendent node especially if we wanted to do
synchronous updates so we're back to supporting only direct children for
distribution.

In this proposal, we add a new callback distributeCallback(NodeList
distributionPool) as an arguemnt (probably inside a dictionary) to
createShadowRoot. e.g.

var shadowRoot = element.createShadowRoot({
distributedCallback: function (distributionPool) {
... // code to distribute nodes
}
});
Unfortunately, we can't really use insertAt and remove in model because
distributionPoolmaybe changed under the foot by (outer) insertion points in the
light DOM if this shadow root to attached to a host inside another shadow DOM
unless we manually listen to distributionchangedevent on every content (which
may recursively appear in distributedNodes of those content).

One way to work around this problem is let UA also propagate changes to
distributionPool to each nested shadow DOM. That is, when distributionPool of a
shadow root gets modified due to changes to distributionPools of direct
children (of the shadow host) that are content elements themselves, UA will

Re: Proposal for changes to manage Shadow DOM content distribution

2015-04-25 Thread Ryosuke Niwa


 On Apr 24, 2015, at 2:23 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 
 On Wed, Apr 22, 2015 at 5:04 PM, Ryosuke Niwa rn...@apple.com wrote:
 I find it decidedly relevant given I'm pointing out that attribute-specified
 slots Domenic mentioned isn't what you described.  Since the only venue in
 which attribute-specified slots came up are [1], [2], and [3].  We're
 DEFINITELY NOT interested in filling slots based on values of arbitrary
 attributes.
 
 [1] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0188.html
 [2] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0190.html
 [3] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0195.html
 
 Apologies, I'd misread [1] and didn't realize it really was talking
 about projecting the value of an attribute into the content of a slot.
 
 (Though I'm confused by the vehemence of your denial here, given that
 in [2] you said you could imagine that such a feature could be easily
 added.)

What I meant is that we don't want a declarative syntax to filling a slot based 
with elements based on attribute values of those elements.  I'm less concerned 
about distributing the value of an attribute to a slot based on its attribute 
name.

Regardless, all of this is moot for foreseeable future given we just reached a 
consensus to focus on an imperative API for v1 on today's F2F.

- R. Niwa

Re: Proposal for changes to manage Shadow DOM content distribution

2015-04-22 Thread Ryosuke Niwa


 On Apr 22, 2015, at 3:48 PM, Justin Fagnani justinfagn...@google.com wrote:
 
 On Wed, Apr 22, 2015 at 2:37 PM, Ryosuke Niwa rn...@apple.com 
 mailto:rn...@apple.com wrote:
 
 On Apr 22, 2015, at 10:16 AM, Justin Fagnani justinfagn...@google.com 
 mailto:justinfagn...@google.com wrote:
 
 On Tue, Apr 21, 2015 at 10:40 PM, Ryosuke Niwa rn...@apple.com 
 mailto:rn...@apple.com wrote:
 
  On Apr 21, 2015, at 10:23 PM, Justin Fagnani justinfagn...@google.com 
  mailto:justinfagn...@google.com wrote:
 
  I do want the ability to redirect distributed nodes into a holes in the 
  base template, so that part is welcome to me. However, my first reaction 
  to the slot idea is that forcing users to add the content-slot attribute 
  on children significantly impairs the DOM API surface area of custom 
  elements.
 
  For the single-level distribution case, how is this different from 
  content select=[content-slot=name] except that content select can 
  distribute based on features of the children that might already exist, 
  like tag names or an attribute?
 
 At the conceptual level, they're equivalent.  However, we didn't find the 
 extra flexibility of using CSS selectors compelling as we mentioned in our 
 proposal [1].
 
 I personally would like to see more power, especially positional selectors. 
 Some components would be better off selecting their first child, rather than 
 requiring a class.
 
 What are concrete use cases that require such flexibility?
 
 Require is a strong word :) but the case I recently experienced was a panel 
 with a header. It always expects one child for the header and the rest for 
 content. There are several ways to do this, and one would be to select the 
 first child into one distribution point and the rest into another. Another 
 way is to use attributes, classes or a specific set of tag names. The key for 
 me here is that you give the custom element author a choice on how to shape 
 their API.

I don't think letting authors of each component choose how to select nodes of 
distributions will increase the inconsistencies between components written by 
different authors and deteriorate the ergonomics of component users.

 template
   content select=.header/content
   content select=:not(.footer)/content
   content select=.footer/content
 /template
 
 Our point wasn't so much that it's not achievable.  With enough hackeries and 
 techniques, we can.  The problem is the developer ergonomics of content 
 element with select attribute with common real world use cases.  For example, 
 the above code is a lot more verbose and less intuitive than
 
 template
   content slot=header/content
   content/content
   content slot=footer/content
 /template
 
 This is true, but it's a trade off for custom element authoring brevity vs 
 custom element use brevity (and authoring expressiveness). I'd personally 
 rather optimize for custom element user ergonomics, and give custom element 
 authors the power to make their elements easy and convenient.
 
 Continuing this example I would actually make the selectors more complex 
 because we have these nice semantic elements in html5:
 template
   content select=header, .header/content
   content select=:not(footer, .footer)/content
   content select=footer, .footer/content
 /template
 
  Which is more work for the CE author, but allows this for the user:
 
 my-element
   headerTitle/header
   p.../p
   p.../p
   footer.../footer
 /my-element
That's a fair point but it is a feature that the user of components needs to 
explicitly opt-in to use slot-content.  That explicit contract ensures the API 
surface to be limited.  Suppose in the version 1 of this component, it only 
supported header.  If the version 2 of this component subsequently added the 
support for footer, it's unclear whether every existing use of footer 
element is appropriate for node distribution.  This poses a serious challenge 
for adding new features to your components.  In addition, such an explicit 
contract is a must-have requirement for cross-origin components we (Apple's 
WebKit team) have been advocating for years now.

- R. Niwa

Re: Proposal for changes to manage Shadow DOM content distribution

2015-04-22 Thread Ryosuke Niwa


 On Apr 22, 2015, at 3:54 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 
 On Wed, Apr 22, 2015 at 2:53 PM, Ryosuke Niwa rn...@apple.com wrote:
 On Apr 22, 2015, at 2:38 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa rn...@apple.com wrote:
 On Apr 22, 2015, at 8:52 AM, Domenic Denicola d...@domenic.me wrote:
 Between content-slot-specified slots, attribute-specified slots,
 element-named slots, and everything-else-slots, we're now in a weird place
 where we've reinvented a micro-language with some, but not all, of the 
 power
 of CSS selectors. Is adding a new micro-language to the web platform worth
 helping implementers avoid the complexity of implementing CSS selector
 matching in this context?
 
 I don't think mapping an attribute value to a slot is achievable with a
 content element with select attribute.
 
 content select=[my-attr='the slot value']
 
 No. That's not what I'm talking here.  I'm talking about putting the
 attribute value into the insertion point in [1] [2] [3], not distributing an
 element based on an attribute value.
 
 Oh, interesting.  That appears to be a complete non-sequitur, tho, as
 no one has asked for anything like that.  It's *certainly* irrelevant
 as a response to the text you quoted.

I find it decidedly relevant given I'm pointing out that attribute-specified 
slots Domenic mentioned isn't what you described.  Since the only venue in 
which attribute-specified slots came up are [1], [2], and [3].  We're 
DEFINITELY NOT interested in filling slots based on values of arbitrary 
attributes.

[1] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0188.html 
https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0188.html
[2] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0190.html 
https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0190.html
[3] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0195.html 
https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0195.html

- R. Niwa

Re: Proposal for changes to manage Shadow DOM content distribution

2015-04-22 Thread Ryosuke Niwa


 On Apr 22, 2015, at 8:52 AM, Domenic Denicola d...@domenic.me wrote:
 
 Between content-slot-specified slots, attribute-specified slots, 
 element-named slots, and everything-else-slots, we're now in a weird place 
 where we've reinvented a micro-language with some, but not all, of the power 
 of CSS selectors. Is adding a new micro-language to the web platform worth 
 helping implementers avoid the complexity of implementing CSS selector 
 matching in this context?
 

I don't think mapping an attribute value to a slot is achievable with a content 
element with select attribute.

- R. Niwa

Re: Proposal for changes to manage Shadow DOM content distribution

2015-04-22 Thread Ryosuke Niwa


 On Apr 22, 2015, at 2:38 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 
 On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa rn...@apple.com wrote:
 On Apr 22, 2015, at 8:52 AM, Domenic Denicola d...@domenic.me wrote:
 Between content-slot-specified slots, attribute-specified slots, 
 element-named slots, and everything-else-slots, we're now in a weird place 
 where we've reinvented a micro-language with some, but not all, of the 
 power of CSS selectors. Is adding a new micro-language to the web platform 
 worth helping implementers avoid the complexity of implementing CSS 
 selector matching in this context?
 
 I don't think mapping an attribute value to a slot is achievable with a 
 content element with select attribute.
 
 content select=[my-attr='the slot value']

No. That's not what I'm talking here.  I'm talking about putting the attribute 
value into the insertion point in [1] [2] [3], not distributing an element 
based on an attribute value.

 On Apr 22, 2015, at 2:38 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa rn...@apple.com wrote:
 I don't think defining a slot based on an attribute value is something we'd 
 like to support.
 
 That is *literally* what your proposal already is, except limited to
 only paying attention to the value of the content-slot attribute.


Distributing elements based on the value of a single well scoped attribute 
versus of an arbitrary attribute is A HUGE difference.

[1] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0188.html 
https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0188.html
[2] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0190.html 
https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0190.html
[3] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0195.html

- R. Niwa

Re: Proposal for changes to manage Shadow DOM content distribution

2015-04-22 Thread Ryosuke Niwa

I don't think defining a slot based on an attribute value is something we'd 
like to support.

 On Apr 22, 2015, at 10:21 AM, Justin Fagnani justinfagn...@google.com wrote:
 
 Another technique I've seen used is compound selectors, which could be used 
 to migrate from one selector to another while preserving backwards 
 compatibility, or to provide some nice default distributions that are also 
 accessible via a class or attribute (ie, select=header, .header).
 
 Could slots have multiple names to support something like this?
 
 On Wed, Apr 22, 2015 at 10:16 AM, Justin Fagnani justinfagn...@google.com 
 mailto:justinfagn...@google.com wrote:
 
 
 On Tue, Apr 21, 2015 at 10:40 PM, Ryosuke Niwa rn...@apple.com 
 mailto:rn...@apple.com wrote:
 
  On Apr 21, 2015, at 10:23 PM, Justin Fagnani justinfagn...@google.com 
  mailto:justinfagn...@google.com wrote:
 
  I do want the ability to redirect distributed nodes into a holes in the 
  base template, so that part is welcome to me. However, my first reaction to 
  the slot idea is that forcing users to add the content-slot attribute on 
  children significantly impairs the DOM API surface area of custom elements.
 
  For the single-level distribution case, how is this different from content 
  select=[content-slot=name] except that content select can distribute 
  based on features of the children that might already exist, like tag names 
  or an attribute?
 
 At the conceptual level, they're equivalent.  However, we didn't find the 
 extra flexibility of using CSS selectors compelling as we mentioned in our 
 proposal [1].
 
 I personally would like to see more power, especially positional selectors. 
 Some components would be better off selecting their first child, rather than 
 requiring a class.
 
 [1] See points 3 and 4 in 
 https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution#some-issues-with-the-current-shadow-dom-spec
  
 https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution#some-issues-with-the-current-shadow-dom-spec
 
 Point 4 is interesting, because unless I'm missing something (which could 
 be!) it's incorrect. You can create selectors with :not() that exclude the 
 content selectors that come after in document order. I would rewrite the 
 example as:
 
 template
   content select=.header/content
   content select=:not(.footer)/content
   content select=.footer/content
 /template
 Cheers,
   Justin
  
 
 
 - R. Niwa

Re: Proposal for changes to manage Shadow DOM content distribution

2015-04-22 Thread Ryosuke Niwa

On Apr 22, 2015, at 10:16 AM, Justin Fagnani justinfagn...@google.com wrote:

On Tue, Apr 21, 2015 at 10:40 PM, Ryosuke Niwa rn...@apple.com
mailto:rn...@apple.com wrote:

On Apr 21, 2015, at 10:23 PM, Justin Fagnani justinfagn...@google.com
mailto:justinfagn...@google.com wrote:

I do want the ability to redirect distributed nodes into a holes in the
base template, so that part is welcome to me. However, my first reaction to
the slot idea is that forcing users to add the content-slot attribute on
children significantly impairs the DOM API surface area of custom elements.

For the single-level distribution case, how is this different from content
select=[content-slot=name] except that content select can distribute
based on features of the children that might already exist, like tag names
or an attribute?

At the conceptual level, they're equivalent. However, we didn't find the
extra flexibility of using CSS selectors compelling as we mentioned in our
proposal [1].

I personally would like to see more power, especially positional selectors.
Some components would be better off selecting their first child, rather than
requiring a class.

What are concrete use cases that require such flexibility?

[1] See points 3 and 4 in
https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution#some-issues-with-the-current-shadow-dom-spec

https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution#some-issues-with-the-current-shadow-dom-spec

Point 4 is interesting, because unless I'm missing something (which could
be!) it's incorrect. You can create selectors with :not() that exclude the
content selectors that come after in document order. I would rewrite the
example as:

template
content select=.header/content
content select=:not(.footer)/content
content select=.footer/content
/template
Our point wasn't so much that it's not achievable. With enough hackeries and
techniques, we can. The problem is the developer ergonomics of content
element with select attribute with common real world use cases. For example,
the above code is a lot more verbose and less intuitive than

template
content slot=header/content
content/content
content slot=footer/content
/template
- R. Niwa

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

2015-04-28 Thread Ryosuke Niwa

On Apr 27, 2015, at 4:23 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 On Mon, Apr 27, 2015 at 4:06 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 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...@google.com wrote:
 IMO, the appeal of this proposal is that it's a small change to the 
 current spec and avoids changing user expectations about the state of the 
 dom and can explain the two declarative proposals for distribution.
 
 It seems like with this API, we’d have to make O(n^k) calls where n is 
 the number of distribution candidates and k is the number of insertion 
 points, and that’s bad.  Or am I misunderstanding your design?
 
 I think you've understood the proposed design. As you noted, the cost is 
 actually O(n*k). In our use cases, k is generally very small.
 
 I don't think we want to introduce O(nk) algorithm. Pretty much every 
 browser optimization we implement these days are removing O(n^2) algorithms 
 in the favor of O(n) algorithms. Hard-baking O(nk) behavior is bad because 
 we can't even theoretically optimize it away.
 
 You're aware, obviously, that O(n^2) is a far different beast than
 O(nk).  If k is generally small, which it is, O(nk) is basically just
 O(n) with a constant factor applied.
 
 To make it clear: I'm not trying to troll Ryosuke here.
 
 He argued that we don't want to add new O(n^2) algorithms if we can
 help it, and that we prefer O(n).  (Uncontroversial.)
 
 He then further said that an O(nk) algorithm is sufficiently close to
 O(n^2) that he'd similarly like to avoid it.  I'm trying to
 reiterate/expand on Steve's message here, that the k value in question
 is usually very small, relative to the value of n, so in practice this
 O(nk) is more similar to O(n) than O(n^2), and Ryosuke's aversion to
 new O(n^2) algorithms may be mistargeted here.

Thanks for clarification. Just as Justin pointed out [1], one of the most 
important use case of imperative API is to dynamically insert as many insertion 
points as needed to wrap each distributed node.  In such a use case, this 
algorithm DOES result in O(n^2).

In fact, it could even result in O(n^3) behavior depending on how we spec it.  
If the user code had dynamically inserted insertion points one by one and UA 
invoked this callback function for each insertion point and each node.  If we 
didn't, then author needs a mechanism to let UA know that the condition by 
which insertion points select a node has changed and it needs to re-distribute 
all the nodes again.

- R. Niwa

[1] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0325.html 
https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0325.html

Re: Inheritance Model for Shadow DOM Revisited

2015-04-28 Thread Ryosuke Niwa


 On Apr 27, 2015, at 9:50 PM, Hayato Ito hay...@chromium.org wrote:
 
 The feature of shadow as function supports *subclassing*. That's exactly 
 the motivation I've introduced it once in the spec (and implemented it in 
 blink). I think Jan Miksovsky, co-author of Apple's proposal, knows well that.

We're (and consequently I'm) fully aware of that feature/prosal, and we still 
don't think it adequately addresses the needs of subclassing.

The problem with shadow as function is that the superclass implicitly 
selects nodes based on a CSS selector so unless the nodes a subclass wants to 
insert matches exactly what the author of superclass considered, the subclass 
won't be able to override it. e.g. if the superclass had an insertion point 
with select=input.foo, then it's not possible for a subclass to then override 
it with, for example, an input element wrapped in a span.

 The reason I reverted it from the spec (and the blink), [1], is a technical 
 difficulty to implement, though I've not proved that it's impossible to 
 implement.

I'm not even arguing about the implementation difficulty. I'm saying that the 
semantics is inadequate for subclassing.

- R. Niwa

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

2015-04-28 Thread Ryosuke Niwa

I've updated the gist to reflect the discussion so far:
https://gist.github.com/rniwa/2f14588926e1a11c65d3 
https://gist.github.com/rniwa/2f14588926e1a11c65d3

Please leave a comment if I missed anything.

- R. Niwa

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

2015-04-28 Thread Ryosuke Niwa


 On Apr 28, 2015, at 1:04 PM, Elliott Sprehn espr...@chromium.org wrote:
 
 A distribute callback means running script any time we update distribution, 
 which is inside the style update phase (or event path computation phase, ...) 
 which is not a location we can run script.

That's not what Anne and the rest of us are proposing. That idea only came up 
in Steve's proposal [1] that kept the current timing of distribution.

 I also don't believe we should support distributing any arbitrary descendant, 
 that has a large complexity cost and doesn't feel like simplification. It 
 makes computing style and generating boxes much more complicated.

That certainly is a trade off. See a use case I outlined in [2].

 A synchronous childrenChanged callback has similar issues with when it's safe 
 to run script, we'd have to defer it's execution in a number of situations, 
 and it feels like a duplication of MutationObservers which specifically were 
 designed to operate in batch for better performance and fewer footguns (ex. a 
 naive childrenChanged based distributor will be n^2).

Since the current proposal is to add it as a custom element's lifecycle 
callback (i.e. we invoke it when we cross UA code / user code boundary), this 
shouldn't be an issue. If it is indeed an issue, then we have a problem with a 
lifecycle callback that gets triggered when an attribute value is modified.

In general, I don't think we can address Steve's need to make the consistency 
guarantee [3] without running some script either synchronously or as a 
lifecycle callback in the world of an imperative API.

- R. Niwa

[1] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0342.html
[2] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0344.html
[3] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0357.html

Re: Inheritance Model for Shadow DOM Revisited

2015-04-30 Thread Ryosuke Niwa


 On Apr 29, 2015, at 9:17 PM, Hayato Ito hay...@chromium.org wrote:
 
 Thanks. As far as my understanding is correct, the conclusions so far are:
 
 - There is no use cases which shadow as function can't support, but 
 content slot can support.
 - there are use cases which shadow as function can support, but content 
 slot can't support.

I disagree. What shadow as function provides is an extra syntax by which 
authors can choose elements. That's not a use case. A use case is a solution 
for a concrete user scenario such as building a social network button.

 - shadow as function is more expressive than content slot

Again, I disagree.

 - content slot is trying to achieve something by removing expressiveness 
 from web developers, instead of trusting them.
 
 I still don't understand fully what the proposal is trying to achieve. I've 
 never heard such a complain, content select is too expressive and easy to 
 be misused. Please remove it, from web developers.
 
 I think any good APIs could be potentially wrongly used by a web developer. 
 But that shouldn't be a reason that we can remove a expressive API from web 
 developers who can use it correctly and get benefits from the expressiveness.

Now let me make an analogous comparison between C++ and assembly language.

- There is no use cases which assembly can't support, but C++ can support.
- There are use cases which assembly can support, but C++ can't support.
- Assembly language is more expressive than C++.
- C++ is trying to achieve something by removing expressiveness from 
programmers, instead of trusting them.

Does that mean we should all be coding in assembly? Certainly not.

For a more relevant analogy, one could construct the entire document using 
JavaScript without using HTML at all since DOM API exposed to JavaScript can 
construct the set of trees which is a strict superset of what HTML tree 
building algorithm can generate. Yet, we don't see that happening even in the 
top tier Web apps just because DOM API is more expressive. The vast majority of 
Web apps still use plenty of templates and declarative formats to construct DOM 
for simplicity and clarity even though imperative alternatives are strictly 
more powerful.

Why did we abandon XHTML2.0? It was certainly more expressive. Why not SGML? 
It's a lot more expressive than XML. You can re-define special character as 
you'd like. Because expressiveness is not necessary the most desirable 
characteristics of anything by itself. The shape of a solution we need depends 
on the kind of problems we're solving.

- R. Niwa

Re: Inheritance Model for Shadow DOM Revisited

2015-04-30 Thread Ryosuke Niwa


 On Apr 30, 2015, at 1:47 AM, Hayato Ito hay...@chromium.org wrote:
 
 Thanks, let me update my understanding:
 
 - There is no use cases which shadow as function can't support, but 
 content slot can support.
 - The purpose of the proposal is to remove an *extra* syntax. There is no 
 other goals.
 - There is no reason to consider content slot proposal if we have a use 
 case which this *extra* syntax can achieve.

That's not at all what I'm saying. As far as we (Apple) are concerned, 
shadow as a function as a mere proposal just as much as our content 
slot is a proposal since you've never convinced us that shadow as a 
function is a good solution for shadow DOM inheritance. Both proposals should 
be evaluated based on concrete use cases.

And even if there are use cases for which a given proposal (either shadow as 
a function or named slot) doesn't adequately address, there are multiple 
options to consider:
1. Reject the use case because it's not important
2. Defer the use case for future extensions
3. Modify the proposal as needed
4. Reject the proposal because above options are not viable

 I'm also feeling that several topic are mixed in the proposal, Imperative 
 APIs, Multiple Templates and content slot, which makes me hard to 
 understand the goal of each.
 Can I assume that the proposal is trying to remove content select, not 
 only from such a multiple templates, but also from everywhere?

As I understand the situation, the last F2F's resolution is to remove content 
select entirely. That's not a proposal but rather the tentative consensus of 
the working group. If you'd like, we can initiate a formal CfC process to reach 
a consensus on this matter although I highly doubt the outcome will be 
different given the attendees of the meeting.

- R. Niwa

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

2015-04-27 Thread Ryosuke Niwa


 On Apr 26, 2015, at 6:11 PM, Hayato Ito hay...@chromium.org wrote:
 
 I think Polymer folks will answer the use case of re-distribution.
 
 So let me just show a good analogy so that every one can understand 
 intuitively what re-distribution *means*.
 Let me use a pseudo language and define XComponent's constructor as follows:
 
 XComponents::XComponents(Title text, Icon icon) {
   this.text = text;
   this.button = new XButton(icon);
   ...
 }
 
 Here, |icon| is *re-distributed*.
 
 In HTML world, this corresponds the followings:
 
 The usage of x-component element:
   x-components
 x-textHello World/x-text
 x-iconMy Icon/x-icon
   /x-component
 
 XComponent's shadow tree is:
 
   shadow-root
 h1content select=x-text/content/h1!-- (1) --
 x-buttoncontent select=x-icon/content/x-button!-- (2) --
   /shadow-root

I have a question as to whether x-button then has to select which nodes to use 
or not.  In this particular example at least, x-button will put every node 
distributed into (2) into a single insertion point in its shadow DOM.

If we don't have to support filtering of nodes at re-distribution time, then 
the whole discussion of re-distribution is almost a moot because we can just 
treat a content element like any other element that gets distributed along with 
its distributed nodes.

- R. Niwa

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

2015-04-27 Thread Ryosuke Niwa


 On 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 
 mailto:sorv...@google.com wrote:
 
 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 
 https://gist.github.com/sorvell/e201c25ec39480be66aa
 
 It seems like with this API, we’d have to make O(n^k)

I meant to say O(nk).  Sorry, I'm still waking up :(

 calls where n is the number of distribution candidates and k is the number of 
 insertion points, and that’s bad.  Or am I misunderstanding your design?
 
 
 We keep the currently spec'd distribution algorithm/timing but remove 
 `select` in favor of an explicit selection callback.
 
 What do you mean by keeping the currently spec’ed timing?  We certainly can’t 
 do it at “style resolution time” because style resolution is an 
 implementation detail that we shouldn’t expose to the Web just like GC and 
 its timing is an implementation detail in JS.  Besides that, avoiding style 
 resolution is a very important optimizations and spec’ing when it happens 
 will prevent us from optimizing it away in the future/
 
 Do you mean instead that we synchronously invoke this algorithm when a child 
 node is inserted or removed from the host?  If so, that’ll impose 
 unacceptable runtime cost for DOM mutations.
 
 I think the only timing UA can support by default will be at the end of micro 
 task or at UA-code / user-code boundary as done for custom element lifestyle 
 callbacks at the moment.
 
 The user simply returns true if the node should be distributed to the given 
 insertion point.
 
 Advantages:
  * the callback can be synchronous-ish because it acts only on a specific 
 node when possible. Distribution then won't break existing expectations 
 since `offsetHeight` is always correct.
 
 “always correct” is somewhat stronger statement than I would state here since 
 during UA calls these shouldDistributeToInsertionPoint callbacks, we'll 
 certainly see transient offsetHeight values.
 
 - R. Niwa

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

2015-04-27 Thread Ryosuke Niwa


 On Apr 26, 2015, at 11:05 PM, Anne van Kesteren ann...@annevk.nl wrote:
 
 On Sat, Apr 25, 2015 at 10:49 PM, Ryosuke Niwa rn...@apple.com wrote:
 One major drawback of this API is computing insertionList is expensive
 because we'd have to either (where n is the number of nodes in the shadow
 DOM):
 
 Maintain an ordered list of insertion points, which results in O(n)
 algorithm to run whenever a content element is inserted or removed.
 Lazily compute the ordered list of insertion points when `distribute`
 callback is about to get called in O(n).
 
 The alternative is not exposing it and letting developers get hold of
 the slots. The rationale for letting the browser do it is because you
 need the slots either way and the browser should be able to optimize
 better.

I don’t think that’s true.  If you’re creating a custom element, you’re pretty 
much in the control of what goes into your shadow DOM.  I’m writing any kind of 
component that creates a shadow DOM, I’d just keep references to all my 
insertion points instead of querying them each time I need to distribute nodes.

Another important use case to consider is adding insertion points given the 
list of nodes to distribute.  For example, you may want to “wrap” each node you 
distribute by an element.  That requires the component author to know the 
number of nodes to distribute upfront and then dynamically create as many 
insertion points as needed.

 If we wanted to allow non-direct child descendent (e.g. grand child node) of
 the host to be distributed, then we'd also need O(m) algorithm where m is
 the number of under the host element.  It might be okay to carry on the
 current restraint that only direct child of shadow host can be distributed
 into insertion points but I can't think of a good reason as to why such a
 restriction is desirable.
 
 So you mean that we'd turn distributionList into a subtree? I.e. you
 can pass all descendants of a host element to add()? I remember Yehuda
 making the point that this was desirable to him.

Consider table-chart component which coverts a table element into a chart with 
each column represented as a line graph in the chart. The user of this 
component will wrap a regular table element with table-chart element to 
construct a shadow DOM:

```html
table-chart
  table
...
  td data-value=“253” data-delta=5253 ± 5/td
...
  /table
/table-chart
```

For people who like is attribute on custom elements, pretend it's
```html
  table is=table-chart
...
  td data-value=“253” data-delta=5253 ± 5/td
...
  /table
```

Now, suppose I wanted to show a tooltip with the value in the chart. One 
obvious way to accomplish this would be distributing the td corresponding to 
the currently selected point into the tooltip. But this requires us allowing 
non-direct child nodes to be distributed.


 The other thing I would like to explore is what an API would look like
 that does the subclassing as well. Even though we deferred that to v2
 I got the impression talking to some folks after the meeting that
 there might be more common ground than I thought.

For the slot approach, we can model the act of filling a slot as if attaching a 
shadow root to the slot and the slot content going into the shadow DOM for both 
content distribution and filling of slots by subclasses.

Now we can do this in either of the following two strategies:
1. Superclass wants to see a list of slot contents from subclasses.
2. Each subclass overrides previous distribution done by superclass by 
inspecting insertion points in the shadow DOM and modifying them as needed.

- R. Niwa

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

2015-04-27 Thread Ryosuke Niwa


 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 out if this 
 seems like an interesting api direction:
 
 https://gist.github.com/sorvell/e201c25ec39480be66aa 
 https://gist.github.com/sorvell/e201c25ec39480be66aa

It seems like with this API, we’d have to make O(n^k) calls where n is the 
number of distribution candidates and k is the number of insertion points, and 
that’s bad.  Or am I misunderstanding your design?

 
 We keep the currently spec'd distribution algorithm/timing but remove 
 `select` in favor of an explicit selection callback.

What do you mean by keeping the currently spec’ed timing?  We certainly can’t 
do it at “style resolution time” because style resolution is an implementation 
detail that we shouldn’t expose to the Web just like GC and its timing is an 
implementation detail in JS.  Besides that, avoiding style resolution is a very 
important optimizations and spec’ing when it happens will prevent us from 
optimizing it away in the future/

Do you mean instead that we synchronously invoke this algorithm when a child 
node is inserted or removed from the host?  If so, that’ll impose unacceptable 
runtime cost for DOM mutations.

I think the only timing UA can support by default will be at the end of micro 
task or at UA-code / user-code boundary as done for custom element lifestyle 
callbacks at the moment.

 The user simply returns true if the node should be distributed to the given 
 insertion point.
 
 Advantages:
  * the callback can be synchronous-ish because it acts only on a specific 
 node when possible. Distribution then won't break existing expectations since 
 `offsetHeight` is always correct.

“always correct” is somewhat stronger statement than I would state here since 
during UA calls these shouldDistributeToInsertionPoint callbacks, we'll 
certainly see transient offsetHeight values.

- R. Niwa

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

2015-04-27 Thread Ryosuke Niwa


 On Apr 27, 2015, at 2:38 PM, Hayato Ito hay...@chromium.org wrote:
 
 On Tue, Apr 28, 2015 at 6:18 AM Ryosuke Niwa rn...@apple.com 
 mailto:rn...@apple.com wrote:
 
  On Apr 26, 2015, at 6:11 PM, Hayato Ito hay...@chromium.org 
  mailto:hay...@chromium.org wrote:
 
  I think Polymer folks will answer the use case of re-distribution.
 
  So let me just show a good analogy so that every one can understand 
  intuitively what re-distribution *means*.
  Let me use a pseudo language and define XComponent's constructor as follows:
 
  XComponents::XComponents(Title text, Icon icon) {
this.text = text;
this.button = new XButton(icon);
...
  }
 
  Here, |icon| is *re-distributed*.
 
  In HTML world, this corresponds the followings:
 
  The usage of x-component element:
x-components
  x-textHello World/x-text
  x-iconMy Icon/x-icon
/x-component
 
  XComponent's shadow tree is:
 
shadow-root
  h1content select=x-text/content/h1!-- (1) --
  x-buttoncontent select=x-icon/content/x-button!-- (2) --
/shadow-root
 
 I have a question as to whether x-button then has to select which nodes to 
 use or not.  In this particular example at least, x-button will put every 
 node distributed into (2) into a single insertion point in its shadow DOM.
 
 If we don't have to support filtering of nodes at re-distribution time, then 
 the whole discussion of re-distribution is almost a moot because we can just 
 treat a content element like any other element that gets distributed along 
 with its distributed nodes.
 
 
 x-button can select.
 You might want to take a look at the distribution algorithm [1], where the 
 behavior is well defined.

I know we can in the current spec but should we support it?  What are concrete 
use cases in which x-button or other components need to select nodes in nested 
shadow DOM case?

- R. Niwa

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

2015-04-27 Thread Ryosuke Niwa


 On Apr 27, 2015, at 3:15 PM, Steve Orvell sorv...@google.com wrote:
 
 IMO, the appeal of this proposal is that it's a small change to the current 
 spec and avoids changing user expectations about the state of the dom and can 
 explain the two declarative proposals for distribution.
 
 It seems like with this API, we’d have to make O(n^k) calls where n is the 
 number of distribution candidates and k is the number of insertion points, 
 and that’s bad.  Or am I misunderstanding your design?
 
 I think you've understood the proposed design. As you noted, the cost is 
 actually O(n*k). In our use cases, k is generally very small.

I don't think we want to introduce O(nk) algorithm. Pretty much every browser 
optimization we implement these days are removing O(n^2) algorithms in the 
favor of O(n) algorithms. Hard-baking O(nk) behavior is bad because we can't 
even theoretically optimize it away.

 Do you mean instead that we synchronously invoke this algorithm when a child 
 node is inserted or removed from the host?  If so, that’ll impose 
 unacceptable runtime cost for DOM mutations.
 I think the only timing UA can support by default will be at the end of 
 micro task or at UA-code / user-code boundary as done for custom element 
 lifestyle callbacks at the moment.
 Running this callback at the UA-code/user-code boundary seems like it would 
 be fine. Running the more complicated distribute all the nodes proposals at 
 this time would obviously not be feasible. The notion here is that since 
 we're processing only a single node at a time, this can be done after an 
 atomic dom action.

Indeed, running such an algorithm each time node is inserted or removed will be 
quite expensive.

 “always correct” is somewhat stronger statement than I would state here 
 since during UA calls these shouldDistributeToInsertionPoint callbacks, 
 we'll certainly see transient offsetHeight values.
 
 Yes, you're right about that. Specifically it would be bad to try to read 
 `offsetHeight` in this callback and this would be an anti-pattern. If that's 
 not good enough, perhaps we can explore actually not working directly with 
 the node but instead the subset of information necessary to be able to decide 
 on distribution.

I'm not necessarily saying that it's not good enough.  I'm just saying that it 
is possible to observe such a state even with this API.

 Can you explain, under the initial proposal, how a user can ask an element's 
 dimensions and get the post-distribution answer? With current dom api's I can 
 be sure that if I do parent.appendChild(child) and then parent.offsetWidth, 
 the answer takes child into account. I'm looking to understand how we don't 
 violate this expectation when parent distributes. Or if we violate this 
 expectation, what is the proposed right way to ask this question?

You don't get that guarantee in the design we discussed on Friday [1] [2]. In 
fact, we basically deferred the timing issue to other APIs that observe DOM 
changes, namely mutation observers and custom elements lifecycle callbacks. 
Each component uses those APIs to call distribute().

 In addition to rendering information about a node, distribution also effects 
 the flow of events. So a similar question: when is it safe to call 
 child.dispatchEvent such that if parent distributes elements to its 
 shadowRoot, elements in the shadowRoot will see the event?

Again, the timing was deferred in [1] and [2] so it really depends on when each 
component decides to distribute.

- R. Niwa

[1] https://gist.github.com/rniwa/2f14588926e1a11c65d3
[2] https://gist.github.com/annevk/e9e61801fcfb251389ef

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

2015-04-27 Thread Ryosuke Niwa


 On Apr 27, 2015, at 4:41 PM, Steve Orvell sorv...@google.com wrote:
 
 Again, the timing was deferred in [1] and [2] so it really depends on when 
 each component decides to distribute.
 
 I want to be able to create an element x-foo that acts like other dom 
 elements. This element uses Shadow DOM and distribution to encapsulate its 
 details.
 
 Let's imagine a 3rd party user named Bob that uses div and x-foo. Bob 
 knows he can call div.appendChild(element) and then immediately ask 
 div.offsetHeight and know that this height includes whatever the added 
 element should contribute to the div's height. Bob expects to be able to do 
 this with the x-foo element also since 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?

In order to support this use case, the author of x-foo must use some mechanism 
to observe changes to x-foo's child nodes and involve `distribute` 
synchronously.  This will become possible, for example, if we added 
childrenChanged lifecycle callback to custom elements.

That might be an acceptable mode of operations. If you wanted to synchronously 
update your insertion points, rely on custom element's lifecycle callbacks and 
you can only support direct children for distribution. Alternatively, if you 
wanted to support to distribute a non-direct-child descendent, just use 
mutation observers to do it at the end of a micro task.

- R. Niwa

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

2015-04-27 Thread Ryosuke Niwa


 On Apr 27, 2015, at 3:31 PM, Hayato Ito hay...@chromium.org wrote:
 
 I think there are a lot of user operations where distribution must be updated 
 before returning the meaningful result synchronously.
 Unless distribution result is correctly updated, users would take the dirty 
 result.

Indeed.

 For example:
 - element.offsetWidth:  Style resolution requires distribution. We must 
 update distribution, if it's dirty, before calculation offsetWidth 
 synchronously.
 - event dispatching: event path requires distribution because it needs a 
 composed tree.
 
 Can the current HTML/DOM specs are rich enough to explain the timing when the 
 imperative APIs should be run in these cases?

It certainly doesn't tell us when style resolution happens. In the case of 
event dispatching, it's impossible even in theory unless we somehow disallow 
event dispatching within our `distribute` callbacks since we can dispatch new 
events within the callbacks to decide to where a given node gets distributed. 
Given that, I don't think we should even try to make such a guarantee.

We could, however, make a slightly weaker guarantee that some level of 
conditions for the user code outside of `distribute` callbacks. For example, I 
can think of three levels (weakest to strongest) of self-consistent invariants:
1. every node is distributed to at most one insertion point.
2. all first-order distributions is up-to-date (redistribution may happen 
later).
3. all distributions is up-to-date.

 For me, the imperative APIs for distribution sounds very similar to the 
 imperative APIs for style resolution. The difficulties of both problems might 
 be similar.

We certainly don't want to (in fact, we'll object to) spec the timing for style 
resolution or what even style resolution means.

- R. Niwa

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

2015-04-27 Thread Ryosuke Niwa


 On Apr 27, 2015, at 5:43 PM, Steve Orvell sorv...@google.com wrote:
 
 That might be an acceptable mode of operations. If you wanted to 
 synchronously update your insertion points, rely on custom element's 
 lifecycle callbacks and you can only support direct children for 
 distribution. 
 
 That's interesting, thanks for working through it. Given a `childrenChanged` 
 callback, I think your first proposal `content.insertAt` and 
 `content.remove` best supports a synchronous mental model. As you note, 
 re-distribution is then the element author's responsibility. This would be 
 done by listening to the synchronous `distributionChanged` event. That seems 
 straightforward.
 
 Mutations that are not captured in childrenChanged that can affect 
 distribution would still be a problem, however. Given:
 
 div id=host
   div id=child/div
 /div
 
 child.setAttribute('slot', 'a');
 host.offsetHeight;
 
 Again, we are guaranteed that parent's offsetHeight includes any contribution 
 that adding the slot attribute caused (e.g. via a #child[slot=a] rule)
 
 If the `host` is a custom element that uses distribution, would it be 
 possible to have this same guarantee?
 
 x-foo id=host
   div id=child/div
 /x-foo
 
 child.setAttribute('slot', 'a');
 host.offsetHeight;

That's a good point. Perhaps we need to make childrenChanged optionally get 
called when attributes of child nodes are changed just like the way you can 
configure mutation observers to optionally monitor attribute changes.

- R. Niwa

Inheritance Model for Shadow DOM Revisited

2015-04-27 Thread Ryosuke Niwa

Note: Our current consensus is to defer this until v2.

On Apr 27, 2015, at 9:09 PM, Hayato Ito hay...@chromium.org wrote:

For the record, I, as a spec editor, still think Shadow Root hosts yet
another Shadow Root is the best idea among all ideas I've ever seen, with a
shadow as function, because it can explain everything in a unified way
using a single tree of trees, without bringing yet another complexity such as
multiple templates.

Please see
https://github.com/w3c/webcomponents/wiki/Multiple-Shadow-Roots-as-%22a-Shadow-Root-hosts-another-Shadow-Root%22

That's a great mental model for multiple generations of shadow DOM but it
doesn't solve any of the problems with API itself. Like I've repeatedly stated
in the past, the problem is the order of transclusion. Quoting from [1],

The `shadow` element is optimized for wrapping a base class, not filling it
in. In practice, no subclass ever wants to wrap their base class with
additional user interface elements. A subclass is a specialization of a base
class, and specialization of UI generally means adding specialized elements in
the middle of a component, not wrapping new elements outside some inherited
core.

In the three component libraries [1] described above, the only cases where a
subclass uses `shadow` is if the subclass wants to add additional styling.
That is, a subclass wants to override base class styling, and can do so via:

```
template
stylesubclass styles go here/style
shadow/shadow
/template
```

One rare exception is `core-menu` [3], which does add some components in a
wrapper around a `shadow`. However, even in that case, the components in
question are instances of `core-a11y-keys`, a component which defines
keyboard shortcuts. That is, the component is not using this wrapper ability to
add visible user interface elements, so the general point stands.

As with the above point, the fact that no practical component has need for this
ability to wrap an older shadow tree suggests the design is solving a problem
that does not, in fact, exist in practice.

[1]
https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution
[2] Polymer’s core- elements, Polymer’s paper- elements, and the Basic Web
Components’ collection of basic- elements
[3]
https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2FPolymer%2Fcore-menu%2Fblob%2Fmaster%2Fcore-menu.htmlsa=Dsntz=1usg=AFQjCNH0Rv14ENbplb6VYWFh8CsfVo9m_A

- R. Niwa

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

2015-04-27 Thread Ryosuke Niwa


 On Apr 27, 2015, at 7:32 PM, Steve Orvell sorv...@google.com wrote:
 
 Perhaps we need to make childrenChanged optionally get called when 
 attributes of child nodes are changed just like the way you can configure 
 mutation observers to optionally monitor attribute changes.
 
 Wow, let me summarize if I can. Let's say we have (a) a custom elements 
 synchronous callback `childrenChanged` that can see child adds/removes and 
 child attribute mutations, (b) the first option in the proposed api here 
 https://gist.github.com/rniwa/2f14588926e1a11c65d3, (c) user element code 
 that wires everything together correctly. Then, unless I am mistaken, we have 
 enough power to implement something like the currently spec'd declarative 
 `select` mechanism or the proposed `slot` mechanism without any change to 
 user's expectations about when information in the dom can be queried.

Right. The sticking point is that it's like re-introducing mutation events all 
over again if we don't do it carefully.

 Do the implementors think all of that is feasible?

I think something alone this line should be feasible to implement but the 
performance impact of firing so many events may warrant going back to 
micro-task timing and think of an alternative solution for the consistency.

 Possible corner case: If a content is added to a shadowRoot, this should 
 probably invalidate the distribution and redo everything. To maintain a 
 synchronous mental model, the content mutation in the shadowRoot subtree 
 needs to be seen synchronously. This is not possible with the tools mentioned 
 above, but it seems like a reasonable requirement that the shadowRoot author 
 can be aware of this change since the author is causing it to happen.

Alternatively, an insertion point could start empty, and the author could move 
stuff into it after running. We can also add `removeAll` on HTMLContentElement 
or 'resetDistribution' on ShadowRoot to remove all distributed nodes from a 
given insertion point or all insertion points associated with a shadow root.

- R. Niwa

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

2015-04-27 Thread Ryosuke Niwa


 On Apr 27, 2015, at 12:25 AM, Justin Fagnani justinfagn...@google.com wrote:
 
 On Sun, Apr 26, 2015 at 11:05 PM, Anne van Kesteren ann...@annevk.nl wrote:
 On Sat, Apr 25, 2015 at 10:49 PM, Ryosuke Niwa rn...@apple.com wrote:
  If we wanted to allow non-direct child descendent (e.g. grand child node) 
  of
  the host to be distributed, then we'd also need O(m) algorithm where m is
  the number of under the host element.  It might be okay to carry on the
  current restraint that only direct child of shadow host can be distributed
  into insertion points but I can't think of a good reason as to why such a
  restriction is desirable.
 
 The main reason is that you know that only a direct parent of a node can 
 distribute it. Otherwise any ancestor could distribute a node, and in 
 addition to probably being confusing and fragile, you have to define who wins 
 when multiple ancestors try to.
 
 There are cases where you really want to group element logically by one tree 
 structure and visually by another, like tabs. I think an alternative approach 
 to distributing arbitrary descendants would be to see if nodes can cooperate 
 on distribution so that a node could pass its direct children to another 
 node's insertion point. The direct child restriction would still be there, so 
 you always know who's responsible, but you can get the same effect as 
 distributing descendants for a cooperating sets of elements.

That's an interesting approach. Ted and I discussed this design, and it seems 
workable with Anne's `distribute` callback approach (= the second approach in 
my proposal).

Conceptually, we ask each child of a shadow host the list of distributable node 
for under that child (including itself). For normal node without a shadow root, 
it'll simply itself along with all the distribution candidates returned by its 
children. For a node with a shadow root, we ask its implementation. The 
recursive algorithm can be written as follows in pseudo code:

```
NodeList distributionList(Node n):
  if n has shadowRoot:
return ask n the list of distributable noes under n (1)
  else:
list = [n]
for each child in n:
  list += distributionList(n)
return list
```

Now, if we adopted `distribute` callback approach, one obvious mechanism to do 
(1) is to call `distribute` on n and return whatever it didn't distribute as a 
list. Another obvious approach is to simply return [n] to avoid the mess of n 
later deciding to distribute a new node.

 So you mean that we'd turn distributionList into a subtree? I.e. you
 can pass all descendants of a host element to add()? I remember Yehuda
 making the point that this was desirable to him.
 
 The other thing I would like to explore is what an API would look like
 that does the subclassing as well. Even though we deferred that to v2
 I got the impression talking to some folks after the meeting that
 there might be more common ground than I thought.
 
 I really don't think the platform needs to do anything to support subclassing 
 since it can be done so easily at the library level now that multiple 
 generations of shadow roots are gone. As long as a subclass and base class 
 can cooperate to produce a single shadow root with insertion points, the 
 platform doesn't need to know how they did it.

I think we should eventually add native declarative inheritance support for all 
of this.

One thing that worries me about the `distribute` callback approach (a.k.a. 
Anne's approach) is that it bakes distribution algorithm into the platform 
without us having thoroughly studied how subclassing will be done upfront.

Mozilla tried to solve this problem with XBS, and they seem to think what they 
have isn't really great. Google has spent multiple years working on this 
problem but they come around to say their solution, multiple generations of 
shadow DOM, may not be as great as they thought it would be. Given that, I'm 
quite terrified of making the same mistake in spec'ing how distribution works 
and later regretting it.

In that regard, the first approach w/o distribution has an advantage of letting 
Web developer experiment with the bare minimum and try out which distribution 
algorithms and mechanisms work best.

- R. Niwa

Re: Why is querySelector much slower?

2015-04-27 Thread Ryosuke Niwa


 On Apr 27, 2015, at 7:04 PM, Jonas Sicking jo...@sicking.cc wrote:
 
 On Mon, Apr 27, 2015 at 1:57 AM, Glen Huang curvedm...@gmail.com wrote:
 Intuitively, querySelector('.class') only needs to find the first matching
 node, whereas getElementsByClassName('.class')[0] needs to find all matching
 nodes and then return the first. The former should be a lot quicker than the
 latter. Why that's not the case?
 
 I can't speak for other browsers, but Gecko-based browsers only search
 the DOM until the first hit for getElementsByClassName('class')[0].
 I'm not sure why you say that it must scan for all hits.

WebKit (and, AFAIK, Blink) has the same optimization. It's a very important 
optimization.

- R. Niwa

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

2015-04-30 Thread Ryosuke Niwa


 On Apr 30, 2015, at 5:12 AM, Anne van Kesteren ann...@annevk.nl wrote:
 
 On Mon, Apr 27, 2015 at 11:05 PM, Ryosuke Niwa rn...@apple.com wrote:
 The other thing I would like to explore is what an API would look like
 that does the subclassing as well.
 
 For the slot approach, we can model the act of filling a slot as if 
 attaching a shadow root to the slot and the slot content going into the 
 shadow DOM for both content distribution and filling of slots by subclasses.
 
 Now we can do this in either of the following two strategies:
 1. Superclass wants to see a list of slot contents from subclasses.
 2. Each subclass overrides previous distribution done by superclass by 
 inspecting insertion points in the shadow DOM and modifying them as needed.
 
 With the existence of closed shadow trees, it seems like you'd want to
 allow for the superclass to not have to share its details with the
 subclass.

Neither approach needs to expose internals of superclass' shadow DOM.  In 1, 
what superclass seems is a list of proxies of slot contents subclasses 
provided.  In 2, what subclass sees is a list of wrappers of overridable 
insertion points superclass defined.

I can't think of an inheritance model in any programming language in which 
overridable pieces are unknown to subclasses.

- R. Niwa

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

2015-04-30 Thread Ryosuke Niwa


 On Apr 30, 2015, at 5:12 AM, Anne van Kesteren ann...@annevk.nl wrote:
 
 On Mon, Apr 27, 2015 at 11:05 PM, Ryosuke Niwa rn...@apple.com wrote:
 I’m writing any kind of component that creates a shadow DOM, I’d just keep 
 references to all my insertion points instead of querying them each time I 
 need to distribute nodes.
 
 I guess that is true if you know you're not going to modify your
 insertion points or shadow tree. I would be happy to update the gist
 to exclude this parameter and instead use something like
 
  shadow.querySelector(content)
 
 somewhere. It doesn't seem important.

FYI, I've summarized everything we've discussed so far in 
https://gist.github.com/rniwa/2f14588926e1a11c65d3.

- R. Niwa

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

2015-04-30 Thread Ryosuke Niwa


 On Apr 30, 2015, at 6:00 AM, Domenic Denicola d...@domenic.me wrote:
 
 This essentially forces distribution to happen since you can observe the 
 result of distribution this way. Same with element.offsetWidth etc. And 
 that's not necessarily problematic,
 
 OK. So the claim that the current spec cannot be interoperably implemented is 
 false? (Not that I am a huge fan of content select, but I want to make sure 
 we have our arguments against it lined up and on solid footing.)
 
 but it is problematic if you want to do an imperative API as I tried to 
 explain in the bit you did not quote back.
 
 Sure, let's dig in to that claim now. Again, this is mostly clarifying 
 probing.
 
 Let's say we had an imperative API. As far as I understand from the gist, one 
 of the problems is when do we invoke the distributedCallback. If we use 
 MutationObserve time, then inconsistent states can be observed, etc.
 
 Why can't we say that this distributedCallback must be invoked at the same 
 time that the current spec updates the distribution result? Since it sounds 
 like there is no interop problem with this timing, I don't understand why 
 this wouldn't be an option.

There will be an interop problem. Consider a following example:

```js
someNode = ~
myButton.appendChild(someNode); // (1)
absolutelyPositionElement.offsetTop; // (2)
```

Now suppose absolutelyPositionElement.offsetTop is a some element that's in a 
disjoint subtree of the document. Heck, it could even in a separate iframe. In 
some UAs, (2) will trigger style resolution and update of the layout. Because 
UAs can't tell redistribution of myButton can affect (2), such UAs will update 
the distribution per spec text that says the distribution result must be 
updated before any _use_ of the distribution result.

Yet in other UAs, `offsetTop` may have been cached and UA might be smart enough 
to detect that (1) doesn't affect the result of 
`absolutelyPositionElement.offsetTop` because they're in a different parts of 
the tree and they're independent for the purpose of style resolution and 
layout. In such UAs, (2) does not trigger redistribution because it does not 
use the distribution result in order to compute this value.

In general, there are thousands of other DOM and CSS OM APIs that may or may 
not _use_ the distribution result depending on implementations.

- R. Niwa

Re: Inheritance Model for Shadow DOM Revisited

2015-04-30 Thread Ryosuke Niwa


 On Apr 30, 2015, at 4:43 AM, Anne van Kesteren ann...@annevk.nl wrote:
 
 On Tue, Apr 28, 2015 at 7:09 PM, Ryosuke Niwa rn...@apple.com wrote:
 The problem with shadow as function is that the superclass implicitly 
 selects nodes based on a CSS selector so unless the nodes a subclass wants 
 to insert matches exactly what the author of superclass considered, the 
 subclass won't be able to override it. e.g. if the superclass had an 
 insertion point with select=input.foo, then it's not possible for a 
 subclass to then override it with, for example, an input element wrapped in 
 a span.
 
 So what if we flipped this as well and came up with an imperative API
 for shadow as a function. I.e. shadow as an actual function?
 Would that give us agreement?

We object on the basis that shadow as a function is fundamentally backwards 
way of doing the inheritance.  If you have a MyMapView and define a subclass 
MyScrollableMapView to make it scrollable, then MyScrollableMapView must be a 
MyMapView.  It doesn't make any sense for MyScrollableMapView, for example, to 
be a ScrollView that then contains MyMapView.  That's has-a relationship which 
is appropriate for composition.

- R. Niwa

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

2015-04-30 Thread Ryosuke Niwa


 On Apr 30, 2015, at 9:25 PM, Elliott Sprehn espr...@chromium.org wrote:
 
 On Thu, Apr 30, 2015 at 8:57 PM, Ryosuke Niwa rn...@apple.com wrote:
 ...
 
  The return value of (2) is the same in either case. There is no observable 
  difference. No interop issue.
 
  Please file a bug for the spec with a concrete example if you can find a 
  observable difference due to the lazy-evaluation of the distribution.
 
 The problem isn't so much that the current shadow DOM specification has an 
 interop issue because what we're talking here, as the thread title clearly 
 communicates, is the imperative API for node distribution, which doesn't 
 exist in the current specification.
 
 In particular, invoking user code at the timing specified in section 3.4 
 which states if any condition which affects the distribution result 
 changes, the distribution result must be updated before any use of the 
 distribution result introduces a new interoperability issue because before 
 any use of the distribution result is implementation dependent.  e.g. 
 element.offsetTop may or not may use the distribution result depending on 
 UA.  Furthermore, it's undesirable to precisely spec this since doing so 
 will impose a serious limitation on what UAs could optimize in the future.
 
 
 element.offsetTop must use the distribution result, there's no way to know 
 what your style is without computing your distribution. This isn't any 
 different than getComputedStyle(...).color needing to flush style, or 
 getBoundingClientRect() needing to flush layout.

That is true only if the distribution of a given node can affect the style of 
element. There are cases in which UAs can deduce that such is not the case and 
optimize the style recalculation away. e.g. two elements belonging two 
different documents.

Another example will be element.isContentEditable. Under certain circumstances 
WebKit needs to resolve styles in order to determine the value of this function 
which, then, uses the distribution result.

 Distribution is about computing who your parent and siblings are in the box 
 tree, and where your should inherit your style from. Doing it lazy is not 
 going to be any worse in terms of interop than defining new properties that 
 depend on style.

The problem is that different engines have different mechanism to deduce style 
dependencies between elements.

- R. Niwa

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

2015-04-30 Thread Ryosuke Niwa


 On Apr 30, 2015, at 9:01 PM, Hayato Ito hay...@chromium.org wrote:
 
 Thanks, however, we're talking about 
 https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0442.html.

Ah, I think there was some miscommunication there. I don't think anyone is 
claiming that the current spec results in interop issues. The currently spec'ed 
timing is only problematic when we try to invoke an author-defined callback at 
that moment. If we never added an imperative API or an imperative API we add 
don't invoke user code at the currently spec'ed timing, we don't have any 
interop problem.

- R. Niwa

Re: Inheritance Model for Shadow DOM Revisited

2015-04-30 Thread Ryosuke Niwa


 On Apr 30, 2015, at 2:44 PM, Ryosuke Niwa rn...@apple.com wrote:
 
 
 On Apr 30, 2015, at 2:29 PM, Brian Kardell bkard...@gmail.com wrote:
 
 On Thu, Apr 30, 2015 at 2:00 PM, Ryosuke Niwa rn...@apple.com wrote:
 
 On Apr 30, 2015, at 4:43 AM, Anne van Kesteren ann...@annevk.nl wrote:
 
 On Tue, Apr 28, 2015 at 7:09 PM, Ryosuke Niwa rn...@apple.com wrote:
 The problem with shadow as function is that the superclass implicitly 
 selects nodes based on a CSS selector so unless the nodes a subclass 
 wants to insert matches exactly what the author of superclass considered, 
 the subclass won't be able to override it. e.g. if the superclass had an 
 insertion point with select=input.foo, then it's not possible for a 
 subclass to then override it with, for example, an input element wrapped 
 in a span.
 
 So what if we flipped this as well and came up with an imperative API
 for shadow as a function. I.e. shadow as an actual function?
 Would that give us agreement?
 
 We object on the basis that shadow as a function is fundamentally 
 backwards way of doing the inheritance.  If you have a MyMapView and define 
 a subclass MyScrollableMapView to make it scrollable, then 
 MyScrollableMapView must be a MyMapView.  It doesn't make any sense for 
 MyScrollableMapView, for example, to be a ScrollView that then contains 
 MyMapView.  That's has-a relationship which is appropriate for composition.
 
 
 Is there really a hard need for inheritance over composition? Won't
 composition ability + an imperative API that allows you to properly
 delegate to the stuff you contain be just fine for a v1?
 
 Per resolutions in F2F last Friday, this is a discussion for v2 since we're 
 definitely not adding multiple generations of shadow DOM in v1.
 
 However, we should have a sound plan for inheritance in v2 and make sure our 
 imperative API is forward compatible with it. So the goal here is to come up 
 with some plan for inheritance so that we can be confident that our 
 inheritance API is not completely busted.

Sorry, I meant to say our *imperative* API is not completely busted.

- R. Niwa

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

2015-04-30 Thread Ryosuke Niwa

On Apr 30, 2015, at 8:17 PM, Hayato Ito hay...@chromium.org wrote:
 On Fri, May 1, 2015 at 2:59 AM Ryosuke Niwa rn...@apple.com wrote:
 
  On Apr 30, 2015, at 6:00 AM, Domenic Denicola d...@domenic.me wrote:
 
  This essentially forces distribution to happen since you can observe the 
  result of distribution this way. Same with element.offsetWidth etc. And 
  that's not necessarily problematic,
 
  OK. So the claim that the current spec cannot be interoperably implemented 
  is false? (Not that I am a huge fan of content select, but I want to 
  make sure we have our arguments against it lined up and on solid footing.)
 
  but it is problematic if you want to do an imperative API as I tried to 
  explain in the bit you did not quote back.
 
  Sure, let's dig in to that claim now. Again, this is mostly clarifying 
  probing.
 
  Let's say we had an imperative API. As far as I understand from the gist, 
  one of the problems is when do we invoke the distributedCallback. If we 
  use MutationObserve time, then inconsistent states can be observed, etc.
 
  Why can't we say that this distributedCallback must be invoked at the same 
  time that the current spec updates the distribution result? Since it 
  sounds like there is no interop problem with this timing, I don't 
  understand why this wouldn't be an option.
 
 There will be an interop problem. Consider a following example:
 
 
 The return value of (2) is the same in either case. There is no observable 
 difference. No interop issue.
 
 Please file a bug for the spec with a concrete example if you can find a 
 observable difference due to the lazy-evaluation of the distribution.

The problem isn't so much that the current shadow DOM specification has an 
interop issue because what we're talking here, as the thread title clearly 
communicates, is the imperative API for node distribution, which doesn't exist 
in the current specification.

In particular, invoking user code at the timing specified in section 3.4 which 
states if any condition which affects the distribution result changes, the 
distribution result must be updated before any use of the distribution result 
introduces a new interoperability issue because before any use of the 
distribution result is implementation dependent.  e.g. element.offsetTop may 
or not may use the distribution result depending on UA.  Furthermore, it's 
undesirable to precisely spec this since doing so will impose a serious 
limitation on what UAs could optimize in the future.

- R. Niwa

Re: Inheritance Model for Shadow DOM Revisited

2015-04-30 Thread Ryosuke Niwa


 On Apr 30, 2015, at 4:43 AM, Anne van Kesteren ann...@annevk.nl wrote:
 
 On Tue, Apr 28, 2015 at 7:09 PM, Ryosuke Niwa rn...@apple.com wrote:
 The problem with shadow as function is that the superclass implicitly 
 selects nodes based on a CSS selector so unless the nodes a subclass wants 
 to insert matches exactly what the author of superclass considered, the 
 subclass won't be able to override it. e.g. if the superclass had an 
 insertion point with select=input.foo, then it's not possible for a 
 subclass to then override it with, for example, an input element wrapped in 
 a span.
 
 So what if we flipped this as well and came up with an imperative API
 for shadow as a function. I.e. shadow as an actual function?

To start off, I can think of three major ways by which subclass wants to 
interact with its superclass:
1. Replace what superclass shows entirely by its own content - e.g. grab the 
device context and draw everything by yourself.
2. Override parts of superclass' content - e.g. subclass overrides virtual 
functions superclass provided to draw parts of the component/view.
3. Fill holes superclass provided - e.g. subclass implements abstract virtual 
functions superclass defined to delegate the work.

- R. Niwa

Re: Inheritance Model for Shadow DOM Revisited

2015-05-01 Thread Ryosuke Niwa


 On May 1, 2015, at 1:04 AM, Anne van Kesteren ann...@annevk.nl wrote:
 
 On Thu, Apr 30, 2015 at 11:35 PM, Ryosuke Niwa rn...@apple.com wrote:
 To start off, I can think of three major ways by which subclass wants to 
 interact with its superclass:
 1. Replace what superclass shows entirely by its own content - e.g. grab the 
 device context and draw everything by yourself.
 
 So this requires either replacing or removing superclass' ShadowRoot.
 
 2. Override parts of superclass' content - e.g. subclass overrides virtual 
 functions superclass provided to draw parts of the component/view.
 
 This is where you directly access superclass' ShadowRoot I assume and
 modify things?

In the named slot approach, these overridable parts will be exposed to 
subclasses as an overridable slot. In terms of an imperative API, it means that 
the superclass has a virtual method (probably with a symbol name) that can get 
overridden by a subclass. The default implementation of such a virtual method 
does nothing, and shows the fallback contents of the slot.

 3. Fill holes superclass provided - e.g. subclass implements abstract 
 virtual functions superclass defined to delegate the work.
 
 This is the part that looks like it might interact with distribution, no?

With the named slot approach, we can also model this is an abstract method on 
the superclass that a subclass must implement. The superclass' shadow DOM 
construction code then calls this function to fill the slot.

- R. Niwa

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

2015-04-29 Thread Ryosuke Niwa


 On Apr 29, 2015, at 4:37 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 
 On Wed, Apr 29, 2015 at 4:15 PM, Dimitri Glazkov dglaz...@google.com wrote:
 On Mon, Apr 27, 2015 at 8:48 PM, Ryosuke Niwa rn...@apple.com wrote:
 One thing that worries me about the `distribute` callback approach (a.k.a.
 Anne's approach) is that it bakes distribution algorithm into the platform
 without us having thoroughly studied how subclassing will be done upfront.
 
 Mozilla tried to solve this problem with XBS, and they seem to think what
 they have isn't really great. Google has spent multiple years working on
 this problem but they come around to say their solution, multiple
 generations of shadow DOM, may not be as great as they thought it would be.
 Given that, I'm quite terrified of making the same mistake in spec'ing how
 distribution works and later regretting it.
 
 At least the way I understand it, multiple shadow roots per element and
 distributions are largely orthogonal bits of machinery that solve largely
 orthogonal problems.
 
 Yes.  Distribution is mainly about making composition of components
 work seamlessly, so you can easily pass elements from your light dom
 into some components you're using inside your shadow dom.  Without
 distribution, you're stuck with either:

As I clarified my point in another email, neither I nor anyone else is 
questioning the value of the first-degree of node distribution from the light 
DOM into insertion points of a shadow DOM.  What I'm questioning is the value 
of the capability to selectively re-distribute those nodes in a tree with 
nested shadow DOMs.

 * components have to be explicitly written with the expectation of
 being composed into other components, writing their own content
 select *to target the content elements of the outer shadow*, which
 is also extremely terribad.

Could you give me a concrete use case in which such inspection of content 
elements in the light DOM is required without multiple generations of shadow 
DOM?  In all the use cases I've studied without multiple generations of shadow 
DOM, none required the ability to filter nodes inside a content element.

 Distribution makes composition *work*, in a fundamental way.  Without it, you 
 simply don't have the ability to use components inside of components except 
 in special cases.

Could you give us a concrete example in which selective re-distribution of 
nodes are required? That'll settle this discussion/question altogether.

- R. Niwa

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

2015-04-29 Thread Ryosuke Niwa


 On Apr 29, 2015, at 4:16 PM, Dimitri Glazkov dglaz...@google.com wrote:
 
 On Tue, Apr 28, 2015 at 1:52 PM, Ryosuke Niwa rn...@apple.com wrote:
 I've updated the gist to reflect the discussion so far:
 https://gist.github.com/rniwa/2f14588926e1a11c65d3
 
 Please leave a comment if I missed anything.
 
 Thank you for doing this. There are a couple of unescaped tags in 
 https://gist.github.com/rniwa/2f14588926e1a11c65d3#extention-to-custom-elements-for-consistency,
  I think?
 
 Any chance you could move it to the Web Components wiki? That way, we could 
 all collaborate.

Sure, what's the preferred work flow? Fork and push a PR?

- R. Niwa.

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

2015-04-29 Thread Ryosuke Niwa


 On Apr 29, 2015, at 5:12 PM, Justin Fagnani justinfagn...@google.com wrote:
 
 Here's one case of redistribution: 
 https://github.com/Polymer/core-scaffold/blob/master/core-scaffold.html#L122
 
 Any time you see content inside a custom element it's potentially 
 redistribution. Here there's on that is (line 122), and one that could be 
 (line 116), and one that definitely isn't (line 106).

Thank you very much for an example. I'm assuming core-header-panel is [1]? It 
grabs core-toolbar. It looks to me that we could also replace line 122 with:

```html
content class=.core-header select=core-toolbar, .core-header/content
content select=*/content
```

and you wouldn't need redistribution. I wouldn't argue that it provides a 
better developer ergonomics but there's a serious trade off here.

If we natively supported redistribution and always triggered via `distribute` 
callback, then it may not be acceptable to invoke `distribute` on every DOM 
change in terms of performance since that could easily result in O(n^2) 
behavior. This is why the proposal we (Anne, I, and others) discussed involved 
using mutation observers instead of childrenChanged lifecycle callbacks.

Now, frameworks such as Polymer could provide a sugar on top of it by 
automatically re-distributing nodes as needed when implementing your select 
attribute.

 I personally think that Hayato's analogy to function parameters is very 
 motivating. Arguing from use-cases at this point is going to miss many things 
 because so far we've focused on the most simple of components, are having to 
 rewrite them for Polymer 0.8, and haven't seen the variety and complexity of 
 cases that will evolve naturally from the community. General expressiveness 
 is extremely important when you don't have an option to work around it - 
 redistribution is one of these cases.

Evaluating each design proposal based on a concrete use case is extremely 
important precisely because we might miss out on expressiveness in some cases 
as we're stripping down features, and we can't reject a proposal or add a 
feature for a hypothetical/theoretical need.

[1] 
https://github.com/Polymer/core-header-panel/blob/master/core-header-panel.html

- R. Niwa

Re: Inheritance Model for Shadow DOM Revisited

2015-04-28 Thread Ryosuke Niwa


 On Wed, Apr 29, 2015 at 2:09 AM Ryosuke Niwa rn...@apple.com wrote:
 
  On Apr 27, 2015, at 9:50 PM, Hayato Ito hay...@chromium.org wrote:
 
  The feature of shadow as function supports *subclassing*. That's 
  exactly the motivation I've introduced it once in the spec (and 
  implemented it in blink). I think Jan Miksovsky, co-author of Apple's 
  proposal, knows well that.
 
 We're (and consequently I'm) fully aware of that feature/prosal, and we 
 still don't think it adequately addresses the needs of subclassing.
 
 The problem with shadow as function is that the superclass implicitly 
 selects nodes based on a CSS selector so unless the nodes a subclass wants 
 to insert matches exactly what the author of superclass considered, the 
 subclass won't be able to override it. e.g. if the superclass had an 
 insertion point with select=input.foo, then it's not possible for a 
 subclass to then override it with, for example, an input element wrapped in 
 a span.
 
  The reason I reverted it from the spec (and the blink), [1], is a 
  technical difficulty to implement, though I've not proved that it's 
  impossible to implement.
 
 I'm not even arguing about the implementation difficulty. I'm saying that 
 the semantics is inadequate for subclassing.

 On Apr 28, 2015, at 10:34 AM, Hayato Ito hay...@chromium.org wrote:
 
 Could you help me to understand what implicitly means here?

I mean that the superclass’ insertion points use a CSS selector to select nodes 
to distribute. As a result, unless the subclass can supply the exactly kinds of 
nodes that matches the CSS selector, it won’t be able to override the contents 
into the insertion point.

 In this particular case, you might want to blame the super class's author and 
 tell the author, Please use content select=.input-foo so that subclass can 
 override it with arbitrary element with class=input-foo”.

The problem is that it may not be possible to coordinate across class hierarchy 
like that if the superclass was defined in a third party library. With the 
named slot approach, superclass only specifies the name of a slot, so subclass 
will be able to override it with whatever element it supplies as needed.

 Could you give me an concrete example which content slot can support, but 
 shadow as function can't support?

The problem isn’t so much that slot can do something shadow as function 
can’t support. It’s that shadow as function promotes over specification of 
what element can get into its insertion points by the virtue of using a CSS 
selector.

Now, it's possible that we can encourage authors to always use a class name in 
select attribute to support this use case. But then why are we adding a 
capability that we then discourage authors from using it.

- R. Niwa

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

2015-05-05 Thread Ryosuke Niwa


 On May 5, 2015, at 11:55 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 
 On Tue, May 5, 2015 at 11:20 AM, Ryosuke Niwa rn...@apple.com wrote:
 On May 4, 2015, at 10:20 PM, Anne van Kesteren ann...@annevk.nl wrote:
 
 On Tue, May 5, 2015 at 6:58 AM, Elliott Sprehn espr...@chromium.org 
 wrote:
 We can solve this
 problem by running the distribution code in a separate scripting context
 with a restricted (distribution specific) API as is being discussed for
 other extension points in the platform.
 
 That seems like a lot of added complexity, but yeah, that would be an
 option I suppose. Dimitri added something like this to the imperative
 API proposal page a couple of days ago.
 
 
 One thing to consider here is that we very much consider distribution a
 style concept. It's about computing who you inherit style from and where 
 you
 should be in the box tree. It just so happens it's also leveraged in event
 dispatch too (like pointer-events). It happens asynchronously from DOM
 mutation as needed just like style and reflow though.
 
 I don't really see it that way. The render tree is still computed from
 the composed tree. The composed tree is still a DOM tree, just
 composed from various other trees. In the open case you can access
 it synchronously through various APIs (e.g.  if we keep that for
 querySelector() selectors and also deepPath).
 
 I agree. I don't see any reason node distribution should be considered as a 
 style concept. It's a DOM concept. There is no CSS involved here.
 
 Yes there is.  As Elliot stated in the elided parts of his quoted
 response above, most of the places where we update distribution are
 for CSS or related concerns:
 
 # 3 event related
 # 3 shadow dom JS api

These two are nothing to do with styles or CSS.

 I have issues with the argument that we should do it lazily.  On one hand, 
 if node distribution is so expensive that we need to do it lazily, then it's 
 unacceptable to make event dispatching so much slower.  On the other hand, 
 if node distribution is fast, as it should be, then there is no reason we 
 need to do it lazily.
 
 The problem is really the redistributions. If we instead had explicit 
 insertion points under each shadow host, then we wouldn't really need 
 redistributions at all, and node distribution can happen in O(1) per child 
 change.
 
 As repeatedly stated, redistribution appears to be a necessity for
 composition to work in all but the most trivial cases.

Where?  I have not yet to see a use case for which selective redistribution of 
nodes (i.e. redistributing only a non-empty strict subset of nodes from an 
insertion point) are required.

- R. Niwa

Re: Custom Elements: Upgrade et al

2015-05-06 Thread Ryosuke Niwa


 On May 6, 2015, at 8:37 AM, Anne van Kesteren ann...@annevk.nl wrote:
 
 On Wed, May 6, 2015 at 4:59 PM, Dimitri Glazkov dglaz...@google.com wrote:
 On Wed, May 6, 2015 at 7:50 AM, Domenic Denicola d...@domenic.me wrote:
 Can you explain how you envision cloning to work a bit more? Somehow there
 will be instances of these elements which are not created by their
 constructors?
 
 Also, how is it in any way similar to  how canvas or input work? I am
 pretty sure both of those are constructed during cloning.
 
 The proposal would be to change that. You can construct an instance.
 And you can create a second instance either by cloning the first or
 constructing a new one.
 
 The difference between canvas and input is that for input we
 also clone private state using this hook:
 
  https://dom.spec.whatwg.org/#concept-node-clone-ext
 
 canvas does no such thing.

Are you suggesting that cloning my-button will create a new instance of 
my-button by invoking its constructor?

- R. Niwa

Re: Shadow DOM: state of the distribution API

2015-05-06 Thread Ryosuke Niwa


 On May 6, 2015, at 10:57 AM, Jonas Sicking jo...@sicking.cc wrote:
 
 On Wed, May 6, 2015 at 2:05 AM, Anne van Kesteren ann...@annevk.nl wrote:
 
 1) Synchronous, no flattening of content. A host element's shadow
 tree has a set of slots each exposed as a single content element to
 the outside. Host elements nested inside that shadow tree can only
 reuse slots from the outermost host element.
 
 2) Synchronous, flattening of content. Any host element nested
 inside a shadow tree can get anything that is being distributed.
 (Distributed content elements are unwrapped and not distributed
 as-is.)
 
 3) Lazy. A distinct global (similar to the isolated Shadow DOM story)
 is responsible for distribution so it cannot observe when distribution
 actually happens.
 
 Has at-end-of-microtask been debated rather than 1/2?

Yes. 1 and 2 don't really specify when as Anne pointed out. Timing is discussed 
separately at [1].

 Synchronous always has the downside that the developer has to deal with 
 reentrancy.

I think we can make the same argument we made for custom elements. Since the 
distribution is done by each shadow DOM's implementation, there is a clear 
ownership. We also can't think of a use case in which `distribute` must be 
called recursively so we might want to ban it altogether (and throw) if that 
were the concern.

 End-of-microtask does have the downside that API calls which
 synchronously return layout information get the wrong values. Or
 rather, values that might change at end of microtask.
 
 But calling sync layout APIs is generally a bad idea for perf anyway.
 If we introduced async versions of getComputedStyle,
 getBoundingClientRect etc, then we could make those wait to return a
 value until all content had been distributed into insertion points.
 
 Of course, adding async layout accessors is a non-trivial project, but
 it's long over due.

I think the biggest concern with this approach is that it essentially forces 
the existing web pages to be rewritten in order to adopt shadow DOM. I'm not 
certain if it's the end of the world but it will surely raise the barrier of 
using shadow DOM.

[1] 
https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Imperative-API-for-Node-Distribution-in-Shadow-DOM.md#api-for-triggering-distribution

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

2015-05-06 Thread Ryosuke Niwa


 On May 5, 2015, at 10:53 PM, Anne van Kesteren ann...@annevk.nl wrote:
 
 On Wed, May 6, 2015 at 3:22 AM, Ryosuke Niwa rn...@apple.com wrote:
 Where?  I have not yet to see a use case for which selective redistribution 
 of nodes (i.e. redistributing only a non-empty strict subset of nodes from 
 an insertion point) are required.
 
 Isn't that what e.g. select does? That is, select only cares about
 option and optgroup elements that are passed to it.

Or it could just distribute all the elements and have do:
```css
::content * { display:none; }
::content option, optgroup { display:block; }
```

Dimitri just added a document describing how we can turn partial distribution 
into whole distribution here (thanks Dimitri!):
https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Partial-Redistributions-Analysis.md

- R. Niwa

Re: Shadow DOM: state of the distribution API

2015-05-06 Thread Ryosuke Niwa


 On May 6, 2015, at 2:39 PM, Elliott Sprehn espr...@chromium.org wrote:
 
 The 3 proposal is what the houdini effort is already researching for custom 
 style/layout/paint. I don't think it's acceptable to make all usage of Shadow 
 DOM break when used with libraries that read layout information today, ie. 
 offsetTop must work. I also don't think it's acceptable to introduce new 
 synchronous hooks and promote n^2 churn in the distribution.

Sorry, I don't follow. If we're making offsetTop to synchronously return the 
correct value, then authors can easily write code that performs in Ω(n^2) by 
obtaining the value of offsetTop between adding/removing direct children of a 
shadow host.  On the other hand, if we're trying to prevent O(n^2) behavior, 
then we should be adding API to asynchronously retrieve layout information.

- R. Niwa

Re: Custom Elements: is=

2015-05-06 Thread Ryosuke Niwa


 On May 6, 2015, at 6:25 AM, Anne van Kesteren ann...@annevk.nl wrote:
 
 Open issues are kept track of here:
 
  https://wiki.whatwg.org/wiki/Custom_Elements
 
 I think we reached rough consensus at the Extensible Web Summit that
 is= does not do much, even for accessibility. Accessibility is
 something we need to tackle low-level by figuring out how builtin
 elements work:
 
  https://github.com/domenic/html-as-custom-elements
 
 And we need to tackle it high-level by making it easier to style
 builtin elements:
 
  http://dev.w3.org/csswg/css-forms/
 
 And if the parser functionality provided by is= is of great value,
 we should consider parsing elements with a hyphen in them differently.
 Similar to how script and template are allowed pretty much
 everywhere.
 
 Therefore, I propose that we move subclassing of builtin elements to
 v2, remove is= from the specification, and potentially open an issue
 on HTML parser changes.

We (Apple) support this proposal.

- R. Niwa

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

2015-05-06 Thread Ryosuke Niwa


 On May 6, 2015, at 6:18 PM, Hayato Ito hay...@chromium.org wrote:
 
 On Wed, May 6, 2015 at 10:22 AM Ryosuke Niwa rn...@apple.com wrote:
 
  On May 5, 2015, at 11:55 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 
  On Tue, May 5, 2015 at 11:20 AM, Ryosuke Niwa rn...@apple.com wrote:
  On May 4, 2015, at 10:20 PM, Anne van Kesteren ann...@annevk.nl wrote:
 
  On Tue, May 5, 2015 at 6:58 AM, Elliott Sprehn espr...@chromium.org 
  wrote:
  We can solve this
  problem by running the distribution code in a separate scripting context
  with a restricted (distribution specific) API as is being discussed for
  other extension points in the platform.
 
  That seems like a lot of added complexity, but yeah, that would be an
  option I suppose. Dimitri added something like this to the imperative
  API proposal page a couple of days ago.
 
 
  One thing to consider here is that we very much consider distribution a
  style concept. It's about computing who you inherit style from and 
  where you
  should be in the box tree. It just so happens it's also leveraged in 
  event
  dispatch too (like pointer-events). It happens asynchronously from DOM
  mutation as needed just like style and reflow though.
 
  I don't really see it that way. The render tree is still computed from
  the composed tree. The composed tree is still a DOM tree, just
  composed from various other trees. In the open case you can access
  it synchronously through various APIs (e.g.  if we keep that for
  querySelector() selectors and also deepPath).
 
  I agree. I don't see any reason node distribution should be considered as 
  a style concept. It's a DOM concept. There is no CSS involved here.
 
  Yes there is.  As Elliot stated in the elided parts of his quoted
  response above, most of the places where we update distribution are
  for CSS or related concerns:
 
  # 3 event related
  # 3 shadow dom JS api
 
 These two are nothing to do with styles or CSS.
 
 I'd like to inform all guys in this thread that Composed Tree is for 
 resolving CSS inheritance by the definition.
 See the Section 2.4 Composed Trees in the spec:
 http://w3c.github.io/webcomponents/spec/shadow/#composed-trees
 
 Let me quote:
  If an element doesn't participate in a composed tree whose root node is a 
  document, the element must not appear in the formating structure [CSS21] 
  nor create any CSS box. This behavior must not be overridden by setting the 
  'display' property.
 
  In resolving CSS inheritance, an element must inherit from the parent node 
  in the composed tree, if applicable.
 
 The motivation of a composed tree is to determine the parent node in 
 resolving CSS inheritance. There is no other significant usages, except for 
 event path.

Event path / retargeting is definitely event related, and it (e.g. deepPath) 
is definitely a part of shadow DOM JS API.  Again, they're nothing to do with 
styles or CSS.

- R. Niwa

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

2015-05-05 Thread Ryosuke Niwa


 On May 4, 2015, at 10:20 PM, Anne van Kesteren ann...@annevk.nl wrote:
 
 On Tue, May 5, 2015 at 6:58 AM, Elliott Sprehn espr...@chromium.org wrote:
 We can solve this
 problem by running the distribution code in a separate scripting context
 with a restricted (distribution specific) API as is being discussed for
 other extension points in the platform.
 
 That seems like a lot of added complexity, but yeah, that would be an
 option I suppose. Dimitri added something like this to the imperative
 API proposal page a couple of days ago.
 
 
 One thing to consider here is that we very much consider distribution a
 style concept. It's about computing who you inherit style from and where you
 should be in the box tree. It just so happens it's also leveraged in event
 dispatch too (like pointer-events). It happens asynchronously from DOM
 mutation as needed just like style and reflow though.
 
 I don't really see it that way. The render tree is still computed from
 the composed tree. The composed tree is still a DOM tree, just
 composed from various other trees. In the open case you can access
 it synchronously through various APIs (e.g.  if we keep that for
 querySelector() selectors and also deepPath).

I agree. I don't see any reason node distribution should be considered as a 
style concept. It's a DOM concept. There is no CSS involved here.

I have issues with the argument that we should do it lazily.  On one hand, if 
node distribution is so expensive that we need to do it lazily, then it's 
unacceptable to make event dispatching so much slower.  On the other hand, if 
node distribution is fast, as it should be, then there is no reason we need to 
do it lazily.

The problem is really the redistributions. If we instead had explicit insertion 
points under each shadow host, then we wouldn't really need redistributions at 
all, and node distribution can happen in O(1) per child change.

- R. Niwa

Re: Custom Elements: Upgrade et al

2015-05-07 Thread Ryosuke Niwa


 On May 6, 2015, at 9:48 PM, Anne van Kesteren ann...@annevk.nl wrote:
 
 On Thu, May 7, 2015 at 12:23 AM, Ryosuke Niwa rn...@apple.com wrote:
 Are you suggesting that cloning my-button will create a new instance of 
 my-button by invoking its constructor?
 
 No, I'm saying there would be another primitive operation, similar to
 the extended structured cloning proposed elsewhere, to accomplish
 cloning without side effects.

Okay. Do you have any idea / proposal as to how that would look like?  I'm 
still not fully grasping what you're proposing to do when we close a custom 
element.

- R. Niwa

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

2015-05-07 Thread Ryosuke Niwa


 On May 6, 2015, at 11:10 PM, Elliott Sprehn espr...@chromium.org wrote:
 
 On Wed, May 6, 2015 at 11:08 PM, Anne van Kesteren ann...@annevk.nl wrote:
 On Thu, May 7, 2015 at 6:02 AM, Hayato Ito hay...@chromium.org wrote:
  I'm saying:
  - Composed tree is related with CSS.
  - Node distribution should be considered as a part of style concept.
 
 Right, I think Ryosuke and I simply disagree with that assessment. CSS
 operates on the composed tree (and forms a render tree from it).
 Events operate on the composed tree. Selection operates on the
 composed tree (likely, we haven't discussed this much).
 
 Selection operates on the render tree. The current selection API is 
 (completely) busted for modern apps, and a new one is needed that's based 
 around layout. Flexbox w/ order, positioned objects, distributions, grid, 
 none of them work with the DOM based API.

Please state your presumptions like that before making a statement such as 
composed street is a style concept.

Now, even if selection were to operate on the CSS box tree, of which I will not 
express my opinion of, event path is still not a style concept.  If you're 
proposing to make it a style concept, then I just need to object to that.

- R. Niwa

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

2015-05-08 Thread Ryosuke Niwa


 On May 7, 2015, at 7:20 PM, Hayato Ito hay...@chromium.org wrote:
 
 Ryosuke, could you file a bug for the spec if you find an uncomfortable part 
 in the spec?
 I want to understand exactly what you are trying to improve.

I don't think there is any issue with the spec per se.  What Anne and I both 
are pointing out is that event path isn't a style concept so node distribution 
can't be thought of as a style concept.

- R. Niwa

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

2015-05-18 Thread Ryosuke Niwa

On May 18, 2015, at 11:18 AM, Dimitri Glazkov dglaz...@google.com wrote:

On Fri, May 15, 2015 at 4:58 PM, Scott Miles sjmi...@google.com wrote:
Polymer really wants Shadow DOM natively, and we think the `slot` proposal
can work, so maybe let's avoid blocking on design of an imperative API
(which we still should make in the long run).

As our entire stack is built on Web Components, the Polymer team is highly
motivated to assist browser implementers come to agreement on a Shadow DOM
specification. Specifically, as authors of the `webcomponents-js` polyfills,
and more than one Shadow DOM shim, we are keenly aware of how difficult
Shadow DOM is to simulate without true native support.

I believe we are in general agreement with the implementers that an
imperative API, especially one that cleanly explains platform behavior, is
an ideal end point for Shadow DOM distribution. However, as has been
discussed at length, it’s likely that a proper imperative API is blocked on
other still-to-mature technologies. For this reason, we would like for the
working group to focus on writing the spec for the declarative `slot`
proposal [1]. We're happy to participate in the process.

[1]:
https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution.md#proposal-part-1-syntax-for-named-insertion-points

It sounds like we are no longer in disagreement on the F. Slots Proposal
item from the April 2015 Meeting
(https://www.w3.org/wiki/Webapps/WebComponentsApril2015Meeting), so we don't
need to block it on the C. The imperative distribution API item.

Given that all vendors agreed that C can wait until v2, we could just focus
on concretizing the slots proposal and then put a lid on Shadow DOM v1.

What do you think, folks?

We (Apple) support focusing on the slot proposal and deferring the imperative
API to v2 or at least not blocking the discussion for the named slots.

- R. Niwa

Re: Custom Elements: is=

2015-06-08 Thread Ryosuke Niwa


 On Jun 8, 2015, at 2:16 PM, Alice Boxhall aboxh...@google.com wrote:
 
 Did anyone have any further thoughts on this? My concerns haven't changed.

Nothing new.

 On Sat, May 9, 2015 at 3:34 PM, Alice Boxhall aboxh...@google.com wrote:
 On Thu, May 7, 2015 at 1:00 AM, Anne van Kesteren ann...@annevk.nl wrote:
 On Wed, May 6, 2015 at 6:59 PM, Alice Boxhall aboxh...@google.com wrote:
  I definitely acknowledge is= may not be the ideal solution to the latter
  problem - it definitely has some holes in it, especially when you start
  adding author shadow roots to things - but I think it does have potential.
  I'd really like to be convinced that we either have a reasonable 
  alternative
  solution, or that it's not worth worrying about.
 
 I think it is worth worrying about, but I don't think it's worth
 holding up a minimal v1 of Custom Elements for. The way to get
 agreement among all parties is to do less. And then take baby steps
 from.
 
 I can definitely see that logic.
 
 My concerns with this in practice are:
 
 - In the time between v1 and v2 (however long that ends up being) we are 
 left without any way to solve this problem, assuming we don't come up with 
 something else for v1. If developers start using custom elements where they 
 would previously have used a native element, this could well result in a 
 regression in accessibility for the web as a whole for this period, and we 
 will be stuck with the legacy of code written during this period for much 
 longer as well.

Web developers are already writing their own custom elements as a bunch of 
nested div's.  How does introducing custom elements make it worse?

The argument that it'll make things worse between v1 and v2 is moot because we 
haven't agreed on anything. is= syntax may never be realized due to various 
issues associated with it.

 - I realise that to some extent developers already aren't using native 
 elements, in part because of the styling issues we've discussed which also 
 affect is=. My concern here is that custom elements will further legitimise 
 this habit, which we've been making some recent progress in changing - we 
 stand to backslide on that effort. Having is= would allow us to roll it into 
 the use native elements where possible message rather than diluting it 
 with unless you're using a custom element in which case here's a checklist 
 which you're not going to look at of everything it should do until we come 
 up with an alternative.

In the case of stylizing elements, it doesn't really matter if authors attach a 
shadow DOM on top of a builtin input element or to a div because as soon as the 
shadow DOM replaces the rendered contents, we can't make assumptions about how 
to expose that element to AT.

 The way I look at this is that currently you have nothing, since only
 Chrome ships this. There's a chance to get three more browsers if you
 make some concessions on the warts. And then hopefully we can iterate
 from there in a more cooperative fashion.
 
 Here's where we differ, because:
 - I don't think it's a wart. I've given this a great deal of thought and I 
 keep ending up back at the current syntax when I try to think of reasonable 
 alternatives, even assuming we could magically fix all the implementation 
 issues with any alternative proposal.

FWIW, we (Apple) definitely dislike is= syntax as currently (or formerly) 
spec'ed.

 - I don't think shipping in one browser is nothing. People (both framework 
 authors and web page authors) are already writing code using is=.

Some developers are always going to use a feature only implemented by a single 
browser (ActiveX in Trident, NaCl in Chrome, current web components 
implementation in Chrome). In fact, why would any browser vendor ship a feature 
that's not going to be used by anyone? However, that doesn't mean the feature 
will be standardized or adopted by other browser vendors.

- R. Niwa

Re: Custom Elements: is=

2015-06-08 Thread Ryosuke Niwa


 On Jun 8, 2015, at 3:23 PM, Alice Boxhall aboxh...@google.com wrote:
 
 On Mon, Jun 8, 2015 at 3:12 PM, Ryosuke Niwa rn...@apple.com 
 mailto:rn...@apple.com wrote:
 
  On Jun 8, 2015, at 2:16 PM, Alice Boxhall aboxh...@google.com 
  mailto:aboxh...@google.com wrote:
 Web developers are already writing their own custom elements as a bunch of 
 nested div's.  How does introducing custom elements make it worse?
 
 I believe the rest of my comment already addressed this.

Sorry, I don't follow.

  - I realise that to some extent developers already aren't using native 
  elements, in part because of the styling issues we've discussed which 
  also affect is=. My concern here is that custom elements will further 
  legitimise this habit, which we've been making some recent progress in 
  changing - we stand to backslide on that effort. Having is= would allow 
  us to roll it into the use native elements where possible message 
  rather than diluting it with unless you're using a custom element in 
  which case here's a checklist which you're not going to look at of 
  everything it should do until we come up with an alternative.
 
 In the case of stylizing elements, it doesn't really matter if authors 
 attach a shadow DOM on top of a builtin input element or to a div because as 
 soon as the shadow DOM replaces the rendered contents, we can't make 
 assumptions about how to expose that element to AT.
 
 That's simply not true at all. If someone replaces the rendered content of a 
 `button`, we know that their intent is to create an element which is 
 semantically a button, and may even be rendered as a button in some cases. 
 Similarly for `input` with a `type` attribute. This is no different to 
 using an ARIA role as far as assistive technology is concerned.

Perhaps I should have said we can't _always_ make assumptions about how to 
expose that element to AT.

Consider creating a date picker in the time we haven't added type=date yet.  
Inside the shadow DOM of this color picker may contain various buttons and 
controls to move between months and pick a date.  Treating the entire control 
as a text field will provide a very poor user experience.

All the use cases I can think of that let UA can safely make assumptions about 
the ARIA role of the element involves tweaking the appearance, which is better 
served by better styling mechanisms for form controls.


  The way I look at this is that currently you have nothing, since only
  Chrome ships this. There's a chance to get three more browsers if you
  make some concessions on the warts. And then hopefully we can iterate
  from there in a more cooperative fashion.
 
  Here's where we differ, because:
  - I don't think it's a wart. I've given this a great deal of thought and I 
  keep ending up back at the current syntax when I try to think of 
  reasonable alternatives, even assuming we could magically fix all the 
  implementation issues with any alternative proposal.
 
 FWIW, we (Apple) definitely dislike is= syntax as currently (or formerly) 
 spec'ed.
 
 Any chance you could go into more detail on that? What exactly is it you 
 dislike about it?

See our replies on the topic on public-webapps.  I don't have a time to collect 
all our replies or restate all the problems we have with is= syntax.  (Perhaps 
I should put up a document somewhere to reference since someone brings up the 
same question every six months or so, and I'm getting sick and tried to even 
say that I don't have a time to re-iterate the same points over and over...)

  - I don't think shipping in one browser is nothing. People (both 
  framework authors and web page authors) are already writing code using 
  is=.
 
 Some developers are always going to use a feature only implemented by a 
 single browser (ActiveX in Trident, NaCl in Chrome, current web components 
 implementation in Chrome). In fact, why would any browser vendor ship a 
 feature that's not going to be used by anyone? However, that doesn't mean 
 the feature will be standardized or adopted by other browser vendors.
 
 No, but unlike the first two examples, this is a proposed web standard.

Well, not everything people propose as a standard becomes a standard.  When a 
proposed standard is rejected, however, people tend to come up with an 
alternative proposal to address those issues.  As far as is= syntax is 
concerned, I haven't heard of any proposals to fix it so as to address 
everyone's concerns.

If you're really passionate about this feature, I suggest you can go dig all 
the discussions we've had in the last three years and see if you can resolve 
all the concerns raised by various participants of the working group.  Now, 
some of those concerns we and others have raised may not be relevant, and they 
may have changed their positions and opinions on matters.  Regardless, I don't 
think keep saying you like (or that you think we need) this feature without 
proposing fixes to raised concerns is productive.

- R

Re: Custom Elements: is=

2015-06-08 Thread Ryosuke Niwa


 On Jun 8, 2015, at 4:37 PM, Alice Boxhall aboxh...@google.com wrote:
 
 
 
 On Mon, Jun 8, 2015 at 4:23 PM, Ryosuke Niwa rn...@apple.com wrote:
 
 On Jun 8, 2015, at 3:23 PM, Alice Boxhall aboxh...@google.com wrote:
 
 On Mon, Jun 8, 2015 at 3:12 PM, Ryosuke Niwa rn...@apple.com wrote:
 
  On Jun 8, 2015, at 2:16 PM, Alice Boxhall aboxh...@google.com wrote:
 Web developers are already writing their own custom elements as a bunch 
 of nested div's.  How does introducing custom elements make it worse?
 
 I believe the rest of my comment already addressed this.
 
 Sorry, I don't follow.
 
  - I realise that to some extent developers already aren't using native 
  elements, in part because of the styling issues we've discussed which 
  also affect is=. My concern here is that custom elements will further 
  legitimise this habit, which we've been making some recent progress in 
  changing - we stand to backslide on that effort. Having is= would allow 
  us to roll it into the use native elements where possible message 
  rather than diluting it with unless you're using a custom element in 
  which case here's a checklist which you're not going to look at of 
  everything it should do until we come up with an alternative.
 
 In the case of stylizing elements, it doesn't really matter if authors 
 attach a shadow DOM on top of a builtin input element or to a div because 
 as soon as the shadow DOM replaces the rendered contents, we can't make 
 assumptions about how to expose that element to AT.
 
 That's simply not true at all. If someone replaces the rendered content of 
 a `button`, we know that their intent is to create an element which is 
 semantically a button, and may even be rendered as a button in some cases. 
 Similarly for `input` with a `type` attribute. This is no different to 
 using an ARIA role as far as assistive technology is concerned.
 
 Perhaps I should have said we can't _always_ make assumptions about how to 
 expose that element to AT.
 
 Consider creating a date picker in the time we haven't added type=date yet.  
 Inside the shadow DOM of this color picker may contain various buttons and 
 controls to move between months and pick a date.  Treating the entire 
 control as a text field will provide a very poor user experience.
 
 Ah, I see what you're saying now, thanks for clarifying.
 
 In this case, the custom element author can add semantic markup inside Shadow 
 DOM just as the browser does for a date picker currently - no assumptions 
 need to be made, since even in the case of type extensions the Shadow DOM is 
 available to the accessibility tree. I don't think it will ever treat the 
 entire control as a text field.

If you're fine with that, why don't you just let authors just put ARIA role in 
buttons' shadow DOM as well?

It would also mean that the author must override the ARIA role implicitly set 
(text field) by UA in this case.  I'd say that's exactly the kind of feature 
that makes the Web platform annoying.

 All the use cases I can think of that let UA can safely make assumptions 
 about the ARIA role of the element involves tweaking the appearance, which 
 is better served by better styling mechanisms for form controls.
  
 I don't think it's an either/or question between is= and styling mechanisms 
 for form controls. I actually think we need both.

Why?  Having authors use two completely different mechanisms to define 
semantics seems like the worst of the both worlds.

- R. Niwa

Re: [ime-api] [blink-dev] Removing IME API code from Blink

2015-05-27 Thread Ryosuke Niwa


 On May 27, 2015, at 11:46 AM, Travis Leithead travis.leith...@microsoft.com 
 wrote:
 
 I believed the use-cases for avoiding UI clashes between site-driven 
 auto-complete lists and IME auto-complete boxes is still a valid use case, 
 and I think the spec is still valid to try to push to recommendation. 
 However, I'd also like to follow up on usage of the ms- prefixed API so that 
 I can get an idea of what its real usage is.

I agree avoiding UI clashes between auto-completions of IME and web page is a 
great use case but I'm not convinced that exposing ClientRect for IME is the 
right API as many Web developers aren't even aware of UI challenges IME 
imposes. For example, a similar UI challenge emerges when dealing with 
auto-corrections in grammar/spell checking features as well.  It would be ideal 
if IME and spell/grammar corrections are handled in a similar manner so that 
Web apps supporting either feature will just work with both features.

- R. Niwa

Re: Components F2F

2015-07-02 Thread Ryosuke Niwa


 On Jun 30, 2015, at 2:55 AM, Anne van Kesteren ann...@annevk.nl wrote:
 
 Can someone update
 https://www.w3.org/wiki/Webapps/WebComponentsJuly2015Meeting with a
 bit more information? I hear it might be in Mountain View?

Is Google hosting this meeting as well?  Alternatively, would other browser 
vendors (e.g. Mozilla) willing to host it this time?

Unfortunately, it's going to be really hard to reserve a big enough room at 
Apple :(  I'm hoping that'll change once we move to the new spaceship but we'll 
see...

 Will we have sufficient time to cover both Custom Elements and Shadow
 DOM? And could the drafts maybe be updated to cover what has been
 agreed to so far? E.g. it seems we have agreement on slots and I think
 that was the last major thing from Shadow DOM that needed a solution.
 Would be great if we could review a complete document.

I'm supposed to write up a document that summaries what we've agreed thus far.  
I've been busy with other stuff lately but will try to post it before the 
meeting.

- R. Niwa

Re: Custom Elements: is=

2015-07-02 Thread Ryosuke Niwa


 On Jun 13, 2015, at 4:49 PM, Léonie Watson lwat...@paciellogroup.com wrote:
 
 From: Bruce Lawson [mailto:bru...@opera.com] 
 Sent: 13 June 2015 16:34
 
 On 13 June 2015 at 15:30, Léonie Watson lwat...@paciellogroup.com wrote:
 why not use the extends= syntax you mentioned?
 
 my-button extends=button attributesPush/my-button
 
 because browsers that don't know about web components wouldn't pay any 
 attention to my-button, and render Push as plain text.
 
 Of course! I should have thought of that.

That's not entirely true.  If the implementation of my-button, let us call it 
MyButtonElement had the prototype that extends HTMLButtonElement, then the 
browser can set role=button just fine.

 On Jun 13, 2015, at 5:41 PM, Patrick H. Lauke re...@splintered.co.uk wrote:
 
 On 13/06/2015 16:33, Bruce Lawson wrote:
 On 13 June 2015 at 15:30, Léonie Watson lwat...@paciellogroup.com wrote:
 why not use the extends= syntax you mentioned?
 
 my-button extends=button attributesPush/my-button
 
 because browsers that don't know about web components wouldn't pay any
 attention to my-button, and render Push as plain text.
 
  Browsers that don't know about web components will fall back to
 button with button
 this-is-made-much-more-marvellous-by=my-button (or whatever)
 
 However, this fallback will only really be useful for very simple cases, 
 where web components have been used to jazz up what essentially is still the 
 element that was extended. And, I would posit, any scripting that was done to 
 act on the all-singing, all-dancing new web component button (if it does 
 anything more than a regular button) would not work for the fallback. Unless 
 it's really just using web components for fancy styling (for instance having 
 a material design button that essentially still works just like a button) - 
 in which case, it makes more sense to work on stylability of standard 
 elements.


Precisely!  I've been saying that for the last two years.  It's so nice  
refreshing to hear someone making the same argument :)  And we (Apple) would 
love to solve the stylability issue of form elements.

- R. Niwa

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

2015-05-22 Thread Ryosuke Niwa


 On May 21, 2015, at 11:33 PM, Wilson Page wilsonp...@me.com wrote:
 
 From experience building components for Firefox OS I think the 'default slot' 
 pattern will fulfill most of our use-cases. This means we won't have to 
 burden our component users by requiring them to add `slot=foo` all over the 
 place.

Could you clarify what you're referring to by 'default slot' pattern?

 Is it fair to say that if this declarative API lands in V1, it's unlikely 
 we'll see imperative API in V2? Have we not exhausted all the options?

At F2F, basically all browser vendors have agreed that we eventually want the 
imperative API, and we (Apple) are certainly interested in the imperative API 
being included in v2.

- R. Niwa

Copying multi-range selection

2015-08-14 Thread Ryosuke Niwa

Hi all,

We've been recently exploring ways to select bidirectional text and content 
that uses new CSS layout modes such as flex box in visually contagious manner.

Because visually contagious range of content may not be contagious in DOM 
order, doing so involves creating a disjoint multi-range selection.  There has 
been quite a bit of discussion about how we can better expose that to the Web 
since the current model of exposing a list of Range objects doesn't seem to be 
working well.

However, another important question I have is how copying such a selected 
content work?  Do we just stitch together disjoint content?  But that may 
result in the content being pasted in completely different order.

Does anyone from Mozilla can share their experience about this?

- R. Niwa

Re: alternate view on constructors for custom elements

2015-07-17 Thread Ryosuke Niwa


 On Jul 17, 2015, at 1:14 PM, Travis Leithead travis.leith...@microsoft.com 
 wrote:
 
 From: Domenic Denicola [mailto:d...@domenic.me] 
 
 window.XFoo = document.registerElement(‘x-foo’, XFooStartup);
 
 Why is XFoo different from XFooStartup? If I define a method in XFooStartup, 
 does it exist in XFoo?
 
 This won't work as I described it, given what you've told me, but my 
 assumption was essentially, that XFooStartup would act as if it didn't really 
 depend on HTMLElement for construction. So, it's constructor wouldn't be 
 linked to the actual custom element creation. Therefore XFoo (the 
 platform-provided constructor function is the thing that is actually used to 
 trigger construction, which would then result in the XFooStartup constructor 
 running. Basically, like this (reverting to non-class syntax):
 
 function XFooStartup(val1, val2) {
  this.prop = val1;
  this.prop2 = val2;
 }
 window.XFoo = document.registerElement(‘x-foo’, XFooStartup);
 
 all I was trying to express different from the current design is: 
 1) replacing the createdCallback with the function constructor (and passing 
 the new element instance as 'this' when calling it)
 2) passing through params from the XFoo platform-native constructor to the 
 XFooStartup function
 3) calling XFooStartup synchronously

We can do this without wrapping author supplied constructor.  In ES6/ES2015 
classes, `this` variable is in the temporary dead zone (TDZ) until `super()` 
which allocates `this` and any attempt to access it will throw 
`ReferenceError`.  In other words, XFooStartup has no way of accessing the 
newly constructed object until `super()` has returned.  This in turns allows 
browser engines to create a native (C++) backing store for the HTML element 
inside HTMLElement’s constructor (or an equivalent code that runs as a part of 
call to `super()` from the direct subclass of HTMLElement) since the newly 
constructed (this) element is never accessed until the highest superclass' 
`super()` (which is HTMLElement in this case) had been called.

- R. Niwa

Re: Custom Elements: createdCallback cloning

2015-07-13 Thread Ryosuke Niwa


 On Jul 12, 2015, at 11:30 PM, Anne van Kesteren ann...@annevk.nl wrote:
 
 On Mon, Jul 13, 2015 at 1:10 AM, Dominic Cooney domin...@google.com wrote:
 Yes. I am trying to interpret this in the context of the esdiscuss thread
 you linked. I'm not sure I understand the problem with private state,
 actually. Private state is allocated for DOM wrappers in Chromium today
 (like Gecko), including Custom Elements; it's not a problem. DOM wrapper
 creation is controlled by the UA, which can arrange for allocating the
 slots.
 
 Sure, but this assumes elements will be backed by something other than
 JavaScript forever. Or at the very least that custom elements will
 always be able to do less than builtin elements.
 
 
 Is there a plan for author classes to be able to have private state or
 something?
 
 Yes, as discussed in that es-discuss thread.
 
 
 Thanks. I can understand how editing and Range.cloneContents would use
 cloning. How is it relevant that Range is depended on by Selection?
 Selection may delete things but it does not clone them.
 
 Editing operations operate on selections, but maybe I'm mistaken about
 that? Either way, you got the problem.

Editing operations use cloning heavily.  As counter-intuitive as it sounds, 
deleting a range of text also involves cloning elements in some cases.

- R. Niwa

Shadow DOM and SVG use elements

2015-10-22 Thread Ryosuke Niwa

Hi all,

What should happen when a SVG use element references an element (or its 
ancestor) with a shadow root?

Should the use element show the composed tree underneath it or ignore shadow 
DOM altogether?

I'm a little inclined towards the former (uses the composed tree).

- R. Niwa

Re: Custom elements backing swap proposal

2015-10-24 Thread Ryosuke Niwa

> On Oct 24, 2015, at 9:55 AM, Elliott Sprehn  wrote:
> 
> I've been thinking about ways to make custom elements violate the consistency 
> principle less often and had a pretty awesome idea recently. 
> 
> Unfortunately I won't be at TPAC, but I'd like to discuss this idea in 
> person. Can we setup a custom element discussion later in the year?

Certainly. I won't be back in the states until 11/8 and both Blink and WebKit 
are having their contributor's meetings in the following week so how about the 
week of November 16th?

If not, the first and the second weeks of December also works.

> The current  "synchronous in the parser" model doesn’t feel good to me 
> because cloneNode() and upgrades are still async,

I've been making a prototype of custom elements API in which cloneNode and all 
other internal construction of elements are sync so only upgrading is async in 
our design.

> and I fear other things (ex. parser in editing, innerHTML) may need to be as 
> well.

Not in our design.

> So, while we've covered up the inconsistent state of the element in one place 
> (parser), we've left it to be a surprise in the others which seems worse than 
> just always being async. This led me to a crazy idea that would get us 
> consistency between all these cases:
> 
> What if we use a different pimpl object (C++ implementation object) when 
> running the constructor, and then move the children/shadows and attributes 
> after the fact? This element can be reused (as implementation detail), and 
> any attempt to append it to another element would throw.

This is not the first time this (or a similar) idea has been brought up.

The problem with this approach is that authors can still find the old 
non-temporary "pimpl" (where did this term come from?) via querySelectorAll, 
getElementsByTagName, etc... because it's still in the document. (If it's not 
in the document, then we would have the iframe reloading problem)

And when the constructors or unrelated code invoked by the constructor access 
the old "pimpl", we have two options:

1. Use the same wrapper as the one we're creating.  This is weird because the 
element as perceived by other DOM APIs such as querySelectorAll and the actual 
object behaves differently.

2. Create a new wrapper. But what are we going to do this with new wrapper when 
we swap back "pimpl" after calling the constructor?  Also, this would mean that 
the identify of elements will change.

There is yet another alternative: make all other DOM APIs behave as if these 
pre-construction custom elements don't exist. However, that is a much tricker 
thing to implement (especially if you didn't want to worsen the performance) 
than making all construction sync at least in WebKit.

- R. Niwa

Re: [Web Components] proposing a f2f...

2015-10-29 Thread Ryosuke Niwa

> 
> On Oct 29, 2015, at 9:47 AM, Chris Wilson  wrote:
> 
> Or host in Seattle.  :)
> 
> On Thu, Oct 29, 2015 at 9:20 AM, Travis Leithead 
>  wrote:
>> I would prefer a late January date so as to allow me to arrange travel. 
>> Otherwise, I’m happy to attend remotely anytime.

I'm okay with either option with a slight preference on having it earlier since 
we didn't have much time discussing custom elements at TPAC.

I would like to resolve the following issues for shadow DOM:
1. Clarify focus navigation
2. Clarify selection behavior (at least make it interoperable to JS)
3. Decide on the style cascading order

And the following issues for custom elements:
4. Construction model. Do we do sync / almost-sync / dance?
5. Do we support upgrading?  If we do, how?

Any other issues?

- R. Niwa

Re: [web components] proposed meetings: 15 dec / 29 jan

2015-11-13 Thread Ryosuke Niwa

> On Nov 13, 2015, at 8:08 AM, Anne van Kesteren <ann...@annevk.nl> wrote:
> 
> On Fri, Nov 13, 2015 at 4:57 PM, Ryosuke Niwa <rn...@apple.com> wrote:
>> What outstanding problems are you thinking of?
> 
> Again, not I, but Hayato Ito raised these. I just happen to agree. He
> emailed this list on November 2:
> 
>  https://lists.w3.org/Archives/Public/public-webapps/2015OctDec/0149.html

Of the four issues listed there:

> On Nov 1, 2015, at 7:52 PM, Hayato Ito <hay...@chromium.org> wrote:
> 
> > 1. Clarify focus navigation
> > 2. Clarify selection behavior (at least make it interoperable to JS)
> > 3. Decide on the style cascading order
> > 4. style inheritance (https://github.com/w3c/webcomponents/issues/314)

I'd like to resolve 3 and 4 ASAP since we're pretty close.  I don't think we 
necessarily need an in-person meeting to do that though.  If anything, it's 
probably more helpful to have discussion over mailing lists so that each person 
can spend as much time as needed to understand / come up with examples and 
proposals.

For 1, we had a rough consensus on how current focus model (in particular focus 
ordering) should be changed to support shadow DOM during TPAC.  Namely, we 
would create a new tab index "scope" at both shadow roots as well as slots, and 
follow the composed tree order for tab ordering.  I think someone should 
document that first.

I just started working on 2 but I probably won't have a time to come up with a 
proposal until mid December.

So if you guys can't make it, I don't think we necessarily need a shadow DOM 
meeting in December.

- R. Niwa

Re: [web components] proposed meetings: 15 dec / 29 jan

2015-11-13 Thread Ryosuke Niwa


> On Nov 13, 2015, at 3:07 AM, Anne van Kesteren  wrote:
> 
> On Fri, Nov 13, 2015 at 11:32 AM, Chaals McCathie Nevile
>  wrote:
>> Our proposal is to look for a host on 15 December on the West Coast, for a
>> meeting primarily focused on Shadow DOM, and another on 29 January in the
>> Bay area for one around Custom Elements. The agenda can be adjusted to take
>> account of people who are unable to travel for both of these, moving items
>> from one to the other if necessary, since *many* but *not all* people are
>> interested in both topics.
> 
> As mentioned before, I and others from Mozilla not in the US are
> unlikely to make December 15. There's a big Mozilla event the entire
> week before and I doubt folks want to keep trucking. But given how far
> along Shadow DOM is perhaps attendance is not important. After all,
> Hayato Ito stressed in an earlier email that to make the meeting
> worthwhile we'd need some new proposals to address the quite hard
> outstanding problems and I haven't seen any of those thus far.

What outstanding problems are you thinking of?

- R. Niwa

Re: TPAC Topic: Using ES2015 Modules in HTML

2015-10-16 Thread Ryosuke Niwa

> On Oct 16, 2015, at 2:45 AM, Anne van Kesteren <ann...@annevk.nl> wrote:
> 
> On Fri, Oct 16, 2015 at 5:39 AM, Ryosuke Niwa <rn...@apple.com> wrote:
>> Can we discuss how we can integrate ES2015 modules into HTML on Tuesday,
>> October 27th at TPAC?
> 
> Pretty sure Tuesday has been reserved for service workers discussion.

The wiki page says there will be a parallel meeting all day on Tuesday:
https://www.w3.org/wiki/index.php?title=Webapps/October2015Meeting 
<https://www.w3.org/wiki/index.php?title=Webapps/October2015Meeting>

CSS / Web Platform joint meeting is definitely happening at 3pm on Tuesday
so service worker meeting needs to finish before that in order not to overlap.

Regardless, we still prefer discussing ES2015 module integration on Tuesday 
morning.

- R. Niwa

TPAC Topic: Using ES2015 Modules in HTML

2015-10-15 Thread Ryosuke Niwa

Hi all,

Can we discuss how we can integrate ES2015 modules into HTML on Tuesday, 
October 27th at TPAC?

Both Gecko and WebKit are basically done implementing ES6 module supports in 
their respective JavaScript engines but blocked on 
http://whatwg.github.io/loader/  to support in 
web contents.

Since my colleague who is interested in this topic cannot attend TPAC in 
person, it would be great if we could have it in Tuesday Morning (Monday 
evening in California).

- R. Niwa

Re: PSA: publish WD of "WebIDL Level 1"

2015-08-31 Thread Ryosuke Niwa

> On Aug 7, 2015, at 9:27 AM, Anne van Kesteren  wrote:
> 
> On Fri, Aug 7, 2015 at 6:23 PM, Travis Leithead
>  wrote:
>> This is, at a minimum, incremental goodness. It's better than leaving the 
>> prior L1 published document around--which already tripped up a few folks on 
>> my team recently. I strongly +1 it.
> 
> If your team looks at the newer L1 they will also trip themselves up.
> Anything but https://heycam.github.io/webidl/ is problematic.

For our internal documentation purposes, I'd refer having a perm link to a 
document that never changes.

Let's say we implement some feature based on Web IDL published as of today.  
I'm going to refer that in my source code commit message.  Future readers of my 
code has no idea what I was implementing when they look at my commit message in 
five years if it refers to the living standard that changes over time.

- R. Niwa

Re: Shadow DOM spec for v1 is ready to be reviewed

2015-09-01 Thread Ryosuke Niwa

Thanks for the update!

> On Aug 27, 2015, at 11:33 PM, Hayato Ito  wrote:
> 
> Let me post a quick update for the Shadow DOM spec: 
> https://w3c.github.io/webcomponents/spec/shadow/ 
> 
> 
> I've almost done the spec work for Shadow DOM v1. I think it's time to be 
> reviewed and get feedback. I hope that a browser vendor, including me, can 
> start to implement it based on the current spec.
> 
> You might want to use https://github.com/w3c/webcomponents/issues/289 
> 
>  to give me feedback. Please feel free to file a new issue if preferred.

I've filed a bunch of editorial issues.

One conceptual problem I have with the current spec is how it "unwrap" nested 
slots.  I thought we had a consensus not to do this at F2F?  
https://github.com/w3c/webcomponents/issues/308 
 tracks this particular issue.

- R. Niwa

Re: Tests for new shadow DOM API

2015-09-03 Thread Ryosuke Niwa

I think many of them are still relevant.  The key problem I have at the moment 
is that I can't tell which ones are relevant and which ones aren't.  So I 
wanted to create a new directory and migrate or delete the existing tests over 
time.

> On Sep 3, 2015, at 1:19 PM, Travis Leithead  
> wrote:
> 
> Why not deprecate/remove the existing tests in the current folder structure? 
> Presumably we can replace them with new tests that are aligned with the 
> recent spec changes?
>  
> If the existing tests really aren’t relevant anymore, I don’t see a reason to 
> keep them around.
>  
> From: rn...@apple.com [mailto:rn...@apple.com] 
> Sent: Thursday, September 3, 2015 1:07 PM
> To: public-webapps 
> Subject: Tests for new shadow DOM API
>  
> Hi all,
>  
> Where should we put tests for new shadow DOM API?  It looks like the tests in 
> https://github.com/w3c/web-platform-tests/tree/master/shadow-dom/shadow-trees 
> 
>  are mostly obsolete and I'm not certain how many of them could be adopted 
> for the new API.
>  
> Would it make sense to rename this old one to "deprecated-shadow-don" and 
> then create a new top-level directory "shadow-dom"?  We can then migrate or 
> write new tests there.
>  
> - R. Niwa
>

Re: PSA: publish WD of "WebIDL Level 1"

2015-09-01 Thread Ryosuke Niwa


> On Sep 1, 2015, at 7:27 AM, Anne van Kesteren <ann...@annevk.nl> wrote:
> 
> On Tue, Sep 1, 2015 at 4:23 PM, Ryosuke Niwa <rn...@apple.com> wrote:
>> I think you’re missing the point.  The point of these documentation is to 
>> know exactly what the patch author was looking at the time he wrote the 
>> patch.  If there was a typo in the spec, that’s an important information.
>> 
>> As for diff’ing what has changed, that’s exactly the use case.  In order to 
>> know what has changed, you need to know what the old spec was.  The living 
>> standard is a total nightmare as far as I’m concerned.
> 
> I guess it depends on your workflow. In any event, does what Domenic
> suggests and has implemented for 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__streams.spec.whatwg.org_=BQIFaQ=eEvniauFctOgLOKGJOplqw=051zrPFUkWGMfGlKdhy9Uw=dmgoI6lEFOWkspvfnnlq-RxpY4jfiiozATV5kFegnFY=UcHS2fRzjPxSXuZZ0gQQs5xb3C-Ct3peVtowrZdxoUE=
>  
> address your concern?

Yes!  It totally does.

- R. Niwa

Re: PSA: publish WD of "WebIDL Level 1"

2015-09-01 Thread Ryosuke Niwa

> On Aug 31, 2015, at 8:51 PM, Anne van Kesteren <ann...@annevk.nl> wrote:
> 
> On Tue, Sep 1, 2015 at 2:33 AM, Ryosuke Niwa <rn...@apple.com> wrote:
>> Let's say we implement some feature based on Web IDL published as of today.  
>> I'm going to refer that in my source code commit message.  Future readers of 
>> my code has no idea what I was implementing when they look at my commit 
>> message in five years if it refers to the living standard that changes over 
>> time.
> 
> Apart from what Domenic said, IDs should remain stable over time and
> other than features getting expanded, they need to remain backwards
> compatible, just as your code base. (It also seems like useful
> information to know what you've implemented has been refactored or
> changed in some way in the corresponding standard, so you can take
> steps to update your code.)

I think you’re missing the point.  The point of these documentation is to know 
exactly what the patch author was looking at the time he wrote the patch.  If 
there was a typo in the spec, that’s an important information.

As for diff’ing what has changed, that’s exactly the use case.  In order to 
know what has changed, you need to know what the old spec was.  The living 
standard is a total nightmare as far as I’m concerned.

- R. Niwa

Re: Proposal: CSS WG / WebApps Joint Meeting for Shadow DOM Styling

2015-09-30 Thread Ryosuke Niwa


> On Sep 29, 2015, at 8:19 AM, Alan Stearns <stea...@adobe.com> wrote:
> 
> On 9/28/15, 4:49 PM, "rn...@apple.com on behalf of Ryosuke Niwa" 
> <rn...@apple.com> wrote:
> 
> Chaals, Art,
> 
> Do you have a time preference for this? We’ve got one vote for Tuesday 
> afternoon, but I think Monday afternoon could work as well.
> 
> I see that the WebApps WG has a larger person-estimate on the schedule page - 
> if that translates to a larger room, the CSSWG people could troop over to 
> you. Or we could host interested people in the CSSWG room. What do you think?
> 
> Ryosuke,
> 
> We now have “Shadow DOM Styling” on the CSSWG agenda for TPAC [1]. It would 
> help if you could add more detail on the particular issues you’d like ironed 
> out.

Thanks!  I've added tentative agenda on 
https://www.w3.org/wiki/Webapps/October2015Meeting#Potential_Agenda_Topics 
<https://www.w3.org/wiki/Webapps/October2015Meeting#Potential_Agenda_Topics> 
since I don't seem to have edit permissions on 
https://wiki.csswg.org/planning/tpac-2015

- R. Niwa

Proposal: CSS WG / WebApps Joint Meeting for Shadow DOM Styling

2015-09-28 Thread Ryosuke Niwa

Hi,

Attending the recent meeting for shadow DOM styling [1] convinced me to join 
CSS WG, and further that we need a joint meeting between CSS WG and WebApps WG 
on this topic during TPAC to iron out the details.

Can we have a joint meeting (of one or two hours) on Monday (10/26) or Tuesday 
(10/27) for this?

[1] https://www.w3.org/wiki/Webapps/WebComponentsSeptember2015Meeting

- R. Niwa

Re: Apple will host Re: Custom Elements meeting will be 25th Jan (not 29th)

2015-12-08 Thread Ryosuke Niwa


> On Dec 8, 2015, at 2:55 AM, Chaals McCathie Nevile  
> wrote:
> 
> On Mon, 07 Dec 2015 13:39:25 +1000, Chaals McCathie Nevile 
>  wrote:
> 
>> we are trying to shift the date of the Custom Elements meeting to *25* Jan, 
>> from the previously proposed date of 29th.
>> 
>> We are currently looking for a host in the Bay area - offers gratefully 
>> received.
> 
> Apple have kindly agreed to host the meeting, so it will be at 1 Infinite 
> Loop, Cupertino. I'll update the page shortly with logistics information.
> 
> Note that if you are driving, you should allow an extra 10 minutes or so for 
> parking. Carpool!

Added logistics on
https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/25janWC.md

- R. Niwa

Re: Apple will host Re: Custom Elements meeting will be 25th Jan (not 29th)

2016-01-06 Thread Ryosuke Niwa


> On Jan 6, 2016, at 12:05 AM, Takayoshi Kochi (河内 隆仁) <ko...@google.com> wrote:
> 
> Is there any option to attend this remotely (telcon or video conference)?
> 
> 2015年12月9日(水) 10:26 Ryosuke Niwa <rn...@apple.com>:
>> 
>> > On Dec 8, 2015, at 2:55 AM, Chaals McCathie Nevile <cha...@yandex-team.ru> 
>> > wrote:
>> >
>> > On Mon, 07 Dec 2015 13:39:25 +1000, Chaals McCathie Nevile 
>> > <cha...@yandex-team.ru> wrote:
>> >
>> >> we are trying to shift the date of the Custom Elements meeting to *25* 
>> >> Jan, from the previously proposed date of 29th.
>> >>
>> >> We are currently looking for a host in the Bay area - offers gratefully 
>> >> received.
>> >
>> > Apple have kindly agreed to host the meeting, so it will be at 1 Infinite 
>> > Loop, Cupertino. I'll update the page shortly with logistics information.
>> >
>> > Note that if you are driving, you should allow an extra 10 minutes or so 
>> > for parking. Carpool!
>> 
>> Added logistics on
>> https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/25janWC.md

The conference room has a video/telephone conference capability so we should be 
able to set up Webinars assuming someone from W3C can help us set it up.

- R. Niwa

Re: time at TPAC other than Wednesday?

2016-01-09 Thread Ryosuke Niwa


> On Jan 9, 2016, at 12:20 PM, Ryosuke Niwa <rn...@apple.com> wrote:
> 
> 
>> On Jan 8, 2016, at 7:12 PM, Johannes Wilm <johan...@fiduswriter.org> wrote:
>> 
>> On Sat, Jan 9, 2016 at 3:49 AM, Grisha Lyukshin <gl...@microsoft.com> wrote:
>>> Hello Johannes,
>>> 
>>> I was the one to organize the meeting. To make things clear, this was an ad 
>>> hoc meeting with the intent for the browsers to resolve any ambiguities and 
>>> questions on beforeInput spec, which we did. This was the reason I invited 
>>> representatives from each browser only.
>>> 
>> 
>> In so far as to clarify the questions you had at the last meeting that you 
>> needed to resolve with your individual teams, that you had indeed announced 
>> at the meeting that you would talk about --- I think that is fair enough. 
>> 
>> I am not 100% familiar with all processes of the W3C, but from what I can 
>> tell, I don't think you can treat it as having been a F2F meeting of this 
>> taskforce, but you can say that you had some informal talks with your and 
>> the other teams about this and now you come back to the taskforce with a 
>> proposal of how to resolve it.
>> 
>> Similarly, among JS editor developers we have been discussing informally 
>> about priorities and how we would like things to work. But those are 
>> informal meetings that cannot override the taskforce meetings.
> 
> Nobody said our F2F was of the task force.
> 
> Let me be blunt and say this.  I don't remember who nominated you to be the 
> editor of all these documents and who approved it.  If you want to talk about 
> the process, I'd like to start from there.
> 
>>> To your question about removing ContentEditable=”true”. The idea is 
>>> consolidate multiple documents into a single editing specification 
>>> document. We wanted to remove ContentEditable=”true” because it had no 
>>> content there. So resolutions on CE=true from previous meetings remain 
>>> unchanged. There is no point on having empty document floating on the web. 
>>> So yeah, we wanted to remove the draft that has no content. We will merge 
>>> Input Events and other ContentEditable specs into a single spec. We didn’t 
>>> really have any discussions on execCommands spec.
>>> 
>> 
>> Yes, I don't think that part can reasonably be said to have been part of 
>> something you could resolve in a closed door, unannounced meeting among only 
>> browser vendors. 
>> 
>> Both the treatment of the various documents and especially 
>> contentEditable=True has been very controversial in this taskforce in the 
>> past, and I don't think you can just set aside all processes and consensus 
>> methods to change this.
>> 
>> So with all due respect, I don't think you can just delete it like that. 
>> Just as I cannot just delete part of the UI events spec because I have had a 
>> meeting with some people from TinyMCE and CKEditor and we decided we didn't 
>> like that part.
> 
> If the task force comes to a consensus that the document was useful, then we 
> can just restore it.  The change was purely editorial in the nature.  First 
> off, I don't remember when we agreed that we needed to have a separate spec 
> for contenteditable=true separate from Aryeh's document.  If you thought the 
> consensus of the last Paris F2F was to do that, then you either misunderstood 
> the meeting's conclusion or I didn't object in time.
> 
> As far as I'm concerned, this is about removing an empty document the task 
> force never agreed to add in the first place.

Now I realize my Github commit message was very misleading from your 
perspective.  I apologize for causing the confusion.  Nonetheless, we don't 
need a separate contenteditable=true document since that's clearly defined in 
the HTML5 spec as well as Aryeh's spec.

- R. Niwa

Re: time at TPAC other than Wednesday?

2016-01-09 Thread Ryosuke Niwa

> On Jan 9, 2016, at 6:18 AM, Florian Rivoal  wrote:
> 
>> On Jan 9, 2016, at 11:49, Grisha Lyukshin  wrote:
>> 
>> Hello Johannes,
>> 
>> I was the one to organize the meeting. To make things clear, this was an ad 
>> hoc meeting with the intent for the browsers to resolve any ambiguities and 
>> questions on beforeInput spec, which we did. This was the reason I invited 
>> representatives from each browser only.
> 
> Hello,
> 
> Thanks for providing some light on this. However, I must say I am extremely 
> surprised, to say the least.
> 
> Informal discussions between anybody is of course fine. But informal 
> discussions are about discussing, not deciding.

Nobody decided anything there.

> However, as far as I gather, this is a meeting where resolutions were made, 
> issues were resolved, a document of was deleted by someone who is not its 
> editor, despite the editor (who was not invited to the meeting) protesting...

As I explained, the document I removed had no content other than the one 
already present in the HTML5 spec as well as Aryeh's contenteditable spec.  
Furthermore, I don't recall the task force deciding to publish this document in 
the first place.

If anything, I was astounded by the fact this document existed at all, and was 
published as if it were the consensus of the task force.  So the removal was 
purely editorial / administrative in nature.

This is precisely why I haven't made changes or send PRs for other things we 
discussed because that would require the discussion in the task force per the 
W3C process.

If the rest of the participants disagree with that, then I can revert the 
change and bring the document back.

> Forgive me if I'm over reacting, but this doesn't sound like "consensus and 
> due process" to me.

There was no consensus of any sort since this was not a F2F of the task force.  
Removal of the document was NOTHING to do with us deciding anything in the 
closed doors.  I agree my commit message was extremely misleading and I didn't 
provide adequate context in which this was discussed so I apologize for that.

- R. Niwa

Re: time at TPAC other than Wednesday?

2016-01-09 Thread Ryosuke Niwa


> On Jan 8, 2016, at 7:12 PM, Johannes Wilm  wrote:
> 
> On Sat, Jan 9, 2016 at 3:49 AM, Grisha Lyukshin  wrote:
>> Hello Johannes,
>> 
>>  I was the one to organize the meeting. To make things clear, this was an ad 
>> hoc meeting with the intent for the browsers to resolve any ambiguities and 
>> questions on beforeInput spec, which we did. This was the reason I invited 
>> representatives from each browser only.
>> 
> 
> In so far as to clarify the questions you had at the last meeting that you 
> needed to resolve with your individual teams, that you had indeed announced 
> at the meeting that you would talk about --- I think that is fair enough. 
> 
> I am not 100% familiar with all processes of the W3C, but from what I can 
> tell, I don't think you can treat it as having been a F2F meeting of this 
> taskforce, but you can say that you had some informal talks with your and the 
> other teams about this and now you come back to the taskforce with a proposal 
> of how to resolve it.
> 
> Similarly, among JS editor developers we have been discussing informally 
> about priorities and how we would like things to work. But those are informal 
> meetings that cannot override the taskforce meetings.

Nobody said our F2F was of the task force.

Let me be blunt and say this.  I don't remember who nominated you to be the 
editor of all these documents and who approved it.  If you want to talk about 
the process, I'd like to start from there.

>> To your question about removing ContentEditable=”true”. The idea is 
>> consolidate multiple documents into a single editing specification document. 
>> We wanted to remove ContentEditable=”true” because it had no content there. 
>> So resolutions on CE=true from previous meetings remain unchanged. There is 
>> no point on having empty document floating on the web. So yeah, we wanted to 
>> remove the draft that has no content. We will merge Input Events and other 
>> ContentEditable specs into a single spec. We didn’t really have any 
>> discussions on execCommands spec.
>> 
> 
> Yes, I don't think that part can reasonably be said to have been part of 
> something you could resolve in a closed door, unannounced meeting among only 
> browser vendors. 
> 
> Both the treatment of the various documents and especially 
> contentEditable=True has been very controversial in this taskforce in the 
> past, and I don't think you can just set aside all processes and consensus 
> methods to change this.
> 
> So with all due respect, I don't think you can just delete it like that. Just 
> as I cannot just delete part of the UI events spec because I have had a 
> meeting with some people from TinyMCE and CKEditor and we decided we didn't 
> like that part.

If the task force comes to a consensus that the document was useful, then we 
can just restore it.  The change was purely editorial in the nature.  First 
off, I don't remember when we agreed that we needed to have a separate spec for 
contenteditable=true separate from Aryeh's document.  If you thought the 
consensus of the last Paris F2F was to do that, then you either misunderstood 
the meeting's conclusion or I didn't object in time.

As far as I'm concerned, this is about removing an empty document the task 
force never agreed to add in the first place.

- R. Niwa

[UIEvents] [Editing] Ordering of composition events and beforeinput

2016-01-09 Thread Ryosuke Niwa

Hi,

This is a feedback from multiple browser vendors (Apple, Google, Microsoft) 
that got together in Redmond last Thursday to discuss editing API and related 
events.

First off, we found out that there are behavior inconsistencies between 
browsers with respect to composition events.

WebKit, Blink, and Gecko all fire `compositionupdate` events before mutating 
DOM whereas Edge and Trident both requires the event after mutating DOM.  We 
think UIEvent spec should be updated to explicitly make the majority behavior 
(firing the event before mutation DOM) standard.

Since this is a ricky behavioral change for Edge/Trident, we think it's better 
to fire `before input` event prior to firing `compositionupdate` instead of the 
other way around was defined in:
http://w3c.github.io/editing/input-events.html#events-inputevent-event-order

We also found that WebKit and Blink both mutate DOM without firing 
`compositionupdate` at the end of composition on Mac.  Only `compositionend` is 
fired.  We think this is a bug in WebKit/Blink especially since Blink fires 
`compositionupdate` before `compositionend` on Windows.  Therefore, we suggest 
that WebKit/Blink fix this bug, and standardize the behavior whereby which 
`compositionupdate` is fired before mutating DOM prior to firing 
`compositionend`.

Furthermore, the above change to always fire `compositionupdate` eliminates the 
necessity for firing `beforeinput` event prior to firing `compositionend` so we 
suggest we remove this from the input event spec:
http://w3c.github.io/editing/input-events.html#events-inputevent-event-order

That is, we only fire `beforeinput` event before and only before firing 
`compositionupdate`, which shall be fired before every DOM mutation initialized 
by input methods.

- R. Niwa

[UIEvents] Firing composition events for dead keys

2016-01-09 Thread Ryosuke Niwa

Hi all,

This is another feedback from multiple browser vendors (Apple, Google, 
Microsoft) that got together in Redmond last Thursday to discuss editing API 
and related events.


We found out that all major browsers (Chrome, Firefox, and Safari) fire 
composition events for dead keys on Mac but they don't on Windows.  I think 
this difference comes from the underlying platform's difference but we think we 
should standardize it to always fire composition events for consistent behavior 
across platforms.

Does anyone know of any implementation limitation to do this?  Or are there any 
reason we should not fire composition events for dead keys on Windows?

- R. Niwa

[UIEvents] [Editing] Moving input/beforeinput events into UI events

2016-01-09 Thread Ryosuke Niwa

Hi all,

This is another feedback from multiple browser vendors (Apple, Google, 
Microsoft) that got together in Redmond last Thursday to discuss editing API 
and related events.


As we discussed various aspects of composition events and beforeinput/input 
events, it became apparent that we want both composition events and 
beforeinput/input events to be defined in a single spec since the ordering of 
these events as well as what happens when their default actions are canceled or 
event propagations are stopped are interdependent among them.

Thus, we think it's better to define the basic event interface as well as the 
timing at which these events are fired in UI events, and define `editType` and 
associated default editing actions in a separate editing spec.

That is, we suggest merging everything in:
http://w3c.github.io/editing/input-events.html
into
https://w3c.github.io/uievents/

except the parts that define the list of values for `editType` and `data` 
(since the content of `data` depends on the type of `editType`), and define the 
latter two in the editing spec that defines these properties' values as well as 
their behaviors:
http://w3c.github.io/editing/contentEditable.html


- R. Niwa

[UIEvents] Keydown/keyup events during composition

2016-01-09 Thread Ryosuke Niwa

Hi all,

This is another feedback from multiple browser vendors (Apple, Google, 
Microsoft) that got together in Redmond last Thursday to discuss editing API 
and related events.


We've been informed that Gecko/Firefox does not fire keydown/keyup events 
during input method composition for each key stroke.  Could someone from 
Mozilla clarify why this is desirable behavior?

We think it's better to fire keydown/keyup events for consistency across 
browsers.  If anything authors can detect that a given keydown/keyup event is 
associated with input methods by listening to composition events as well.

- R. Niwa

[Editing] Adding `dataTransfer` to `InputEvent` interface

2016-01-09 Thread Ryosuke Niwa

Hi,

This is yet another feedback from multiple browser vendors (Apple, Google, 
Microsoft) that got together in Redmond last Thursday to discuss editing API 
and related events.


It came to our attention that `beforeinput` event fired for paste would need to 
expose HTML (or images, etc...) instead of plain text.  To expose that data, we 
suggest to add `dataTransfer` property on the `InputEvent` interface to expose 
these non-plaintext contents.

As suggested in
https://lists.w3.org/Archives/Public/public-webapps/2016JanMar/0025.html

we suggest doing so in:
http://w3c.github.io/editing/contentEditable.html
as a partial interface definition for `InputEvent` which defines `data`, 
`dataTransfer`, and `editType` IDL attributes.

- R. Niwa

[Editing] [DOM] Adding static range API

2016-01-09 Thread Ryosuke Niwa

Hi,

This is yet another feedback from multiple browser vendors (Apple, Google, 
Microsoft) that got together in Redmond last Thursday to discuss editing API 
and related events.

For editing APIs, it's desirable to have a variant of Range that is immutable.  
For example, if apps were to create an undo stack of its own, then storing the 
selection state using Range would be problematic because those Ranges would get 
updated whenever DOM is mutated.  Furthermore, live ranges are expensive if 
browsers had to keep updating them as DOM is mutated.  This is analogous to how 
we're moving away form LiveNodeList/HTMLCollection to use StaticNodeList in 
various new DOM APIs.

So we came up with a proposal to add StaticRange: a static, immutable variant 
of Range defined as follows:

[Constructor,
 Exposed=Window]
interface StaticRange {
  readonly attribute Node startContainer;
  readonly attribute unsigned long startOffset;
  readonly attribute Node endContainer;
  readonly attribute unsigned long endOffset;
  readonly attribute boolean collapsed;
  readonly attribute Node commonAncestorContainer;

  const unsigned short START_TO_START = 0;
  const unsigned short START_TO_END = 1;
  const unsigned short END_TO_END = 2;
  const unsigned short END_TO_START = 3;
  short compareBoundaryPoints(unsigned short how, Range sourceRange);

  [NewObject] 
Range cloneRange();

  boolean isPointInRange(Node node, unsigned long offset);
  short comparePoint(Node node, unsigned long offset);

  boolean intersectsNode(Node node);
};

Along with range extensions from CSS OM view also added as follows:
https://drafts.csswg.org/cssom-view/#extensions-to-the-range-interface

partial interface StaticRange
 {
  [NewObject] sequence getClientRects();
  [NewObject] DOMRect getBoundingClientRect();
};

with one difference, which is to throw an exception (perhaps 
InvalidStateError?) when StaticRange's boundary points don't share a common 
ancestor, not in a document, or offsets are out of bounds.

- R. Niwa

Re: [UIEvents] Firing composition events for dead keys

2016-01-09 Thread Ryosuke Niwa

> On Jan 9, 2016, at 6:33 PM, Olli Pettay <o...@pettay.fi> wrote:
> 
> On 01/10/2016 01:14 AM, Ryosuke Niwa wrote:
>> Hi all,
>> 
>> This is another feedback from multiple browser vendors (Apple, Google, 
>> Microsoft) that got together in Redmond last Thursday to discuss editing API 
>> and related events.
>> 
>> 
>> We found out that all major browsers (Chrome, Firefox, and Safari) fire 
>> composition events for dead keys on Mac but they don't on Windows.  I think 
>> this difference comes from the underlying platform's difference but we think 
>> we should standardize it to always fire composition events for consistent 
>> behavior across platforms.
>> 
>> Does anyone know of any implementation limitation to do this?  Or are there 
>> any reason we should not fire composition events for dead keys on Windows?
>> 
> 
> Does anyone know the behavior on Linux.
> 
> What is the exact case you're talking about here? do you have a test case?

Sure. On Mac, you can enable International English keyboard and type ' key and 
then u.

On Mac:
1. Pressing ' key inserts ' (character) and fires `compositionstart` event.
2. Pressing u key replaces ' with ú and fires `compositionend`.

On Windows, dead key doesn't insert any character at all, and pressing the 
second key insert the composed character.

Looking at MSDN:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms646267(v=vs.85).aspx#_win32_Dead_Character_Messages

dead key should issue WM_KEYDOWN as well as WM_DEADCHAR in TranslateMessage so 
I don't think there is an inherent platform limitation to fire composition 
events.

- R. Niwa

< 1 2 3 4 5 6 >

401 - 500 of 522 matches

Mail list logo