[webkit-dev] WebKit on Slack

[Jonathan Davis]

Hi folks,

I’m happy to announce that we have launched a #WebKit workspace for 
collaboration on Slack. All developers and contributors to WebKit are invited 
to join and participate.

The #WebKit workspace on Slack is available at:
https://webkit.slack.com 

You’ll need an invitation to participate. If you’ve contributed a patch in the 
last couple of years, you’re likely to have already received a direct 
invitation by email to the address(es) you used for your contributions.

If you’re just getting started with contributing, you can find a short guide to 
contributing and information on joining our Slack channels in the "Staying in 
Touch" section of the Getting Started page available at:
https://webkit.org/getting-started/ 

Feel free to email me if you have any questions about our Slack workspace or 
encounter problems joining. Happy contributing!

— Jon Davis

smime.p7s
Description: S/MIME cryptographic signature
___
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 27, 2020, at 3:41 AM, Noam Rosenthal  wrote:
> 
> 
> 
> On Thu, Feb 27, 2020 at 12:46 PM Noam Rosenthal  > wrote:
> 
> 
> On Thu, Feb 27, 2020 at 12:17 PM Yoav Weiss  > wrote:
> 
> 
> On Wed, Feb 26, 2020 at 11:33 PM Ryosuke Niwa  > wrote:
> 
> 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.
> Body background color is still painted before any contentful paint... Is this 
> a bug?
> Also, a web page might not have content at all (e.g. a bunch of divs with 
> bgcolors). Would webkit not render that web page at all? 
> 
> It seems like the code in FrameView does this:
> // Ensure that we always fire visually non-empty milestone eventually.
> if (finishedParsingMainDocument && frame().loader().isComplete())
> return true;
> 
> I suggest splitting this to two milestones - the current one, that triggers 
> when the main document finished loading, and another one that only triggers 
> when content has actually been painted (which may never happen). I think this 
> would be a good split for first-paint/first-contentful-paint in WebKit.

The first visually non-empty milestone almost always happens way before this 
point. The above is just a fallback to make sure we eventually hit this 
milestone. For example, if a document is totally blank even after loading the 
document and all subresources, we want to paint it instead of waiting forever.

The visually non-empty heuristic is elsewhere.

Note that WebKit would consider the paint triggered by the above fallback code 
to be both a first paint and “first visually non-empty paint” or “first 
meaningful paint”, which somewhat corresponds to Chrome’s notion of “first 
contentful paint”.

First paint can only happen earlier under even more unusual circumstances, I 
believe there is a timeout after which we will paint even if all we can paint 
is blank white or background color.

> 
> But let's take the specifics to Slack/bugzilla?

I think it would be good for you to talk to people who understand WebKit’s 
layout/paint milestones in detail before taking things to bugzilla. Ask on 
Slack, and I’ll point you to the right people.

> 
> ___
> 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] Proposal for an "intent to" process for web-exposed features

[Maciej Stachowiak]

I think we should have some structure, not just freeform emails. We can start 
with a simple template, but there’s some info that folks almost always want, so 
it’s easier if it’s included in the first place, rather than needing 
predictable follow-up questions

I also like having a title pattern, because that makes it easier to search 
email to find all things that fit the category.

Basically, since for any given feature email, there’s many potential readers 
and only one sender, so it seems reasonable to ask the sender to do a little 
extra 

I had some sample templates (much simpler than the ones used by Chrome) which I 
will dig out and send here.

> On Feb 26, 2020, at 11:08 PM, Ryosuke Niwa  wrote:
> 
> 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.

I personally think every web platform facing change should be announced, but 
it’s ok if some broader feature announcements cover every property and 
attribute in the spec at the time, even if they don’t land all at once. On the 
other hand, in specs like HTML or DOM, many individual new markup attributes or 
DOM properties are a feature in themselves.


> 
>  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/ 
I think he was using “preference” to mean “setting”, not to suggest that this 
is merely a preference and not required.

> 
> 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).
> 

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

[Noam Rosenthal]

On Thu, Feb 27, 2020 at 12:46 PM Noam Rosenthal  wrote:

>
>
> On Thu, Feb 27, 2020 at 12:17 PM Yoav Weiss  wrote:
>
>>
>>
>> On Wed, Feb 26, 2020 at 11:33 PM Ryosuke Niwa  wrote:
>>
>>>
>>> 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.
>>>
>> Body background color is still painted before any contentful paint... Is
> this a bug?
> Also, a web page might not have content at all (e.g. a bunch of divs with
> bgcolors). Would webkit not render that web page at all?
>

It seems like the code in FrameView does this:

// Ensure that we always fire visually non-empty milestone eventually.

*if* (finishedParsingMainDocument && frame().loader().isComplete())

*return* *true*;

