Re: [csswg-drafts] [css-view-transitions-1] Prose to modify pseudo-trees (#8113)

Fwiw, I think the approach I would take is to define the view transition pseudo-elements as forming a tree, and define what that tree is by description rather than by algorithm. In general I prefer describing what the structure _is_ to describing how to build it; I just find definitions easier to understand than trying to compile and run piles of algorithms in my head. :/ Sometimes it's not possible to do that, but in that case I usually fully describe the target model first, and write up the algorithms to build it as an expansion of that definition. Having the ultimate model defined descriptively puts the algorithm into context: we know what we're trying to do, and why, and how it all fits together in the end.

(Think about how you describe the view transition tree to the CSSWG: you don't walk us through all the algorithms for building it; you say that there's a tree of pseudo-elements, the root is ::view-transition, and it has these children, and they have those children... Of course the spec has to be more precise, but it can often do that that by being more detailed rather than taking a fundamentally different approach.)

Anyway, our goal is to optimize understandability of the spec without sacrificing precision. In that light, defining what a tree structure is, the fact that its node have parents, what a descendant is, etc. is unnecessary. These are all commonly understood concepts in our field, so there's no actual spec ambiguity to clear up by defining them. Therefore, creating an algorithmic definition of them just makes the spec longer and harder to read.

The question to ask is, where is the spec actually ambiguous? And clear that up. Afaict all you need to define is that you're building a tree of pseudo-elements, and that appending one pseudo-element to another one means appending it to its child list. You can make that a local definition; same with a pre-insert term, if you need one; “remove” should work fine here with just its English definition.

The reason DOM needs to define everything in detailed algorithms is because it it has complex input arguments to process and has to time various observable side-effects of the tree-building process such as events. We're not dealing with that here, so we can take shortcuts like relying on commonly understood definitions of common words.

> @fantasai @tabatkins are you aware of any other specs that have ran into this?

I'm not aware of any other CSS spec that tries to build a pseudo-element tree. :) Let's do things locally here, and if we need to generalize it later we can refactor the concept.

-- 
GitHub Notification of comment by fantasai
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8113#issuecomment-1338816562 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 6 December 2022 06:09:35 UTC