Participants

Nic Jansma, Yoav Weiss, Adrian de la Rosa, Barry Pollard, Carine Bournez, Giacomo Zecchini, Guohui Deng, José Dapena Paz, Mike Henniger, Noam Helfman, Luis Flores, Alex Christensen, Joan Leon, Jase Williams, Leon Brocard, Philip Tellis, Joone Hur, Michal Mocny

Admin

Next Meeting

2026-01-29 at 8am PST / 11am EST (earlier slot)

LoAF & Element Timing (ET) FPWD

Yoav: As part of rechartering, it'd be good to have them in FPWD for both of them, call for consensus for that
... Thoughts if we should not do that?
Barry: Concern about Element Timing from other implementers?
Yoav: Element Timing was adopted
Jase: I think concerns came after adoption, but more in context of whether Container Timing supersedes Element Timing, do we need both?
Carine: We need to decide if we want that in the charter or not
... Have discussion first, then publish which one we think is the right way to do that

Container Timing (CT) - Adoption?

Yoav: Brings us to adoption of Container Timing
... Separate incubation
... I think we had relatively broad support for it
... If we want ET+CT be a single spec, now would be a good time to make that move
Bas: To what extend would CT supersede ET?
Michal: Looking at this recently, surface value, it feels like an extension (only adds new capabilities).
... Because ET applies to a single element, it exposes a little more metadata about that element, where CT exposes a summary of a full container (e.g. bounds of element are not exposed to CT)
... Could say if container is a single element then expose this data
... Or maybe you represent the single largest element
Jase: There are some things we don't have like load time for images, don't consider those in CT
... We definitely could
Michal: I don't think it's rocket-science
... I'd be for merging as an extension
... ET also supports post-interaction events
... Whereas CT is just an initial load metric
... Mechanism for ATF primary content
... Don't know if this restriction needs to be there
Jase: Issue for that, happy to discuss more
... Followed LCP's path for that
Michal: Simplifies a lot for CT, but removes a powerful use-case for ET
Jose: Problem is when you scroll, area is less predictable
... Maybe we should have different time of CT events, incremental
... Send latest painted areas, compared to previous paints. Continuous feedback on paints in CT
... Slightly different use-case
Jase: Does anyone have an issue with having these be the same if we're working towards covering features that ET has?
Yoav: I don't think the two APIs have to be identical for them to live in a single document
... Main concern with changing ET is back-compat, since it's being used in the wild
... Underlying algorithms being shared by these two APIs, easier if they're in the same document
... Main argument we heard in the past against it is if some implementations want to support one but not the other
Michal: ET is popular API in Chromium
... Any working rollout of ET will work with CT
... Might be people who have misdeployed ET and aren't getting entries, and now they'd start getting new data
... I think it'd continue working as-is
... Some API differences we'd have to make compatible
Bas: Realistic chance we'd want to adopt CT but not ET. Whether there's good reasons for that, I can't say off the top of my head.
... That might be the reason why we'd object to merging
Carine: For ET FPWD for rechartering, it seems from this discussion we're not ready for that. We would need to at least publish at the same pace. Once it's called ET, it's difficult when it would implement CT
Bas: Has Apple signalled intention?
Alex: I don't think so, but I can double-check
... If they were combined, I don't think it would prevent us from shipping one vs. another
... But web platform tests being combined would be kind of annoying
Yoav: Theoretically we could find a name that covers both areas and split WPTs under that
Bas: Doesn't sound like it's clear that support from two engines of two parts would be the case
Carine: Not clear what solution is
... What I'm hearing today is we're not ready for publication because we're not ready for scoping of that spec
... Charter could say we're working on scope, since we already have input from ET
... Input from CT, we're working on scope
... We can have charter without an obvious published starting point, we say we're going to work on it
... CfC for only LoAF in that case
... For LoAF there's also the question of the name (can be part of CfC)
Jase: Sounds like we haven't made a decision about merging
... Can we move spec under w3c/webperf or incubation?
Carine: We can move it into WICG
... We will have an open issue about charter
... Continue discussion in another repro until that decision has been made
... WICG is under same guidance as W3C
Yoav: We can ensure it moves there
Michal: Sounds like, there's at least two implementor interest (maybe no timeline)
... I don't have any concerns about putting it in WICG while we work this out
... We've been merging more and more together
... This is the "container feature" of the element timing API
... Ready to adopt, no concerns over that
... Sounds like no concerns around merging
... Element timing already has a container concept in it, surprising to people when it doesn't work, so merging this would help

