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

I should've sent this sooner. Apologies!

The CfC is long past, and the non-blocking questions were addressed.
We're now ready to move ahead with publishing Long Animation Frames as FPWD.

On Thu, Jan 22, 2026 at 4:39 PM Noam Rosenthal <nrosenthal@google.com>
wrote:

>
>
> On Thu, Jan 22, 2026, 3:19 PM Michal Mocny <mmocny@google.com> wrote:
>
>> +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.
>>
>
> Specifically that point in time is in a very particular spot in the
> rendering loop.
>
>>
>> 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.
>>>
>>
> Note that the algorithms that check the clock exit early if some
> conditions are not met, the main one being that we don't normally check the
> clock in the middle of a script (apart from forced style and layout). This
> has proven to be a sweet spot that doesn't create noticeable overhead.
>
>
> 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
>>>>>
>>>>
>>>