Participants
- Nic Jansma, Benjamin De Kosnik, Carine Bournez, CP Clermont, Michal Mocny, Nicolás Peña Moreno, Noam Helfman, Peter Perlepes, Steven Bougon, Yoav Weiss
Next Call
April 15th 2021 @ 10am PST / 1pm EST
Meeting Recording Survey
Topics
Publishing - Yoav Weiss
- Yoav: As part of Noam’s work on RT/Fetch, we need some changes in HRtime and others
- … Publishing those changes was a bit of a manual process
- … Had setup auto-publishing of HRTime in 2015, but the pipeline broke since then
- … Seems we can refresh that decision
- … First question I’d like to ask is if we can make that decision, or if there are objections
- Noam: Can you clarify what auto-publish means?
- Yoav: There’s a working draft (e.g. TR) published on the W3C site, a published working draft
- … Whereas when we work on editor draft of specs, they are not automatically published unless we decide they should be
- … Which means other specs cannot reference them without explicit links until we published those
- … Auto-publish commits so when we land PR in HRTime, ResTiming, etc, so it goes to w3c.org/TR/[spec-name]
- Noam: Makes sense
- Yoav: Does it no longer apply to specs not in Working Draft?
- Carine: We can do that for CRs as well
- … Just for Transition Request we can’t do that
- Nic: Are there any downsides to auto-publish?
- Carine: Mostly a benefit to editors, no other downsides seen
- Yoav: Decision made to auto-publish for WD and CR specs
- … Other than that, I was looking at spec status spreadsheet
- … HR-Time 3 is a working draft, and it’s fine to leave it there for now
- … PerformanceTimeline L2 is a working draft. L2 was in PR and changes made brought it back to a WD as a result. Now we have 2 WDs in parallel.
- … In my mind it makes sense to take L2 to CR->PR->REC
- … Issues marked as L2 are currently closed, other than an issue asking that tests are clean
- … Make sense to move PT L2 to CR?
- Nicolás: Why was it moved back
- Yoav: Added feature: supportedEntryTypes and buffered flag
- Nicolás: Only see supportedEntryTypes
- Yoav: Can do more archeology.
- Nicolás: Makes sense to ask if people have objections to the additions to L2 and then move it to REC
- Yoav: We removed buffered flag from L2 and put in L3 only.
- … Added type as well
- … Question for Carine: Do we need anything beyond working group decision to move PerfTimeline L2 to CR?
- … And if that is sufficient, can we do that now?
- Carine: We can do that now on the call, and get it in the minutes. We need to get a sense if there are objections.
- … Would be more comfortable with a Call for Consensus by email, since it wasn’t on the meeting’s agenda
- Yoav: I can take an AI for a CfC for moving PT L2 from WD to CR
- Carine: Is there something in L3 we want to publish now?
- Yoav: L3 has buffered flag, was there anything more?
- Nicolás: I also added number of dropped entries. Nothing beyond that.
- Yoav: Makes sense to publish L2 to REC and then move L3 to the living standard model.
- Carine: If we are sending a CfC for L2, we could also ask to publish a FPWD of L3
- Yoav: Auto-publishing is a tooling issue beyond the decision we recorded a few minutes ago
- Carine: once we transition to FPWD
- Yoav: Also AI to publish First Public Working Draft for L3
- Sean: Quick addition: in L3 the disconnect method also clears the options list, which L2 didn’t have
ResourceTiming and NavigationTiming + Fetch
- Yoav: Noam R. is doing a lot of work with integration Fetch into RT/LT, which was a barrier for us moving from L2 to L3
- … Also if we can abandon the move L2 to REC for RT/LT and move to Living Standard now that we have Fetch integration behind us
- Benjamin: Yes let’s not have a dual-track model
- Yoav: Carine what would be the procedural bit here? CfC for moving them to Living Standard model?
- Carine: The resolution would be to keep the two levels?
- Yoav: Resolution would be to drop L3, stay on L2 forever-more, and move that to a CR-based Living Standard
- Yoav: We need a CfC for call to CR for RT
- … for NT since there’s significant work from Fetch integration, that may result in downgrading it to a WD, but once we have both of them in CR, do we need anything else for them to be a Living Standard?
- Carine: It stays in CR forever basically, and something in the document says it’s a Living Standard
- … RT L1 since it was never a REC do we drop it?
- Yoav: I don’t think RT L1 has open issues.
- Carine: I suppose why it’s still L1 is in CR it’s for testing
- … It’s CR since 4 years ago
- Yoav: I suspect it’s just because we haven’t done a good job making sure it’s not in CR for 4 years
- … Looking at the current WPT tests for RT, we may need to analyze which tests are L1 related
- Carine: If the group wants to say it’s a Living Standard, drop levels all-together in some way, that’s OK as well
- Yoav: Don’t have strong opinions, have a slight preference for pushing L1 forward to REC, then make sure that’s documented.
- … Apple never implemented L2, but they are not on this call. Any other strong preference? On L1 should we publish or abandon it?
- Sean: I personally find having all sorts of Levels confusing
- … When we implement stuff, we’re always referring to the latest one. So having L2 and L3 mixing in, why do we have both?
- Yoav: The point is not to have both L2 and L3, but I think you’re saying that levels in general are confusing
- ... I can formulate an email to the group about moving L2 to CR, as part of that also see if anyone has strong opinions about keeping L1 or if we can abandon it.
- Benjamin: And then L3 will be Living Standard?
- Yoav: We would abandon L3 (which didn’t have work), and move L2 to Living Standard
- Benjamin: Sounds good
- Carine: So that would essentially mean abandoning levels
- Nicolás: Should we do that for PerformanceTimeline too?
- Carine: That would mean changing the previous resolution to merge PerformanceTimeline L2/L3 and move to CR.
- Yoav: Move L2 to CR, merge L3 to L2, and L2 will be Living Standard from now on
- Nicolás: I think of it as renaming L3 to L2
- Yoav: CfC is the same CfC, just the path is different. Instead of taking L2 to REC, merge L3 to L2 and make it Living Standard.
- Nicolás: L3 is a superset of L2. No need to merge.
- … Right now we have two branches, L2 and gh-pages. Just renaming gh-pages to L2.
- Yoav: You can look at it as merging, other than that we won’t be doing any merges
- Carine: Looking at proactively where we can publish this
- … I think we could reclaim the short name “performance-timeline” without the number at the end
- Yoav: If we can reclaim that for L2 that would be ideal
- Carine: L1 did not have “performance-timeline-1”. “Performance-timeline” points to L2. We can remove “L2” from the title. Remove “-2” from URI.
- … You can also find a “-4”, we may need to fix that
User-Timing
- Yoav: We have published L1 and L2
- … L3 is a Working Draft, would be worthwhile to push to CR, and make L3 the Living Standard
- … Any objections?
- Sean: Is my understanding correct that we call CR “Living Standard”
- Yoav: We now have two versions of Living Standards. One is that we push a spec to REC, then re-publish as REC for any future changes (but there is a process with that).
- … The easier version is that we push to CR, say it’s a Living Standard, and future changes don’t require as much process.
- … In a similar way where Fetch and HTML spec in the WHATWG.
- … Requires some sort of group consensus
- Sean: So if we do that for User Timing and we move L3 to CR, do we still need L1/L2 in REC status
- Yoav: They will remain published, but we can generally ignore them as historical artifacts
- Carine: We can claim they are superseded by higher levels. We generally keep older revisions, where there are cases where 1.0 is easy to implement in some cases, and 2.0 has additional features. And people want to keep 1.0 where use-cases for earlier versions still exist. Which is not the case here.
- … For this working group, I think we always want people to implement the highest level
- … So we have to remove L3 from title, push to CR, declare it supersedes L2 and L1 when we enter Recommendation, and use Process 2020 to amend the REC
- … Another possibility is to enter CR, and stay in CR forever. That way we don’t supersede L1/L2 RECs, but we can obsolete them.
- … And then once a year publish CR snapshots, which are CR required for approval
- ... For the moment the forever-CR versus REC, it’s not clear which is best for each working group
- … We need to go to CR for L3 which is just in WD. We don’t need to decide that now.
- Yoav: I think the group previously decided the forever-CR model is more favorable
- … We can start by pushing WD to CR, revisit in future if needed.
Page-Visibility
- Yoav: Currently in PR
- … One HTML integration issue to resolve, then we could potentially take it to REC
- … Probably need to do that first before we make the decision?
- Nic: How much work would it be to resolve that issue?
- Yoav: Issue 51
- Michal: Finish line perhaps as little as as a day. It’s well-outlined what it would take here.
- ... Changes to this spec, HTML and dependencies, but not too bad
- Yoav: Something you’d be able to push in near future?
- Michal: I think so
- Yoav: In order to move to REC, this is the last issue
- Michal: I will take it
- Yoav: Testing status we’re in perfect shape
- Nicolás: PV testing isn’t the most complete
- Yoav: I think it takes a lot of manual tests
Beacon API
- Yoav: 0 open issues, currently in CR and we can take it to PR
- … As far as tests go, we are almost green, two implementations for each of the tests
- … Do we need a perfect score on tests to move to PR, or can we take to PR and fix tests on way to REC
- Carine: It doesn’t have to be perfect, if we can justify and identify the issue then that’s OK
- Yoav: We have 2+ implementations passing for each test
- … To move that to PR, is that a CfC but a separate one?
- Carine: I’d rather have a separate one
- Yoav: AI to CfC
Yoav: Feels like something we’d want to move to Resource Timing
Nic: I think there’s a similar issue there
Nicolás: You mentioned in the NavigationTiming issue that it would require some opt-in?
Yoav: I think that it won’t for NT, but would for RT
Nic: RT#90 is a duplicate on the RT side
Yoav: Makes sense to fold this one into the other one
Nic: Clarification question around what the time titled “AppCache”. What components can contribute to that time in the diagram. Yoav, you commented around it.
Yoav: AppCache is dead, let’s not bother with defining its delays too much. Benjamin - what about Firefox?
Benjamin: deprecated
Nic: In the case of NT, it’s not the AppCache feature, but we were referring to the browser cache in general. In the diagram we have AppCache before DNS connection. It was meant to cover the browser cache - how long it took to get the resource from disk cache. The name changed over time, but it’s not about the AppCache feature.
Yoav: As far as implementations go, either we fetch the resource from disk cache, or ignore the cache and go to the network. AFAIK, there are no scenarios where we wait on disk, and only then go to the network. I’m not sure that definition makes sense.
Nicolás: You’re saying that’s measuring when we try to see if it’s in disk cache and fail do we then go to the network? I also don’t understand what’s the delta between fetchStart and dnsStart.
Nic: We often see a non zero delta between those numbers and assumed it’s disks spinning up
Yoav: I’d assume we won’t go to disk unless we know we find something there
Nicolás: Worth investigating what’s happening there
Nic: In IE that time was accessing the cache index, which may not have been in memory
… I can see if today we still see a difference there
… The basic question was “what is that time?” We can try to inform that decision a little bit
Yoav: It would be interesting to do some research there.
Nic: Out of time, just wanted to point out great work on RT Fetch integration.