My concern with this is that it means that anytime that a node is inserted anywhere, we need to recheck the insertion-point for all of its siblings.

Adding William who can comment more on the performance implications of this.

I would really much prefer if there was an imperative way to add content; the <content> element is un-ergonomic and very hard to use in a sensible way. I am hearing this feedback from multiple developers as I try to show them shadow DOM.

I know there is already an open issue for this (bug 18429) but I thought it was relevant since this bug seems to be about putting lipstick on the <content> pig, whereas we could instead try to create something non-pig-like.

Anyway that's the last I'll say on the subject to avoid derailing further; we can continue discussing the imperative API in bug 18429.

(In reply to Jonas Sicking from comment #1)
> My concern with this is that it means that anytime that a node is inserted
> anywhere, we need to recheck the insertion-point for all of its siblings.

Same concern here. The problem with :first-of-type is that it involves walking previous siblings to check this condition when multiple children are inserted via document fragments.

(In reply to Domenic Denicola from comment #2)
> I would really much prefer if there was an imperative way to add content;
> the <content> element is un-ergonomic and very hard to use in a sensible
> way. I am hearing this feedback from multiple developers as I try to show
> them shadow DOM.
> 
> I know there is already an open issue for this (bug 18429) but I thought it
> was relevant since this bug seems to be about putting lipstick on the
> <content> pig, whereas we could instead try to create something non-pig-like.

Yes. In fact, we (Apple) would argue that we should implement the imperative API first.

(In reply to Jonas Sicking from comment #1)
> My concern with this is that it means that anytime that a node is inserted
> anywhere, we need to recheck the insertion-point for all of its siblings.
> 
> Adding William who can comment more on the performance implications of this.

That is not specific to the ':first-of-type'. We have to recalculate distributions whenever a node is inserted whether matching criteria has ':first-of-type' or not.

(In reply to Ryosuke Niwa from comment #3)
> (In reply to Jonas Sicking from comment #1)
> > My concern with this is that it means that anytime that a node is inserted
> > anywhere, we need to recheck the insertion-point for all of its siblings.
> 
> Same concern here. The problem with :first-of-type is that it involves
> walking previous siblings to check this condition when multiple children are
> inserted via document fragments.

Right. I guess this is one of the pseudo classes which is difficult to implement without performance impact.
In general, we need *virtual siblings traversal* for Tree-Structural pseudo-classes.
http://dev.w3.org/csswg/selectors4/#structural-pseudos


For reference:
Chromium side bug is here: https://code.google.com/p/chromium/issues/detail?id=343332
In blink, we already supported some of pseudo classes. To implement these in blink, we (especially shinyak@chromium.org) had to use a technique of C++'s template so that we could overcome perf concern. There is a technical difficulty.


> 
> (In reply to Domenic Denicola from comment #2)
> > I would really much prefer if there was an imperative way to add content;
> > the <content> element is un-ergonomic and very hard to use in a sensible
> > way. I am hearing this feedback from multiple developers as I try to show
> > them shadow DOM.
> > 
> > I know there is already an open issue for this (bug 18429) but I thought it
> > was relevant since this bug seems to be about putting lipstick on the
> > <content> pig, whereas we could instead try to create something non-pig-like.
> 
> Yes. In fact, we (Apple) would argue that we should implement the imperative
> API first.

(In reply to Hayato Ito from comment #4)
> (In reply to Ryosuke Niwa from comment #3)
> > (In reply to Jonas Sicking from comment #1)
> > > My concern with this is that it means that anytime that a node is inserted
> > > anywhere, we need to recheck the insertion-point for all of its siblings.
> > 
> > Same concern here. The problem with :first-of-type is that it involves
> > walking previous siblings to check this condition when multiple children are
> > inserted via document fragments.
> 
> Right. I guess this is one of the pseudo classes which is difficult to
> implement without performance impact.
> In general, we need *virtual siblings traversal* for Tree-Structural
> pseudo-classes.
> http://dev.w3.org/csswg/selectors4/#structural-pseudos

I don't think we should be supporting these pseudo selectors in the level 1 specification when we could easily support the use case by adding a simple imperative API for it given the performance impact.  In fact, such an imperative API would support more use cases such as an element that picks a random child element upon click.

I'd go as far as to say we wouldn't implement this even if it were in the spec.

(In reply to Domenic Denicola from comment #2)
> I would really much prefer if there was an imperative way to add content;
> the <content> element is un-ergonomic and very hard to use in a sensible
> way. I am hearing this feedback from multiple developers as I try to show
> them shadow DOM.
> 
> I know there is already an open issue for this (bug 18429) but I thought it
> was relevant since this bug seems to be about putting lipstick on the
> <content> pig, whereas we could instead try to create something non-pig-like.
> 
> Anyway that's the last I'll say on the subject to avoid derailing further;
> we can continue discussing the imperative API in bug 18429.

I think it would be very helpful for browser vendors to hear what reactions actual web developers are having with <content> that make them feel the need of an imperative API as a first draft.

Could we have that conversation in 18429 as you suggested?

Thanks!

Let me add a support for pseudo-classes in the matching criteria.

Please feel free to re-open this issue if you have further objections.

- I guess lack of pseudo-classes support in the matching criteria in the spec is  simply a kind of mistake of the spec editors. That should have been there.
- In blink, we've successfully supported structural pseudo classes with zero-overhead in theory.

I've updated the spec at https://github.com/w3c/webcomponents/commit/45eda3bf9ca2c67f47a3ae4e267cdd6776a4a2c1

Apple objects to this resolution on two basis:
1. Explaining details and fieldset itself isn't a use case.
2. We can't implement this feature efficiently

Reopening the bug.

I agree. I'd prefer to see these usecases solved through an imperative API.

I don't understand how you're planning on solving the performance issues involved here? Without the change here, it appears that whenever a node is changed, we only need to check if that affect where that node itself is inserted. With this change we now have to recheck where are all its siblings are inserted too.

Either way, adding more complex selectors will only get you so far. An imperative API will always be needed so I think we should start there.

Thank you for the comments.

Let me share my experience in blink's implementation, hoping that would be helpful for us to address perf's concern.
I am aware that this is just one example and the explanation doesn't apply to any implementation. However, I think it is very important for us to share our experience.


The change here, adding pseudo-classes to the matching criteria, would not have any impact of timing of re-calculation of distribution in blink.
If a node is inserted somewhere, the *dirty* flag is always set to *inclusive ancestor* nodes of the node, in a sense of tree of trees, and we will run distribution algorithm (*1) anyway later. All these things already need dynamic check.

The change here had an impact only on the following process in the pool distribution algorithm (*2) in blink's implementation:

> If NODE satisfies CONTENT's matching criteria:

Here, blink did some efforts to share the common logic between (existing) CSS selectors and matching criteria uses in content insertion points.
The big difference between them is that nodes in POOL doesn't have *physical* siblings relationships. We can't use normal node->nextSibling in a DOM tree here because nodes in POOL requires the different *virtual* sibling traversal strategy. To share the common selector matching long nicely here, we had to introduce DOMSiblingTraversalStragegy, which is an abstraction how we traverse node's siblings. We used a kind of C++ template technique here so that this doesn't any performance impact on normal CSS selector's matching, which uses *normal* sibling traversal.


I am afraid that this is too implementation detail and might not be discussed in the spec bug, however, I am happy to provide any further information!


As for the imperative API, let's discuss how imperative API should be in bug 18429. I'll join the discussion.
I hope the discussion in bug 18429 would have a good impact.



*1. http://w3c.github.io/webcomponents/spec/shadow/#distribution-algorithms
*2. http://w3c.github.io/webcomponents/spec/shadow/#dfn-pool-population-algorithm

For the moment, let's concentrate on enabling first-of-type use case with imperative API. I reverted the original change in https://github.com/w3c/webcomponents/commit/a9583c299c4a30d9a462efd6e05438ded9926b25

*** Bug 26552 has been marked as a duplicate of this bug. ***