Re: [csswg-drafts] [scroll-animations] Broader scope of scroll timelines (#7759)

tldr: I really don't like the way that `defer` works in the syntax; the ability of authors to write `scroll-timeline: foo block defer;` seems genuinely confusing/contradictory. I have two suggestions for fixing it: one eliminates `-attachment` entirely and folds the functionality into `-name` and `-axis`; the second just shifts the `defer` keyword into `-axis` so you can't specify it and an axis at the same time. Neither of these change the processing model at all from what the current spec specifies, or introduce any new concepts; they're *purely* syntax rearrangements.


-----

Hm, giving it more thought, I'm still thinking that the current solution feels very artificial; even with the better editorial text, it feels like -attachment was designed and bolted onto an existing -name/-axis pair (which it effectively was) rather than being designed as part of it from the start. Depending on the value of this third property, one property changes behavior (creating a timeline, or looking up a timeline) and another is either used or ignored. This sort of mode-switching is not common in CSS, and it's weird for it to be cascaded separately, too.

So, like, the the fundamental deal is still that you have two operations (define a timeline scope, and attach a scrolling axis to a timeline in scope) and want to do either or both of them (and when doing both, you want them linked together implicitly). When you're doing both, the current split of properties already maps perfectly to the two tasks: `-name` defines the scope, and `-axis` attaches the scrolling axis. 

Ideally we'd be able to handle the two single-operation scenarios just by modifying the necessary property. Here's one more sketch that does precisely that, as simply as possible:

```
scroll-timeline-name: none | [ <custom-ident> [ root | ancestor ]? ]#
scroll-timeline-axis: [ block | ... | defer ]#
```

`-name` can either be in `root` mode (creates a timeline of the given name) or `ancestor` mode (looks for an ancestor of the given name). If omitted, defaults to `root`.

`-axis` either attaches the given scrolling axis to the timeline selected by `-name`, or does nothing (if `defer`). If omitted, defaults to `block`.

This allows the useless combination of `scroll-timeline: foo ancestor defer;`, which does nothing. But I think this is less confusing than the current spec's `scroll-timeline: foo block defer;` possibility, which is genuinely *unclear* in whether it attaches the attaches the block scrolling axis to `foo` or defers it.

I think the cascade behavior is slightly more reasonable, too. 

(We *could* eliminate the possibility of a useless/confusing combo entirely, by instead moving the `ancestor` keyword down to `-axis`, with a grammar of ` [ [ block | ... ] [ local | ancestor ]? | defer]`, but I think that's a little more confusing in different ways, since the `-axis` value would be changing the interpretation of `-name`. It also makes it look like you're referring to the block axis of an ancestor, rather than using *your* block axis *for* an ancestor.)

-------

Or here, one final possibility if we are really attached to `-attachment` and want a minimal edit from the current spec. The thing that's really getting my goat here is that the `defer` value causes us to ignore `-axis`, but we can still specify it.

```
scroll-timeline-name: <custom-ident>#;
scroll-timeline-axis: [ block | ... | defer]#;
scroll-timeline-attachment: [ local | ancestor ]#
```

All values are treated exactly as the spec currently defines, it's just that the `defer` keyword is moved *to* the `-axis` property, which prevents you from specifying it alongside an axis in the shorthand. This also means that now `-attachment` merely changes the interpretation of `-name`, which is a little less unusual for CSS things.

This, similarly, allows the no-op shorthand value of `foo defer ancestor`, but as I said above I think that's better than the current conflicting value of `foo block defer`.

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


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

Received on Tuesday, 25 April 2023 21:04:09 UTC