Navigation confidence/Charter

Yoav: One of the things causing blockage here, is what's discussed in the next bullet point. Two intents to implement that is currently part of the charter.
... Wasn't part of the draft of the charter that the chairs put forward
... Was adopted downstream somewhere in the process
... Not all features covered in working group specs have multiple implementations
... At the same time we have no process for getting support from implementors, wasn't something chairs predicted
... Other WGs have processes we could emulate, and we could adopt as part of the new charter
... We could have things in our spec that aren't covered by multiple implementations, need to figure out what to do
... Already a problem in Resource Timing (may be getting resolved)
... Already an issue in NavigationTiming (talking about soon)
... CT/ET doesn't have implementation for multiple engines
... Broad spectrum specs is in a weird shape, what would constitute "support"
... What do we want to do with features that rely on specs that this WG covers but don't have that support
... One option would be for those to live in PRs forever (WHATWG for a while, untenable)
... Another is monkeypatches, no one wants that, fragile and gets out of date
... Third option is to have those features in the spec, marked specifically as lacking consensus, don't know if this is something other folks are OK with or not
... Would make it easier for hooking features into existing algorithms that have consensus
Michal: I think that makes sense
... Curious with projects like Baseline, is there overlap lacking consensus on spec vs implementation
Yoav: Some features have spiritual support but not implementation support
... Could be reverse, implementers wants to get rid fo something
Carine: If you are in CR, there is consensus about content
... What is lacking is implementations, and we're in the middle of development or testing
Yoav: For living standards as well?
Carine: Currently we have eternal CR model since it was a way at some point to make changes without considering we're breaking standard
... Process as it is now, we can make changes to REC
... Once we reach obvious state that it's tested and operable, it becomes a new REC
... We can append RECs
... Our group stays in CR forever
... Confusing from people if it's because it's not adopted, or tested, or if group keeps making things
... From reading list of deliverables in previous charter it's obvious things staying in CR forever are untouched
... We should move them to RECs
... If they're not, it's because we're unfinished, is the message we're sending
... Lacking consensus vs. Lacking implementation
... Should stay in WD and not move to CR if lacking consensus
... We have lots of specs on WD
... If we look at ET, looking at adoption, there is an implementation, point of standardization is there are several that are interoperable
... If we go to REC trac, there is an incentive
... Goal is to leave draft state by finding consensus
... And leave CR state by finishing testing
... At least every feature has 2 implementations to know it's tested
... If intent to ship parts of spec not there yet, we can make the case
... Different from staying in CR for 5 years without moving to REC
Barry: If we have something implemented only in one browser, like CT, we're still allowed to talk about it
Yoav: We can definitely discuss things in this group. We can discuss incubations not in the charter of this group. Things being worked on in WICG or Fetch
Barry: Intent of having in charter is we're responsible of specs
Yoav: Responsible for publishing these specs as standards is goal of the charter
Carine: Also defines what the starting point is in terms of IP
... If it comes from another group or outside it clears
... If we receive it from preceding, if we're unclear of IP, it's going to be a problem
... Charter is saving us from those issues as well
Barry: Most things start outside group and come inside
... Are those things donated as IP
Carine: When published as FPWD, people that join charter agree to what was in scope, then something brought in by a company in the group, they have a 6 months from FPWD to exclude from WD for it to be included royalty-free
Yoav: Going back to Navigation Confidence
... Chromium is now shipping, under impression we have consensus
... Realized it's not necessarily the case
... Mozilla is objecting to the feature being part of Navigation Timing
... What should we do with that?
... One thing in the spirit of discussed earlier would be to provide proper hooks for feature in NT, but exclude the attribute and algorithms into another spec outside NT (WICG?) that would cover that attribute
... As part of charter, we can discuss where we want those features to be, live in external specs and rely on hooks, or be part of this WG specs with some annotation that it doesn't have consensus
Barry: We need to be able to iterate specs, and don't want to slow down on being able to implement
... Separate spec or not?
... We can't just freeze these APIs and just say there's no implementor agreement first
... From a developer POV, having multiple small feature specs that hook into each other is not ideal
... PaintTiming which is FP and FCP and there's bits in the spec saying it's optional
... Then we'd still have to cross the bridge to figure out agreement
... Prefer that to monkey-patch
Bas: I think in general, Navigation Confidence is of interest here
... You're right where objections revolve around whether people need a feature
.. Based on internal feedback, there's a risk to users and privacy
... Those are more special objections in a way, form a stronger barrier
... If there are severe concerns about what an addition to a draft, has a consequence for users of web, less happy about it being in a spec that we otherwise intend to support
Yoav: Spin up issue on NavigationTiming what we're doing with this in immediate, in charter discussion we'll discuss broader picture of how we want the evolution of existing specs to happen
Bas: We have a fair amount of things where we have concerns around fingerprinting/privacy
... Need to be more mindful about those than things about lack of a desire to implement

