[csswg-drafts] [scroll-animations-1] How should ViewTimeline work on an inline or fragmented subject? (#13818)

flackr has just created a new issue for https://github.com/w3c/csswg-drafts:

== [scroll-animations-1] How should ViewTimeline work on an inline or fragmented subject? ==
As part of the interop investigation, @kevers-google discovered that the test [view-timeline-pseudo-on-scroller.html](https://github.com/web-platform-tests/wpt/blob/7110c870ba8c4d39534e87b9a488e16ccd0727b2/scroll-animations/css/view-timeline-pseudo-on-scroller.html#L4) is only failing on chrome because it has an inline subject. This raised the question of how inline subjects should work.

According to the current spec, on [view progress subjects](https://www.w3.org/TR/scroll-animations-1/#view-progress-subject):
> View progress timelines are segments of a scroll progress timeline that are scoped to the scroll positions in which any part of the subject element’s [principal box](https://www.w3.org/TR/css-display-3/#principal-box) intersects its nearest ancestor scrollport

I think given the definition of [inline](https://www.w3.org/TR/css-display-3/#valdef-display-inline) in css-display it is expected that view timelines should work.
> inline
> The element generates a box that is inline-level when placed in [flow layout](https://www.w3.org/TR/css-display-3/#flow-layout). [[CSS2]](https://www.w3.org/TR/css-display-3/#biblio-css2)

However, I was then comparing this to what intersection observer does, as most developers conceptually think of a view timeline subject as similar to an intersection observer, and found the following:

[Compute the Intersection of a Target Element and the Root](https://w3c.github.io/IntersectionObserver/#observe-a-target-element):
> To compute the intersection between a [target](https://w3c.github.io/IntersectionObserver/#intersectionobserver-target) target and an [intersection root](https://w3c.github.io/IntersectionObserver/#intersectionobserver-intersection-root) root, run these steps:
>
> 1. Let intersectionRect be the result of [getting the bounding box](https://drafts.csswg.org/cssom-view-1/#element-get-the-bounding-box) for target.

[To get the bounding box](https://drafts.csswg.org/cssom-view-1/#element-get-the-bounding-box)
> To get the bounding box for element, run the following steps:
> 1. Let list be the result of invoking [getClientRects()](https://drafts.csswg.org/cssom-view-1/#dom-element-getclientrects) on element.
> 2. If the list is empty return a [DOMRect](https://drafts.csswg.org/geometry-1/#domrect) object whose [x](https://drafts.csswg.org/geometry-1/#dom-domrect-x), [y](https://drafts.csswg.org/geometry-1/#dom-domrect-y), [width](https://drafts.csswg.org/geometry-1/#dom-domrect-width) and [height](https://drafts.csswg.org/geometry-1/#dom-domrect-height) members are zero.
> 3. If all rectangles in list have zero width or height, return the first rectangle in list.
> 4. Otherwise, return a [DOMRect](https://drafts.csswg.org/geometry-1/#domrect) object describing the smallest rectangle that includes all of the rectangles in list of which the height or width is not zero.

If my understanding is correct, this means that an intersection observer will produce results based on a bounding box and a view timeline will produce results based on the first box.

I propose view timelines should use the same bounding box of all boxes.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13818 using your GitHub account


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

Received on Thursday, 16 April 2026 18:26:10 UTC