Participants
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 Hedenskog, Aaron Schulz
Next Meeting
- Thursday April 9th at 10am PDT / 1pm EDT
Paint Timing Issue Triage
- 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 together.
- 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 this
- 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
- 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 optional
- 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 crucial.
- ...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!
- 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 fold.
- … 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 viewport.
- 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 here.
- 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.
- 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
- 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 as 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 content.
- Timo: Also for accessibility, we should treat nearly invisible text differently
- 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!