Re: [webkit-dev] Proposal for an "intent to" process for web-exposed features

[Ryosuke Niwa]

Thanks for starting this discussion.

On Wed, Feb 26, 2020 at 10:33 PM Frédéric Wang  wrote:

>
> The idea of an "intent to" process has been raised several times in the
> past (e.g. in our 2020 goals [1]) and some people already use it
> informally, but it does not seem that we have any agreement right now. Such
> a process would help to coordinate changes internally (between port
> maintainers and contributors) and externally (with standard groups, users
> and other implementers). For the former point, see [2][3][4] for examples
> of how coordination is not smooth right now. The latter point will give a
> better understanding of what's happening in WebKit and help web developer
> advocacy.
>

Having some kind of a process to announce a new Web facing API or behavior
change is a good idea. In fact, we technically still have such a process
although nobody seems to be using these days:
https://trac.webkit.org/wiki/AddingFeatures

The Mozilla and Chromium projects have their own process [5] [6]. We can
> probably start with minimal rules and refine them in the future. We can
> even make it mandatory only for new web platform features developed under
> a runtime preference for now (i.e. excluding small features for which
> it's not worth introducing a flag, behavior changes or deprecation/removal).
> Below is a proposal based on Mozilla's one.
>

WebKit tends to err on the side of simpler rules so let's stick with that.
I don't think we need an email template for example (I hate templates; all
those intent to X emails on other engines' mailing lists look so silly).

1. Email webkit-dev with an intent to prototype.
>

I really dislike the idea of putting features into different stages like
prototyping, etc... I'd prefer a much simpler approach in which a new
feature or any behavior chance being worked on is announced on webkit-dev.

In fact, I don't think we should have any rule about how emails are titled,
etc... Emails just need to contain a certain set of information we need to
evaluate whether a given feature / behavior change is good or not.

Rather, what we need a guidance on is at which point something becomes a
feature or a behavior change significant enough that an announcement on
webkit-dev is necessary. For example, one could argue that any bug fix in
Web facing API will affect its behavior. However, I don't think we want to
be tracking every one of those behavior changes in WebKit on webkit-dev.

Similarly, adding a new API has multitude of scales. On one hand, there is
ResizeObserver and there is adding pointerLockElement on ShadowRoot
. At which point, should
we be making webkit-dev announcement. Again, I don't think we want to be
tracking the addition of every new DOM property, JS API, etc... on
webkit-dev.

 2. Implement the feature normally behind a off-by-default preference.
>

This is not a preference, it's a WebKit policy:
https://webkit.org/feature-policy/

3. Email webkit-dev with an intent to ship.
>

I don't think this makes much sense in WebKit since there is no such a
thing as shipping in WebKit. Each port maintainers decide which set of
features will be enabled at when.

Or do you mean that we enabling new feature / behavior by default? If so,
then making such an announcement on webkit-dev requirement for Web facing
feature / behavior change makes sense to me. But we should never use term
such as "shipping".

4. If there's no negative feedback, ship (ports maintainer can still
> disable the feature if they want to).
>

We should probably adopt the same 5 business day policy here.

II/ Intent to prototype template
>

I don't think a template is necessary. We don't have a template for
nominating reviewer, committer, etc...

We should just have a list of topics / details / information each email
should contain. We should probably have:

   - Summary of new feature / behavior change
   - Bug URL
   - Spec URL / PR / Issue
   - Status in other browsers

I really don't think links to the related emails on webkit-dev, etc... is
necessary because anyone interested in a given feature / behavior change
will surely check the bug, etc...

On the other hand, we should probably also create a way to track all these
new features and behavior changes in some central place. For new Web facing
features, we have: https://webkit.org/status/

We should probably create some other page / tracking tool where all
behavior changes to existing Web APIs are tracked. And updating of
https://webkit.org/status/ as well as this new tracking tool should
probably a part of the requirement of adding a new feature / making a Web
facing behavioral change.

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Proposal for an "intent to" process for web-exposed features

[Frédéric Wang]

Hi,

The idea of an "intent to" process has been raised several times in the
past(e.g. in our 2020 goals [1])and some people already use it
informally, but it does not seem that we have any agreement right now.
Such a process would help to coordinate changes internally (between port
maintainers and contributors) and externally (with standard groups,
users and other implementers). For the former point, see [2][3][4] for
examples of how coordination is not smooth right now.The latter point
will give a better understanding of what's happening in WebKit and help
web developer advocacy.

The Mozilla and Chromium projects have their own process [5] [6]. We can
probably start with minimal rules and refine them in the future. We can
even make it mandatory only for new web platform features developed
under a runtime preference for now (i.e. excluding small features for
which it's not worth introducing a flag, behavior changes or
deprecation/removal). Below is a proposal based on Mozilla's one.

WDYT?

Frédéric, on behalf of Igalia's web platform team

[1] https://trac.webkit.org/wiki/WebKitGoalsfor2020
[2] Behavior change: https://bugs.webkit.org/show_bug.cgi?id=201641#c49
[3] Deprecation/Removal: https://bugs.webkit.org/show_bug.cgi?id=204125#c7
[4] New feature: https://bugs.webkit.org/show_bug.cgi?id=157743landed in
April 2019 and only enabled in
https://bugs.webkit.org/show_bug.cgi?id=203644
[5] https://wiki.mozilla.org/ExposureGuidelines
[6] https://www.chromium.org/blink/launching-features



I/ General process

1. Email webkit-dev with an intent to prototype.
2. Implement the feature normally behind a off-by-default preference.
3. Email webkit-dev with an intent to ship.
4. If there's no negative feedback, ship (ports maintainer can still
disable the feature if they want to).

II/ Intent to prototype template

Subject: Intent to prototype:  

Summary: Elevator pitch for the new functionality.
Bug: Link to https://bugs.webkit.org
Standard: Link to standard or public discussions with other browser vendors.
Preference: name of flag.
Status in other browsers: "shipped", "intent emailed" or "considering".
web-platform-tests: Test suite for this feature.

III/ Intent to ship template

Subject: Intent to ship:  

As of  I intend to turn  on by default:
https://bugs.webkit.orgto turn the flag on>. This has
originally been proposed in https://lists.webkit.org/pipermail/webkit-devintent to prototype>.*If
anything changed since that thread please include that information in
this email*.

It's acceptable to merge the "intent to prototype" into the "intent to
ship" email as long as all the relevant requirements are met.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit position on Paint Timing / (first paint, first contentful paint)

[Ryosuke Niwa]

On Wed, Feb 26, 2020 at 9:00 PM Maciej Stachowiak  wrote:

>
>
> On Feb 26, 2020, at 2:25 PM, Ryosuke Niwa  wrote:
>
>
> On Wed, Feb 26, 2020 at 11:29 AM Maciej Stachowiak  wrote:
>
>>
>>
>> On Feb 26, 2020, at 10:51 AM, Noam Rosenthal 
>> wrote:
>>
>>
>>
>> On Wed, Feb 26, 2020 at 8:08 PM Maciej Stachowiak  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 . 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 think that for the main
>> use-case of catching regressions for website code, it's ok (and almost
>> unpreventable) if the implementations have some variances between them,
>> what matters is that the metric is reliable for the particular browser.
>> 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.
>>
>>
>> First paint that’s not first meaningful/contentful paint is not a very
>> good performance metric IMO. Who cares that a paint happened if it doesn’t
>> have any image or text content?
>>
>> I also don’t think this exposes less. The privacy risk here is exposing
>> timing data that might be usable for fingerprinting.
>>
>>
>>
>>>
>>> Chrome team themselves have been telling web developers that First
>>> Contentful Paint is deprecated in favor of Largest Contentful Paint. Should
>>> we concerned about this? It seems even harder to define LCP in an
>>> engine-independent way.
>>>
>> What was deprecated was "first meaningful paint" (FMP). FCP was not
>> deprecated and has been in wide use for some time.
>>
>>
>> What’s the difference between First Meaningful and First Contentful?
>>
>
> There is no difference in Safari because we don't do any painting of a
> newly navigated until the first meaningful paint happens.
>
>
> WebKit’s notion of First Meaningful Paint is not the same as Chrome’s,
> from the sound of it. It sounds closer to Chrome’s First Contentful Paint,
> which makes no attempt to exclude sidebars or navigation bars or the like.
> (But it does exclude iframe).
>

Well, WebKit does have heuristics like the number of characters that have
been laid out to gate the initial paint whereas Blink makes no such
attempts for having the first contentful paint (it just means the painted
content has something more than pure white / blank tile).

