Re: WebPerfWG call - March 26th 10am PT

Hey all,

and recording <> from last
week's call are now available.
Copying the minutes here for safe keeping:

WebPerfWG call - March 26 2020

Noam Rosenthal, Peter Perlepes, Nicolás Peña, Annie Sullivan, Steve Bougon,
Michal Mocny., Michelle Vu, Alex Christensen, Benjamin De Kosnik, Yoav
Weiss, Nic Jansma, Ryosuke Niwa, Philippe Le Hegaret, Timo Tijhof, Dave
Pifke, Gilles Dubuc, Peter H, Aaron S
Next Meeting

   - Thursday April 9th at 10am PDT / 1pm EDT

Paint Timing Issue TriageClarify what happens to a page which consists of
just an iframe

   - Ryosuke: The fact that we're exposing paint times in cross-origin
   frames can in some browsers expose information about the main frame.
   - Yoav: Does this affect other browsers?
   - Benjamin: I'm not aware offhand
   - Nicolás: In Chrome, paints are separate per renderer process, so first
   paints are per-frame.
   - Yoav: In Chrome, iframe paints are completely separate from the main
   frame paints.
   - Ryosuke: In Webkit, main frame and cross-origin iframes are painted
   - Nicolás: is that due to your first paint heuristics?
   - Ryosuke: yeah
   - Noam: Implementations could choose to not expose paint timings for
   cross-origin iframes (or any frame), as long as the developer could detect
   - Nicolás: Detection could be done via supportedEntryTypes
   - Ryosuke: spec currently doesn’t allow that. We’d need to change it.
   - Noam: supportedEntryTypes is per browsing context, so that fine
   - Ryosuke: Not great that different browsers behave differently, but
   that’s the only way to resolve that
   - Yoav: Yeah, indicating it’s not supported is better than returning
   invalid values

Allow optional implementation of first-paint

   - Yoav: From Webkit's perspective, FP and FCP are supposed to happen at
   the same time due to various heuristics, so Webkit may not want to
   implement FP (and just FCP)
   - Ryosuke: In addition, we think FP is a bad metric to optimize for.
   People should optimize for FCP
   - Nicolás: Chrome thinks both FP and FCP have value. Would be reasonable
   to make it optional. Not sure if we need developers to be able to detect
   lack of support.
   - Ryosuke: Could we have separate types in supportedEntryTypes so the
   developer could feature-detect
   - Noam: Like the idea of separate entry types. The use of “name” here is
   inconsistent with other entries
   - Yoav: We already have "paint" entry type today that is being used, so
   it would be ideal to keep it.  Do we then keep it for backward-compat?
   - Nicolás: Worried that we would need to support both forever. Would be
   better to avoid breaking changes
   - Ryosuke: But it’s only implemented in one browsers, so sites would
   have to adapt.
   - Timo: From a developer perspective, we ask for “paint” and get both
   entries or not. What breakage would we expect?
   - Nicolás: That’s my point. Making it optional is fine. Changing the
   entry type name less so, because code w3ill need to change.
   - Timo: Yeah, the API is nicely designed and enables things to be
   - Ryosuke: Concerned about compatibility concerns with APIs shipping in
   one browser. That’s not how it works.
   - Yoav: With my Chromium hat on, we’re not saying it’s impossible to
   change, but there’s a cost to that, and from what I’m hearing, there’s no
   clear use-case that would justify it.
   - Nicolás: Also, we made a bunch of changes to the spec that would now
   force us to change our implementation. So saying we’re opposing changes is
   not fair.
   - Gilles: What would be the downside of when listening to "paint" only
   getting one type or the other or both?
   - Noam: It's about expectations for the developer, what they can know
   they will get data for (or will always be missing). But it doesn’t seem
   - ...If we stuck with supportedEntryTypes of "paint", the spec could say
   that it doesn't guarantee all types such as FP and/or FCP. Maybe we should
   add other feature detection if needed.
   - Ryosuke: I’d object to adding another mechanism. If we need feature
   detection, it should be a separate type.
   - Noam: Right now, it doesn’t seem necessary
   - Yoav: FWIW, I agree that if we needed feature detection, it should
   have worked with the current mechanism.
   - … But folks in the room that actually use the API say that it’s not
   something they ever needed.
   - Ryosuke: Proposal is to update the spec to just say that FP is optional
   - Ben: Would this allow us to add a "Full Paint" as optional here?
   - Noam: We don't necessarily want each browser to have their own
   optional definitions, but if "Full Paint" is important, we can get it
   defined in the spec and possibly be optional
   - Peter: Agree as a web developer that there’s no need for more specific
   feature detection
   - Yoav: Agreement we can make First Paint optional in the spec?
   - Everyone: Yup!