Minutes

Device Memory: Update recommended upper and lower bounds - Barry

https://github.com/w3c/device-memory/issues/50
Barry: Looking at Device Memory API
... Currently only supported in Chromium
... Emits e.g. 0.25 GB through 8 GB
... Set an upper and lower bounds, recommendation capping at 0.25 and 8
... However in example it shows it can only have a specific list
... Increasingly looking like lower-bounds are rare, and privacy thoughts, these categories are no longer fit for purpose
... Would like to remove the lower ones
... Confirmed by Akamai, rare
... Also needs to go higher at the top, e.g. performance implications from AI
... Gemini won't work unless you have 16 GB RAM on your machine
... Would be nice to give e.g. cloud fallback if you have less
... API currently in WebPerfWG charter, some questions if it should be since only Chrome implements
... 1. Should we update limits?
... 2. Open PR where it suggests it's open to implementers what limits are chosen?
... 3. 16GB isn't common on mobile, different limits on mobile vs. desktop, mobile 2/4/8 mobile, desktop up to 32
... We do see some traffic where 16 GB on mobile, maybe that's emulators?
... We work in powers of 2, so 24 GB would roll back to 16 GB
Guohui: I believe there is conflicting text in the document today, I have an open PR
... https://github.com/w3c/device-memory/pull/53
... Propose we change the spec text. We do have recommended value, and implementations are free to adjust.
Barry: Two things. One is whether the implementor is allowed to make changes to the list.
... Two is whether the bounds should be changed by Chromium
Guohui: Old text says can adjust the value over time
... I'm thinking even at the same time, it can be different by different devices
... I think there are other situations where implementations can show different values, e.g. by country
... Would like to explicitly say, we give guidance, and implementation can adjust the value very flexibly
Yoav: I think including specific values in initial spec was potentially not a great move, making these bounds implementation defined, what the implementation intends to do, and make sure implementers know which buckets have a large chunk of the population in them
... Make it explicit it's OK to be device dependent or class dependent
Nic: same, good case to make these changes
Philip: Concerns about going to 32/64GB of privacy, identifying a small subset of users
... Recommendation that global trends should be looked at what usage looks like
... Something we could add to help making that decision
... Also for knowing what kind of hardware is becoming available
... Suggestion needs to be part of the spec if we're increasing limits
Yoav: You're suggesting that limit could be location dependent?
Barry: Personally I'm against making it overly complex, e.g. implications of by-country limits being lower could stop from video playing
... Complexity of what developer might know what it means could be a concern
... Update documentation on MDN
... I have looked at geo data, 16 GB is less common in certain geos, but surprisingly common in sub-Saharan Africa, South Americas, Brazil, etc
... Final point is that RUM Archive can't look at this by what is in the data (top end)
... Recommended upper bound has limited visibility

Participants

Admin

Minutes

Device Memory: Update recommended upper and lower bounds - Barry

CSS performance - Yoav