Skip to content

[scroll-animations-1] Three-value animation-range shorthand notation #8672

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
fantasai opened this issue Apr 3, 2023 · 7 comments
Closed

Comments

@fantasai
Copy link
Collaborator

fantasai commented Apr 3, 2023

Currently animation-range is defined with the following syntax:

animation-range: [ <<'animation-range-start'>> <<'animation-range-end'>>? ]#

We added the following rules:

  • In the longhands, as well as in the shorthand, if a range name is given but the offset is omitted, it defaults to 0% for -start and 100% for -end.
  • In the shorthand, if the second value is omitted and the first value has a range name, it copies the range name from the first and takes a 100% offset. (The second value otherwise defaults to the initial value, normal).

What we didn't discuss was what happens if two offsets and a keyword were specified, e.g.

animation-range: contain 10% 90%;
animation-range: 10% contain 90%;

These don't fall under the special range-name duplication rules we decided in #8438, so the standard behavior that falls out is:

animation-range: contain 10% 90%;
animation-range-start: contain 10%;
animation-range-end: 90%;

animation-range: 10% entry 90%;
animation-range-start: 10%;
animation-range-end: contain 90%;

We have several options here:

  • Assign the longhand values exactly as specified (see above).
  • Extend the range name duplication rule to apply to also apply to double offset values.
    • In this case, such longhand combinations would not have a serialization in the shorthand, unless we made some more explicit serialization like “normal 10%” also valid and equal to “10%”. See suggestion from @cdoublev.
  • Make these types of values (two offsets, one keyword) invalid.

Imho, while making contain 10% 90% expand to contain 10% contain 90% seems nice, doing that for the analogous 10% contain 90% makes a bit less sense, and I'm not sure that making “normal” act like a range is a good idea, since it's supposed to represent the absence of a range restriction... And making them invalid seems unnecessary work, since these syntaxes are normal consequences of a basic shorthanding relationship. So I'm inclined to go for the first option. Thoughts?

@ydaniv
Copy link
Contributor

ydaniv commented Apr 7, 2023

I think we need to have a general rule for ranges without names. For example, how does 100px 20vh expand? Or 20% 80%?
My suggestion is to always expand a missing name to the full range of the attached timeline. In case of a ScrollTimeline this should work as expected.
In case of a ViewTimeline this would be the entire cover range.
For future timelines, say HoverTimeline, this could be the viewport, and so on.
@fantasai I think that's what you meant by using normal here?

@flackr
Copy link
Contributor

flackr commented May 12, 2023

@fantasai I agree with your conclusion that going with option 1 makes sense.

@ydaniv yes that is my understanding as well, the intention is that not specifying a range associates with the "normal" or default range so either of the things you specified would be over the entire scroll timeline range or cover view timeline range.

@flackr
Copy link
Contributor

flackr commented May 12, 2023

Though thinking about this further, we may want an omitted range with specified value for ViewTimeline to refer to the entire scroll range. This would allow doing things with absolute pixel offsets, allowing things such as what was discussed here: #8578 (comment)

@ydaniv
Copy link
Contributor

ydaniv commented May 13, 2023

Agreed. Example: animating an element that scrolls into view, becomes sticky, and then remains sticky till end of document, but animates all the way, or until an absolute point:

.sticky {
  position: sticky;
  top: 0;
  animation: hue-rotate both view();
  animation-range: entry 0% 100%;
}

@fantasai
Copy link
Collaborator Author

fantasai commented Jun 2, 2023

@flackr An issue with that is that animation-range: normal needs to map to the cover range on view timelines; making animation-range: 10% 90% use a completely different range than normal seems unexpected?

@ydaniv
Copy link
Contributor

ydaniv commented Jun 6, 2023

@fantasai I think it's fine, having a specified %'s value that will behave differently from normal.

Also need to consider what happens in case of animation-range: 100px 1000px, should be the same, right?

@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed [scroll-animations-1] Three-value `animation-range` shorthand notation, and agreed to the following:

  • RESOLVED: No change
The full IRC log of that discussion <dael> fantasai: We have an animation-range shorthand for start and end. Can take keyword, length, % or both one after the other. Means you can do 2 or 3 component values
<fantasai> animation-range: 10% entry 90%;
<fantasai> animation-range: contain 10% 90%;
<dael> fantasai: Question was what's best way to interpret a 3 component value. Examples ^
<dael> fantasai: Could do exactly as specified. Another is make these invalid. Third is duplicate the keyword which feels a little odd in the first example.
<dael> fantasai: flackr had another though?
<dael> flackr: It was that no spec range would refere to max-range of the timeline. So it's larger than the cover range for view timelines
<dael> fantasai: That feels independant from how to assign 3 value
<dael> flackr: It is, but gives meaningful value to things without range
<dael> fantasai: Animation-range 10% 90% would go from 10-90% of cover
<dael> flackr: Then I think we shouldn't do magic with range names in 3 value
<dael> Rossen_: Does that leave us no change?
<dael> fantasai: I think that is current state
<dael> fantasai: First option, assign long hand values as specified
<fantasai> s/would go/currently goes/
<dael> florian: When you have % keyword % is it unambig by ordering?
<dael> fantasai: Yes. animation-range requires keyword first
<dael> florian: Good
<dael> Rossen_: Do we need a resolution?
<dael> flackr: resolve to keep as is?
<dael> Rossen_: no change
<dael> Rossen_: Objections?
<dael> RESOLVED: No change
<dael> fantasai: I brought this because we hadn't talked about the 3-value option so needed to cover

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants