LGTM2 On Wed, Dec 3, 2025 at 7:59 AM Yoav Weiss (@Shopify) <[email protected]> wrote:
> LGTM1 > > On Wednesday, December 3, 2025 at 4:56:04 PM UTC+1 Michal Mocny wrote: > > Yes, on top of. startTime is defined in terms of renderTime which is now > defined in terms of paint/presentation times. > > So this just exposes the individual values that were already used for the > calculations. > > > Thank you! exposing those on top of the current attributes means that > there's no real compat risk here. Firefox being supportive significantly > reduces interop risk. > > > > On Wednesday, December 3, 2025 at 10:51:35 AM UTC-5 Yoav Weiss wrote: > > I should know this but do I understand correctly and this is adding > `paintTime` and `presentationTime` *on top* of existing attributes such as > `renderTime`/`startTime`/etc? > > On Thursday, November 27, 2025 at 11:49:01 AM UTC+1 Chromestatus wrote: > > *Contact emails* > [email protected], [email protected] > > > > *Explainer* > https://github.com/w3c/paint-timing/blob/main/presentation-timestamps.md > > *Specification* > https://w3c.github.io/paint-timing/#painttimingmixin > > *Summary* > Expose "paintTime" and "presentationTime" in element timing, LCP, long > animation frames, and paint timing. "paintTime" means the time when the > rendering phase ended and the browser started the paint phase. > "presentationTime" means the time when the "pixels reached the screen", > which is somewhat implementation-defined. This feature entry omits event > timing, which would be done separately. > > *Blink component* > Blink>PerformanceAPIs > <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EPerformanceAPIs%22> > > *Web Feature ID* > performancetiming <https://webstatus.dev/features/performancetiming> > > *Motivation* > So far the spec defined the paint time as the time after the "rendering > update", when the document hands over rendering to the UA. However, in > chromium the exposed paint time (in event timing, element timing, LCP and > paint-timing) was different - the approximated VSync time from the > compositor, which is important in terms of UX. This created confusion and > incompatibility This proposal defines both these timestamps, and exposes > them in an identical way in all the relevant entries. > > *Initial public proposal* > https://github.com/w3c/paint-timing/issues/62 > > *TAG review* > https://github.com/w3ctag/design-reviews/issues/1013 > > *TAG review status* > Pending > > *Risks* > > > *Interoperability and Compatibility* > *No information provided* > > *Gecko*: Positive (https://github.com/mozilla/standards-positions/ > issues/1110) Firefox folks took part of the WebPerfWG meeting where this > was discussed/resolved. > > *WebKit*: In development (https://github.com/WebKit/standards- > positions/issues/426) > > *Web developers*: No signals > > *Other signals*: > > *WebView application risks* > > Does this intent deprecate or change behavior of existing APIs, such that > it has potentially high risk for Android WebView-based applications? > *No information provided* > > > *Debuggability* > *No information provided* > > *Will this feature be supported on all six Blink platforms (Windows, Mac, > Linux, ChromeOS, Android, and Android WebView)?* > Yes > > *Is this feature fully tested by web-platform-tests > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* > No > > > *Flag name on about://flags* > *No information provided* > > *Finch feature name* > PaintTimingMixin > > *Rollout plan* > Will ship enabled for all users > > *Requires code in //chrome?* > False > > *Tracking bug* > https://issues.chromium.org/issues/378827535 > > *Estimated milestones* > Shipping on desktop144 Shipping on Android144 Shipping on WebView144 > > *Anticipated spec changes* > > Open questions about a feature may be a source of future web compat or > interop issues. Please list open issues (e.g. links to known github issues > in the project for the feature specification) whose resolution may > introduce web compat/interop risk (e.g., changing to naming or structure of > the API in a non-backward-compatible way). > None. This is already part of interop 2025. Note that the TAG review was > delayed because some things in the explainer were missing initially. > > *Link to entry on the Chrome Platform Status* > https://chromestatus.com/feature/5162859838046208?gate=5137700305502208 > > *Links to previous Intent discussions* > Intent to Prototype: https://groups.google.com/a/ > chromium.org/d/msgid/blink-dev/67347e70.2b0a0220.3644d. > 01e9.GAE%40google.com > > > This intent message was generated by Chrome Platform Status > <https://chromestatus.com>. > > -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2f9f3215-7039-4248-976a-b9cb398bded6n%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2f9f3215-7039-4248-976a-b9cb398bded6n%40chromium.org?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9t0LnJdc-9peR4pnSV%2Bjbhyt1e5e4QG7UOk8jtXti6Hw%40mail.gmail.com.