Clarify whether First Contentful Paint considers content outside the

   - Ryosuke: There are different definitions of "viewport" (visual or
   layout), and detecting whether something is in the viewport can be tricky.
   - … There are a few cases where content outside of the viewport the user
   could never see (e.g. negative px offset)
   - Nicolás: I thought this is already solved with Noam’s suggestion to
   clip the bounding rect with the scrolling area. Is that not the case?
   - Noam: Current version clips with the scrolling area, so Contentful
   Paint is anything the user can potentially get to by scrolling.
   - Timo: Also depends on the directionality of the page - RTL vs. LTR
   - Noam: Falls out of the scrolling area definition.
   - Ryosuke: Does it refer to visual viewport or the layout viewport?
   - Noam: It doesn’t have a viewport. It’s about the root box
   - Ryosuke: So the viewport part is still an open question
   - Yoav: We don’t care about the viewport. We can say any paint within
   the scrolling area is contentful, and any paint outside is not.
   - … We don’t need to define which viewport we don’t care about. Because
   we don’t care about all of them.
   - Nicolás: clipping with the scrolling area is enough to clarify what
   counts. No need to reference the viewport at all.
   - Ryosuke: We can decide that viewport is irrelevant. But it’s not clear
   to me that this is the right decision.
   - … If paints happen outside the viewport and the user sees nothing,
   should they count?
   - … One argument against looking at the viewport is that it would make
   the metric more variant depending on the user’s device.
   - … Maybe the people who are using it can comment.
   - Timo: Do we want to punish websites with users on small screens?
   Difference between content available and visible. Also, computing the
   viewport can be expensive
   - Noam: Already computed for intersection observer.
   - Nicolás: but it could be expensive from a performance perspective.
   - Gilles: It would be awkward if you have content that's outside of the
   viewport, and will only show up when they scroll, then the metric would be
   dependent on user interaction.
   - … To me, that’s the strongest argument to ignore the viewport.
   - Yoav: I struggle to find cases where we have paints outside the
   viewport but not inside it.
   - Noam: When I worked at Wix, many sites would have large BG image above
   the fold, and the text below the fold.
   - … So the initial viewport would be painted after the text below the
   - … The Paint API should be as much as possible separate from user
   interaction and tied to loading time
   - Ryosuke: Avoiding dependency on user interaction seems like the
   strongest argument
   - Dave: Should we define another event for when the user scrolls?
   - Yoav: User dependent metrics are hard to reason about as different
   users do different things.
   - Noam: Also, that metric exists in the form of intersection observer.
   - Timo: True that websites should be punished if they only paint outside
   the viewport, but maybe separate from this API
   - Gilles: in the list of suggestions, we also have attribution for the
   paint, which would enable sites to see their first paint is outside the
   - Ryosuke: Attribution?
   - Gilles: which element first painted
   - Nicolás: we can have many first elements
   - Gilles: a can of worms for the future. But that may be the solution
   - Nicolás: we also have a note relating to the viewport: "... an element
   is paintable if it is within the viewport, or can potentially be in the
   viewport as a result of scrolling or zooming."
   - … Do we need to remove it?
   - Ryosuke: We can leave the word viewport in this non-normative note as
   long as we clear out the rest of the references.

Be more precise about first paint vs first contentful paint

   - Nicolás: Processing logic is a little too-informal. If it’s a “first
   paint” we mark first-paint, but there’s no way of knowing that.
   - … Some improvement could be done to keep track of that. But no need to
   discuss it necessarily.
   - Ryosuke: seems editorial

Should transparent (alpha-value=0) text be considered contentful

   - Noam: Some discussion on the issue. I think there’s consensus that
   transparent text should not be contentful, but unclear about text
   decorations: shaddows, underlines, emphasis
   - … In the PR I proposed that shadows would be contentful but
   decorations wouldn’t be, as you can’t read the text from them
   - Ryosuke: Maybe we should special case transparent text, as the user
   can still select it and interact with it
   - Nicolás: Suggested by Marcus from Mozilla, so I wonder if they are OK
   with not ignoring transparent text.
   - Benjamin: I’ll ask Marcus about that
   - Ryosuke: Where’s the comment?
   - Nicolás: Issue 58
   - Noam: And then I opened issue 75
   a result
   - Timo: The comment also mentions scales and opacity
   - Yoav: From my perspective, it’s hard for users to distinguish between
   opaque text and text with very low opacity values, or text that has very
   low contrast compared to its background.
   - … Ryosuke’s comment about text selection makes a very good point,
   because this text is potentially visible to the user.
   - Ryosuke: If the selects the text, they can also copy it. So its
   - Timo: Also for accessibility, we should treat nearly invisible text
   - Ryosuke: In accessibility cases, people put it off screen. I don’t
   have strong opinions.
   - Nicolás: Same. So let’s talk to Mozilla folks that presented the issue.
   - Ryosuke: Can you CC them on the issue?
   - Nicolás: Will do!

On Wed, Mar 25, 2020 at 12:40 AM Yoav Weiss <> wrote:

> Hey all,
> Hope you're all doing well given the extreme circumstances.
> Join us <> this week to talk
> about Paint Timing <>!! We've made
> some good progress on that front, and have some remaining issues to discuss.
> On the agenda
> <>,
> we have:
>    -
>    Paint Timing issues
>    -
>       To discuss
>       -
>          Clarify what happens to a page which consists of just an iframe
>          <>
>          -
>          Allow optional implementation of first-paint
>          <>
>          -
>          Clarify whether First Contentful Paint considers content outside
>          the viewport <>
>          -
>          Be more precise about first paint vs first contentful paint
>          <>
>          -
>       Can we close?
>       -
>          What is the scope of timings?
>          <>
>          -
>          Timestamps should be specified in an interoperative way
>          <>
> We also have a bunch of issues to triage, in case there's remaining time.
> As always, the meeting will be recorded and published online.
> See y'all there! :)
> Yoav

Received on Friday, 3 April 2020 16:52:26 UTC