I suggest splitting this to two milestones - the current one, that triggers
when the main document finished loading, and another one that only triggers
when content has actually been painted (which may never happen). I think
this would be a good split for first-paint/first-contentful-paint in WebKit.

But let's take the specifics to Slack/bugzilla?
___
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)

[Yoav Weiss]

On Thu, Feb 27, 2020 at 11:47 AM Noam Rosenthal  wrote:

>
>
> On Thu, Feb 27, 2020 at 12:17 PM Yoav Weiss  wrote:
>
>>
>>
>> On Wed, Feb 26, 2020 at 11:33 PM Ryosuke Niwa  wrote:
>>
>>>
>>> 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.
>>>
>> Body background color is still painted before any contentful paint... Is
> this a bug?
> Also, a web page might not have content at all (e.g. a bunch of divs with
> bgcolors). Would webkit not render that web page at all?
>
>>
>>> 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.
>>>
>>
>> With my WebPerfWG hat on, I agree. Would be good to find a model that
>> works well for different implementations (even if not comparable between
>> different implementations), while providing points in time for developers
>> that can: a) provide a user meaningful visual metric and b) enable spotting
>> regressions.
>>
> Note taken. Though this is hypothetical - let's get to the point where the
> spec is lacking, and then we can decide how to go about it.
> What I propose is to go as far as possible with the spec, and when we
> reach an ambiguity tackle it on the spec front.
>
>>
>> Would WebKit folks be interested in helping exploration on that front?
>>
> I would be happy to help coordinate this (e.g. work on the details of pec
> differences and prod Ryosuke and folks for feedback about internals).
>

That sounds great, thank you! :)


>
>
>>
>>> I don't think we don't should that because we don't have an equivalent
>>> of first-paint.
>>>
>>
>> FWIW, I don't think it's a huge problem if WebKit will report FP and FCP
>> as the same timestamp, as they are indeed the same point in time.
>>
> A simple test shows that safari does show the background color
> (body=bgcolor) when a timeout is set to render everything else (e.g. add
> text to the document). According to the spec, the first one should give
> first-paint and the second one would be first-contentful-paint.
>
___
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 Thu, Feb 27, 2020 at 12:17 PM Yoav Weiss  wrote:

>
>
> On Wed, Feb 26, 2020 at 11:33 PM Ryosuke Niwa  wrote:
>
>>
>> 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.
>>
> Body background color is still painted before any contentful paint... Is
this a bug?
Also, a web page might not have content at all (e.g. a bunch of divs with
bgcolors). Would webkit not render that web page at all?

>
>> 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.
>>
>
> With my WebPerfWG hat on, I agree. Would be good to find a model that
> works well for different implementations (even if not comparable between
> different implementations), while providing points in time for developers
> that can: a) provide a user meaningful visual metric and b) enable spotting
> regressions.
>
Note taken. Though this is hypothetical - let's get to the point where the
spec is lacking, and then we can decide how to go about it.
What I propose is to go as far as possible with the spec, and when we reach
an ambiguity tackle it on the spec front.

>
> Would WebKit folks be interested in helping exploration on that front?
>
I would be happy to help coordinate this (e.g. work on the details of pec
differences and prod Ryosuke and folks for feedback about internals).


>
>> I don't think we don't should that because we don't have an equivalent of
>> first-paint.
>>
>
> FWIW, I don't think it's a huge problem if WebKit will report FP and FCP
> as the same timestamp, as they are indeed the same point in time.
>
A simple test shows that safari does show the background color
(body=bgcolor) when a timeout is set to render everything else (e.g. add
text to the document). According to the spec, the first one should give
first-paint and the second one would be first-contentful-paint.
___
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)

[Yoav Weiss]

On Wed, Feb 26, 2020 at 11:33 PM Ryosuke Niwa  wrote:

>
> 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.
>

With my WebPerfWG hat on, I agree. Would be good to find a model that works
well for different implementations (even if not comparable between
different implementations), while providing points in time for developers
that can: a) provide a user meaningful visual metric and b) enable spotting
regressions.

Would WebKit folks be interested in helping exploration on that front?


>
> 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.
>

FWIW, I don't think it's a huge problem if WebKit will report FP and FCP as
the same timestamp, as they are indeed the same point in time.


> - R. Niwa
>
> ___
> 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] Proposal for an "intent to" process for web-exposed features

[Frédéric Wang]

Hi Ryosuke, just replying quickly to two points:

On 27/02/2020 08:08, Ryosuke Niwa wrote:
>
> 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".

Yes, it's about enabling the feature by default, as I said it's up to
the port maintainer to later decide whether they want to disable it. The
term "shipping" was copied from Mozilla's template but we can use
something else if that's misleading.

>
> 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.

Right, the proposal says + 1 week, but that's just an example.

-- 
Frédéric Wang

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