Skip to content

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

Closed
@fantasai

Description

@fantasai

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?

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions