When is the slotting algorithm run

[annevk]

Searching for "slotting algorithm" does not find any callers. That does not seem right.

[annevk]

I'm assuming we have to run this whenever the tree or shadow tree is modified?

Might it be better to define it lazily what assignedSlot returns and how getAssignedNodes() works? Are there any other potential consumers?

[rniwa]

The CSS box generation requires the flattened tree. I don't think there is any point in making the spec run this algorithm lazily. We can spec it to run whenever DOM gets mutated and implementors can do the work lazily as an optimization.

[annevk]

That would mean though that without optimization we'd have to run this each mutation, for each node in the tree, including any associated shadow trees, and their associated shadow trees, etc., since slot elements could get removed or moved, children of host elements could get moved, etc.

It seems easier to specify this as a lazy algorithm if this is only used for assignedSlot and getAssignedNodes().

(I'm assuming you mean the "slotting algorithm" and not the "flatted tree algorithm" when you say "this algorithm".)

[rniwa]

In that case, I'd suggest writing two algorithms. One that finds (slot name, slot element) pairs in a given node tree and another one that creates a list of (slot name, list of assigned nodes) pairs from the child nodes of a shadow host.

The first algorithm is implemented in WebKit at:
http://trac.webkit.org/browser/trunk/Source/WebCore/dom/SlotAssignment.cpp#L187

The second algorithm is implemented in WebKit at:
http://trac.webkit.org/browser/trunk/Source/WebCore/dom/SlotAssignment.cpp#L217

[annevk]

Seems reasonable.

@hayatoito I think this is one of the main problems with the specification. That while algorithms are defined, it's unclear where these algorithms are plugged into the rest of the system.

[hayatoito]

I added dfn.js to the spec. It looks that the (reverse) dependency is:

"slotting algorithm": http://w3c.github.io/webcomponents/spec/shadow/#dfn-slotting-algorithm
  ->  "assigned slot": http://w3c.github.io/webcomponents/spec/shadow/#dfn-assigned-slot
    ->  "assigned": http://w3c.github.io/webcomponents/spec/shadow/#dfn-assigned
      ->  "get assigned nodes algorithm": http://w3c.github.io/webcomponents/spec/shadow/#dfn-get-assigned-nodes-algorithm
        ->  "assigned nodes": http://w3c.github.io/webcomponents/spec/shadow/#dfn-assigned-nodes
          -> "distributed nodes algorithm": http://w3c.github.io/webcomponents/spec/shadow/#distributed-nodes-algorithm
            -> "distributed nodes" for a slot: http://w3c.github.io/webcomponents/spec/shadow/#dfn-distributed-nodes
              -> "flattening algorithm": http://w3c.github.io/webcomponents/spec/shadow/#dfn-distributed-nodes
                -> "flat tree": http://w3c.github.io/webcomponents/spec/shadow/#dfn-flat-tree
                   -> In resolving CSS inheritance, an element must inherit from the parent node in the flat tree, if applicable.
                   -> .. others
              -> "getAssignedNodes" method
        -> "getAssignedNodes" method

Thus, the consumers are getAssignedNodes() and (how to construct) a flat tree.

It seems easier to specify this as a lazy algorithm if this is only used for assignedSlot and getAssignedNodes().

Yes, that's my intention. I thought that we can keep the spec simple by this laziness (declarative) definition. I would like to avoid to specify the timing when these algorithms are run.

[annevk]

When I click on slotting algorithm it says "No references in this file."

I don't think the current approach works. There's a couple of places where it's observable whether or not the algorithm has run. Either you need to just hook into mutation or you need to make sure it's run by the time it's being observed. Currently it doesn't really seem like either is required.

[hayatoito]

The dependency (slotting algorithm -> assigned slot) exists in the following sentence.

The slotting algorithm must be used to determine the assigned slot for a node and must be equivalent to processing the following steps:

I don't think the current approach works. There's a couple of places where it's observable whether or not the algorithm has run. Either you need to just hook into mutation or you need to make sure it's run by the time it's being observed. Currently it doesn't really seem like either is required.

Should we clarify the timing? AFAIR, the spec had a sentence, such as:

The composed tree must be updated before the rendering occurs.

However, I removed this sentence because this sentence does not define anything.
I thought that declarative (lazy?) definition was the last hope for us.

As a dependency shows, we need to define the timing when we should construct a "flat tree", ultimately, if we are to define the timing exactly. I have no idea how to define it nicely.

[annevk]

My current approach in defining this in the DOM Standard is to basically define algorithms similar to those in Shadow DOM "find a slot", "find slotables", "find distributed slotables", and invoke those from places such as assignedSlot and getAssignedNodes() (not yet defined, to be done in HTML).

The CSS specification for Shadow DOM will have to deal with the flattened tree and maybe even define that in detail since that is largely immaterial to DOM (it doesn't affect event dispatch or any API).

WDYT?

[hayatoito]

It sounds good.
Yeah, CSS specification might have to consider this issue more seriously, however, in DOM and HTML Standard, the approach should work, I think.

[annevk]

Given #288 this approach is no good, but it also seems this is a duplicate of that. To solve #288 we need to carefully define when nodes get assigned to slots.