-
Notifications
You must be signed in to change notification settings - Fork 707
[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
Comments
I think we need to have a general rule for ranges without names. For example, how does |
@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. |
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) |
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%;
} |
@flackr An issue with that is that |
@fantasai I think it's fine, having a specified Also need to consider what happens in case of |
The CSS Working Group just discussed
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 |
Currently
animation-range
is defined with the following syntax:We added the following rules:
normal
).What we didn't discuss was what happens if two offsets and a keyword were specified, e.g.
These don't fall under the special range-name duplication rules we decided in #8438, so the standard behavior that falls out is:
We have several options here:
Imho, while making
contain 10% 90%
expand tocontain 10% contain 90%
seems nice, doing that for the analogous10% 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?The text was updated successfully, but these errors were encountered: