Define the timing when distribution happens

[hayatoito]

Title: [Shadow]: Specify distribution in terms of event loop (bugzilla: 28443)

Migrated from: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28443

---

comment: 0
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28443#c0
Dimitri Glazkov wrote on 2015-04-08 15:58:31 +0000.

From https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0052.html

Currently, the spec is not very precise about when distribution happens:

"If any condition which affects the distribution result changes, the distribution result must be updated before any use of the distribution result."

This results in difficulty for interoperability, as the exact timing of when affects change is hard to reason across browsers.

Instead, it needs to define when exactly the distribution algorithm runs. For example, we could have tied it to the timing of style calculation, because distribution algo always runs before style calculation.

Is the timing of style calculation specified?

[annevk]

I no longer think this is a problem. All the features that are DOM observable will just invoke algorithms synchronously to get the nodes they need (and typically they don't need distributed nodes, only getAssignedNodes() does that iirc). And CSS can compute the flat tree whenever it wants.

[hayatoito]

I think a potential consumer of this issue is #288.
In DOM Standard, we do not need to depend on this issue.

[annevk]

Hmm, right, I discovered that yesterday too. For that the DOM Standard absolutely needs to be revamped in some way. If we address that we can no longer lazily evaluate slots and slotables. We'll have to run those algorithms as part of insertion/removing and queue something for an event/mutation record.

[hayatoito]

Yeah, I agree. "slotchange" event is difficult to define, if we are to define the exact condition which triggers the event in such an imperative way. I am not sure it is possible. That's the reason I could not be supportive this feature so far.

[annevk]

It seems easy enough to define since we already define insert/remove. We just need to make insert/remove also run some kind of slotting algorithm. That's not going to be inexpensive, but hopefully implementations can find ways to optimize.

[annevk]

Okay, so DOM now defines slotting and has https://dom.spec.whatwg.org/#find-flattened-slotables to define assignedNodes(). I don't think anything else depends on timing here, correct?

[hayatoito]

Yeah, I think we can close this now.

One remaining concern is a flat tree. Its client is CSS.

However, as long as the assigned nodes are calculated synchronously in each DOM mutation, we do not need any other timing to define a flat tree because its structure is uniquely decided by the information of the assigned nodes.

[trusktr]

One remaining concern is a flat tree. Its client is CSS.

It's client is also my library, or any library similar to http://aframe.io which uses custom elements to render to WebGL or any other rendering target outside of DOM; and this is under the assumption that such a library wants to be ShadowDOM-compatible.

At the moment, A-Frame has expressed that they do not wish to be ShadowDOM-compatible, and their library currently breaks when you try to use it with ShadowDOM.

As for my library, I'm working on the solution here, and it involves hijacking attachShadow as well as needing to know which elements are assigned/unassigned to slots in order to know the positions that they are rendered relative to in a render tree (basically this means being able to track the "flat tree").