On Wed, Feb 26, 2020 at 10:54 AM Noam Rosenthal <n...@webkit.org> wrote:
> (resending from correct address) > On Wed, Feb 26, 2020 at 8:08 PM Maciej Stachowiak <m...@apple.com> wrote: > >> >> Some quick comments: >> > >> the definition of First Contentful Paint here in the spec: < >> https://www.w3.org/TR/paint-timing/#sec-terminology> does not match the >> definition stated at <https://web.dev/first-contentful-paint/>. The >> Chrome definition on web.dev specifies that iframe content is not >> included, the spec does not have this limitation. Would an implementation >> that matches the spec match Chrome? >> > The draft version of the spec specifies that iframe content is not > included in FCP: > https://w3c.github.io/paint-timing/#sec-reporting-paint-timing, and has a > few more comprehensive details about this. I think it's a good place to > start. > > I am also not sure this matches the layout milestones that already exist >> in non-Blink browser engines. Has this spec been implemented in Gecko, for >> example, to verity that it’s not exposing a concept that only exists in >> Blink? >> > No, this has not been implemented in Gecko, I'm tracking the bug on this: > https://bugzilla.mozilla.org/show_bug.cgi?id=1518999, there was some > movement recently. > > I suggest to start from "first-paint", and to try to match chrome as much > as possible in how FCP is implemented, in the cases where the spec doesn't > give enough detail, if such places exist. > I don't think we should do that. For starters, Chrome's painting strategy while loading a web page is very different from that of Safari / WebKit. We would freeze the painting of the previous page at the moment a new navigation is committed, and we wouldn't update the painting until the destination page has a meaningful content in it. This is a very much different from Chrome's model where the moment a new navigation is committed, Chrome will show a blank page then start incrementally painting the page throughout the navigation. Second off, the point of specification is to allow multiple independent implementations. If we had to reverse-engineer what Chrome is doing and implement that, it defeats the point of having any standard at all. I also suggest to start with "first-paint" as it's perhaps a bit less > "internal" than FCP, and can provide a performance-regression metric with a > lesser degree of risk regarding exposing internals / privacy. > I don't think we don't should that because we don't have an equivalent of first-paint. - R. Niwa
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