Note (for folks not familiar with WebKit's navigation / painting model)
that, by definition, WebKit's first painting of a newly navigated page *is*
the first contentful paint and also the first paint because we never even
attempt to paint the page until then (if we did paint the newly navigated
page prior to that point, that'd be considered as a bug).

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Is anyone maintaining Nicosia scrolling code?

[Simon Fraser]

> On Feb 23, 2019, at 3:29 AM, z...@falconsigh.net wrote:
> 
> On Sat, Feb 23, 2019, at 2:47 AM, Simon Fraser wrote:
>> There’s a bunch of code in Source/WebCore/page/scrolling/nicosia/ that 
>> I keep breaking with scrolling tree refactoring. Most of it it stubs. 
>> Is anyone maintaining this code, because it obviously doesn’t work, and 
>> I’d like to remove the maintenance burden.
>> 
> 
> I added the stubs there, and was planning to start adding actual 
> implementations there in the following weeks, now that a new release cycle 
> was just entered.
> 
> I wouldn't mind disabling or removing the code temporarily in order to enable 
> you an easier time refactoring around it. But given that the async scrolling 
> capability is something we plan to add support for in the WPE and GTK ports, 
> I'd appreciate some input about the scope and the timeframe of your work and 
> possibility of sharing as much of the implementation as possible between 
> different ports.

I’m hitting Nicosia compile issues again 
(https://bugs.webkit.org/show_bug.cgi?id=208282) and the last Nicosia-related 
commit was on October 3.

Does Nicosia qualify as a “science project” in the sense listed at 
https://webkit.org/project/  . Googling for 
Nicosia finds no technology-related hits on the first page.

Simon



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit position on Paint Timing / (first paint, first contentful paint)

[Maciej Stachowiak]

> On Feb 26, 2020, at 2:25 PM, Ryosuke Niwa  wrote:
> 
> 
> On Wed, Feb 26, 2020 at 11:29 AM Maciej Stachowiak  > wrote:
> 
> 
>> On Feb 26, 2020, at 10:51 AM, Noam Rosenthal > > wrote:
>> 
>> 
>> 
>> On Wed, Feb 26, 2020 at 8:08 PM Maciej Stachowiak > > wrote:
>> 
>> Some quick comments: 
>> 
>> the definition of First Contentful Paint here in the spec: 
>> > > does not match the 
>> definition stated at > >. 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 think that for the main use-case of 
>> catching regressions for website code, it's ok (and almost unpreventable) if 
>> the implementations have some variances between them, what matters is that 
>> the metric is reliable for the particular browser. 
>> 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.
> 
> First paint that’s not first meaningful/contentful paint is not a very good 
> performance metric IMO. Who cares that a paint happened if it doesn’t have 
> any image or text content?
> 
> I also don’t think this exposes less. The privacy risk here is exposing 
> timing data that might be usable for fingerprinting.
> 
>>  
>> 
>> Chrome team themselves have been telling web developers that First 
>> Contentful Paint is deprecated in favor of Largest Contentful Paint. Should 
>> we concerned about this? It seems even harder to define LCP in an 
>> engine-independent way.
>> What was deprecated was "first meaningful paint" (FMP). FCP was not 
>> deprecated and has been in wide use for some time.
> 
> What’s the difference between First Meaningful and First Contentful?
> 
> There is no difference in Safari because we don't do any painting of a newly 
> navigated until the first meaningful paint happens.

WebKit’s notion of First Meaningful Paint is not the same as Chrome’s, from the 
sound of it. It sounds closer to Chrome’s First Contentful Paint, which makes 
no attempt to exclude sidebars or navigation bars or the like. (But it does 
exclude iframe).

> 
> - R. Niwa
> 
>> 
>> Finally, we should do a privacy review to consider whether exposing this 
>> info to webpages creates fingerprinting risk or otherwise exposes user data.
>> Great, what is needed for such review?
> 
> We will discuss with Apple’s privacy experts what they think of the privacy 
> risk. I’m just giving you a rain check for results of this discussion.
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org 
> https://lists.webkit.org/mailman/listinfo/webkit-dev 
> 
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit position on Paint Timing / (first paint, first contentful paint)

[Ryosuke Niwa]

On Wed, Feb 26, 2020 at 10:54 AM Noam Rosenthal  wrote:

> (resending from correct address)
> On Wed, Feb 26, 2020 at 8:08 PM Maciej Stachowiak  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 . 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

Re: [webkit-dev] WebKit position on Paint Timing / (first paint, first contentful paint)

[Ryosuke Niwa]

On Wed, Feb 26, 2020 at 11:29 AM Maciej Stachowiak  wrote:

>
>
> On Feb 26, 2020, at 10:51 AM, Noam Rosenthal 
> wrote:
>
>
>
> On Wed, Feb 26, 2020 at 8:08 PM Maciej Stachowiak  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 . 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 think that for the main
> use-case of catching regressions for website code, it's ok (and almost
> unpreventable) if the implementations have some variances between them,
> what matters is that the metric is reliable for the particular browser.
> 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.
>
>
> First paint that’s not first meaningful/contentful paint is not a very
> good performance metric IMO. Who cares that a paint happened if it doesn’t
> have any image or text content?
>
> I also don’t think this exposes less. The privacy risk here is exposing
> timing data that might be usable for fingerprinting.
>
>
>
>>
>> Chrome team themselves have been telling web developers that First
>> Contentful Paint is deprecated in favor of Largest Contentful Paint. Should
>> we concerned about this? It seems even harder to define LCP in an
>> engine-independent way.
>>
> What was deprecated was "first meaningful paint" (FMP). FCP was not
> deprecated and has been in wide use for some time.
>
>
> What’s the difference between First Meaningful and First Contentful?
>

There is no difference in Safari because we don't do any painting of a
newly navigated until the first meaningful paint happens.

- R. Niwa


>> Finally, we should do a privacy review to consider whether exposing this
>> info to webpages creates fingerprinting risk or otherwise exposes user data.
>>
> Great, what is needed for such review?
>
>
> We will discuss with Apple’s privacy experts what they think of the
> privacy risk. I’m just giving you a rain check for results of this
> discussion.
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit position on Paint Timing / (first paint, first contentful paint)

[Noam Rosenthal]

On Wed, Feb 26, 2020 at 9:29 PM Maciej Stachowiak  wrote:

> 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.
>
>
> First paint that’s not first meaningful/contentful paint is not a very
> good performance metric IMO. Who cares that a paint happened if it doesn’t
> have any image or text content?
>
I think it's meaningful as a general regression metric, albeit less useful
than FCP. Web developers are scrambling for any RUM information they can
use...


> I also don’t think this exposes less. The privacy risk here is exposing
> timing data that might be usable for fingerprinting.
>
Yes, I think that privacy-relevant timing information is already available
through resource timing (window.performance.getEntries("resource")). But
we'll see what the privacy experts come up with.


> What was deprecated was "first meaningful paint" (FMP). FCP was not
> deprecated and has been in wide use for some time.
>
> What’s the difference between First Meaningful and First Contentful?
>
FMP had the notion of "primary" content; e.g. it was ignoring
navbars/headers, and trying to figure out when the main content of the site
has been rendered.  As noted, FMP is deprecated. FCP is a lot more
transparent in what it measures.

We will discuss with Apple’s privacy experts what they think of the privacy
> risk. I’m just giving you a rain check for results of this discussion.
>
Got it, Looking forward :)
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit position on Paint Timing / (first paint, first contentful paint)

[Maciej Stachowiak]

> On Feb 26, 2020, at 10:51 AM, Noam Rosenthal  
> wrote:
> 
> 
> 
> On Wed, Feb 26, 2020 at 8:08 PM Maciej Stachowiak  > wrote:
> 
> Some quick comments: 
> 
> the definition of First Contentful Paint here in the spec: 
>  > does not match the 
> definition stated at  >. 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 think that for the main use-case of 
> catching regressions for website code, it's ok (and almost unpreventable) if 
> the implementations have some variances between them, what matters is that 
> the metric is reliable for the particular browser. 
> 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.

First paint that’s not first meaningful/contentful paint is not a very good 
performance metric IMO. Who cares that a paint happened if it doesn’t have any 
image or text content?

I also don’t think this exposes less. The privacy risk here is exposing timing 
data that might be usable for fingerprinting.

>  
> 
> Chrome team themselves have been telling web developers that First Contentful 
> Paint is deprecated in favor of Largest Contentful Paint. Should we concerned 
> about this? It seems even harder to define LCP in an engine-independent way.
> What was deprecated was "first meaningful paint" (FMP). FCP was not 
> deprecated and has been in wide use for some time.

What’s the difference between First Meaningful and First Contentful?

>  
> 
> Finally, we should do a privacy review to consider whether exposing this info 
> to webpages creates fingerprinting risk or otherwise exposes user data.
> Great, what is needed for such review?

We will discuss with Apple’s privacy experts what they think of the privacy 
risk. I’m just giving you a rain check for results of this discussion.___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit position on Paint Timing / (first paint, first contentful paint)

[Noam Rosenthal]

(resending from correct address)
On Wed, Feb 26, 2020 at 8:08 PM Maciej Stachowiak  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 . 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 think that for the main
use-case of catching regressions for website code, it's ok (and almost
unpreventable) if the implementations have some variances between them,
what matters is that the metric is reliable for the particular browser.
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.


