Re: CfC - publishing Long-Animation-Frames as a FPWD

+Noam to keep me honest, but I think that:

On Wed, Jan 21, 2026 at 12:53 PM Alex Christensen <achristensen@apple.com>
wrote:

> I'm not sure how this would relate to publishing a first public working
> draft, but we have some comments:
> 1. If multiple layouts are triggered by the same rendering update, which
> time would be reported in as 'style and layout start time' in 'frame timing
> info'?
>

In chromium you can only have a single layout in the rendering update
itself.  That is what the frame timing info reports.  You can have any
number of *forced* style or layouts inside other tasks that are scheduled
during a single animation frame i.e. when a developer reads from properties
that need re-layout.

The Long Animation Frame Timing API distinguishes these via
forcedStyleAndLayoutDuration
<https://w3c.github.io/long-animation-frames/#ref-for-dom-performancescripttiming-forcedstyleandlayoutduration>
(in scripts section of attribution).  Multiple scripts may be reported in a
single LoAF, but only a subset of sufficienty long scripts are reported.  I
have made a feature request
<https://github.com/w3c/long-animation-frames/issues/23> to have the Frame
Timing info also just report the simple sum of all forced style & layout
time, for the whole frame, to make it both easier and more accurate for
certain rendering patterns.

If WebKit would find that a useful addition (or the only viable
alternative?) I think we could include something like that.


> 2. This specification introduces many new points at which times need to be
> gathered from the clock, which has a cost that may be high enough that we
> might not be able to ship this without a measurable performance regression,
> which would be unacceptable to us.
>

Most of the reporting work is lazy and deferred until after we know a
script / frame are long, and the minimum duration threshold also means
there is inherantly a limited amount of operations per unit time-- but
indeed you need to at least measure a few times/durations for each task in
order to know if these are long.

Chromium did not have measureable regressions when implementing this API,
but we had already been measuring task durations before this API.


> On Jan 16, 2026, at 5:48 AM, Yoav Weiss <yoav.weiss@shopify.com> wrote:
>
> Indeed!
>
> On Fri, Jan 16, 2026 at 2:40 PM Michal Mocny <mmocny@google.com> wrote:
>
>> (Just confirming: silence is considered support, right?)
>>
>> On Fri, Jan 16, 2026, 05:47 Yoav Weiss <yoav.weiss@shopify.com> wrote:
>>
>>> Hey folks!
>>>
>>> Following WG discussion yesterday, I'm sending out a Call For Consensus
>>> on publishing the Long Animation Frames
>>> <https://w3c.github.io/long-animation-frames/> specification as a First
>>> Public Working Draft.
>>>
>>> The call would end 2 weeks from now, on January 30th. If you have any
>>> objections to publishing, please voice them prior to that.
>>>
>>> Thanks!
>>> Yoav
>>>
>>
>