Parse full animation-range syntax

[johannesodland]

Implements parsing the full animation-range syntax to fix #236

Changes:

• Implement parsing of animation-range in parseAnimationRange()
  • Extract common parsing functionality into consumeRange()
• Additional typed-css-om functionality and fixes to be able to validate length-percentage:
  • Implement add two types from css-typed-om (needed for validating length-percentage)
  • Make create a type case insensitive
• Change how <length-percentage> in rangeStart/End is stored and returned:
  • from CSS.percent(0)
  • to { rangeName: 'none', offset: CSS.percent(0)}
• Add vitest for unit-tests
• Write unit tests for
  • CSSNumericType.type()
  • Parsing animation-range

The tests for animation-range are not strictly unit tests and tests the implementation through the internal parseAnimationRange() function. The functionality is currently only exposed through css parsing which makes it difficult to test. We could expose the parsing partly through CSSStyleValue.parse('animation-range', value) but then we would have to proxy that method in all browsers.

[bramus]

Did a (very) quick pass, left some remarks.

[bramus]

I see you lowercased this here, yet in test/unit/cssom/css-numeric-value-type.test.js the unit is uppercase

[johannesodland]

I lower-cased the units here, as the units should be case insensitive. (Both new CSSUnitValue(5, 'Q').type() and new CSSUnitValue(5, 'q').type() should return {length: 1}.)

Q was the odd unit out, and I think its better to keep the representation of the units in lower case, in stead of changing the case om the fly when checking units.

The upper-case Q in the test is copy paste from before the unit was lower cased.
Come to think of it, the unit tests should probably test the units with both upper and lower case 🤔.

Talking about units, we have some case sensitivity issues in the cssom polyfill if you create a CSSUnitValue() or run CSSNumericValue.parse() with upper-case units. Units are then stored and serialized in uppercase, while Safari and Chrome will return them in lowercase. It should be simple to fix, but I'll save it for another PR :)

[johannesodland]

Added tests for both upper and lower case units when creating a CSSUnitValue and checking its type in 326fc3b.

The spec (and webkit) seems to require lower case 'number' and 'percent' unit, while blink supports both casings. Aligned with webkit and the spec.

[bramus]

One of the things that was present in the previous implementation is that it checked whether the passed in range made sense for the type of timeline or not. E.g. passing incover 20% does not make sense for a regular ScrollTimeline.

With this functionality removed here now, do we check it elsewhere before it’s actually used?

[johannesodland]

As I understand it, the syntax allows for both <length-percentage> and <timeline-range-name> <length-percentage>? which makes sense since animation-range is a property of the animation and not the timeline.

The values are checked when used.

When <length-percentage> is defined on a view-timeline, the offset corresponds to a specified point on the view-timeline. animation-range: 0% 100% is then treated similarly to cover 0% cover 100% and normal.

<length-percentage>
The animation attachment range starts at the specified point on the timeline measuring from the start of the timeline.

When <timeline-range-name> <length-percentage>? is used on a scroll-timeline, only the offsets are used. entry 0% entry 100% is treated similarly to 0% 100% and normal.

This seem to correspond well with Chrome, as far as I have tested. Specify animation-range: cover 20% on an animation with a scroll-timeline, and rangeStart will return {rangeName: 'cover', offset: CSS.px(20)}.

I don't see how we can validate a specified cover 20% for a ScrollTimeline, as the timeline might be changed to a ViewTimeline afterwards.

[bramus]

Note that none is not mentioned in the spec and that it is something that Chrome uses to indicate if the range only has an offset.

There is some discussion to introduce scroll as a range name in w3c/csswg-drafts#9367, which would allow renaming none to scroll as I mentioned in w3c/csswg-drafts#9367 (comment).

Would leave it at how it is right now, but might need a comment linking to the WG Issue.

[johannesodland]

Good point. I'll leave a comment linking to the issue.

[johannesodland]

Documented the use of 'none' as range name in stead of null in 96c567c.

[calinoracation]

Edit: Nevermind, our atomic css parser split the rules out so it couldn't parse it correctly.

@bramus @johannesodland Any chance of landing this? We're trying to use some code like this and it's not parsing at the moment. In Chromium it works great.

    animation-duration: 1ms;
    animation-fill-mode: forwards;
    animation-name: overflow-visible;
    animation-range-start: entry 70%;
    animation-range-end: entry 100%;
    animation-timeline: --carousel-scroller;
    view-timeline-name: --carousel-scroller;

    @keyframes overflow-visible {
      from {
        opacity: 1;
      }
      to {
        opacity: 0;
      }
    }