>
> Chrome team themselves have been telling web developers that First
> Contentful Paint is deprecated in favor of Largest Contentful Paint. Should
> we concerned about this? It seems even harder to define LCP in an
> engine-independent way.
>
What was deprecated was "first meaningful paint" (FMP). FCP was not
deprecated and has been in wide use for some time.


>
> Finally, we should do a privacy review to consider whether exposing this
> info to webpages creates fingerprinting risk or otherwise exposes user data.
>
Great, what is needed for such review?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit position on Paint Timing / (first paint, first contentful paint)

[Maciej Stachowiak]

Some quick comments:

I am concerned that the definitions of these paint milestones have 
engine-dependent assumptions, and some may not be spelled out in the spec.

For example, the definition of First Contentful Paint here in the spec: 
 does not match the 
definition stated at . 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?

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?

Chrome team themselves have been telling web developers that First Contentful 
Paint is deprecated in favor of Largest Contentful Paint. Should we concerned 
about this? It seems even harder to define LCP in an engine-independent way.

Finally, we should do a privacy review to consider whether exposing this info 
to webpages creates fingerprinting risk or otherwise exposes user data.

Regards,
Maciej

> On Feb 26, 2020, at 3:32 AM, Noam Rosenthal  wrote:
> 
> Hola
> I was approached by the Wikimedia foundation to implement the paint timing 
> API for WebKit (yay).
> I think this is a good feature to have for webkit, and I wanted to hear 
> thoughts about it before I begin.
> 
> The feature was enabled in Chrome for quite a while, and is potentially very 
> useful for real user monitoring to see if changes to the code of the website 
> create performance regressions on different browsers.
> We've been using it extensively (on Chrome) when I worked at Wix.com, and 
> always hoped that "some day" it will be available in other browsers.
> 
> I think it's a pretty lean spec and was stable since 2017, and that it fits 
> with the WebKit project goals, by allowing web developers to better optimize 
> their content and catch Safari/WebKit-specific regressions early.
> 
> I would like to get feedback on whether it's a desired feature for WebKit, if 
> there are caveats/pitfalls I should be thinking about, and anything else 
> that's worth mentioning at this point.
> 
> There are of course delicate decisions to be made as to the choice of timing 
> indicator, but I will get to that once we've sorted out the position in 
> general.
> 
> Bug: https://bugs.webkit.org/show_bug.cgi?id=78011 
> 
> Spec: https://www.w3.org/TR/paint-timing/ 
> 
> 
> Thanks!
> Noam
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] WebKit position on Paint Timing / (first paint, first contentful paint)

[Noam Rosenthal]

Hola
I was approached by the Wikimedia foundation to implement the paint timing
API for WebKit (yay).
I think this is a good feature to have for webkit, and I wanted to hear
thoughts about it before I begin.

The feature was enabled in Chrome for quite a while, and is potentially
very useful for real user monitoring to see if changes to the code of the
website create performance regressions on different browsers.
We've been using it extensively (on Chrome) when I worked at Wix.com, and
always hoped that "some day" it will be available in other browsers.

I think it's a pretty lean spec and was stable since 2017, and that it fits
with the WebKit project goals, by allowing web developers to better
optimize their content and catch Safari/WebKit-specific regressions early.

I would like to get feedback on whether it's a desired feature for WebKit,
if there are caveats/pitfalls I should be thinking about, and anything else
that's worth mentioning at this point.

There are of course delicate decisions to be made as to the choice of
timing indicator, but I will get to that once we've sorted out the position
in general.

Bug: https://bugs.webkit.org/show_bug.cgi?id=78011
Spec: https://www.w3.org/TR/paint-timing/

Thanks!
Noam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev