[Minutes] WebPerf WG TPAC F2F Meeting 07 Nov 2017

Hi,

The minutes from the 07 Nov 2017 WebPerf WG TPAC F2F Meeting are 
available:
   https://www.w3.org/2017/11/07-webperf-minutes.html
and
   http://bit.ly/webperf-tpac17

also as plain text below:

--------------------

WebPerf WG TPAC F2F Meeting

07 Nov 2017

Agenda

Attendees

Present
Ryosuke, Alex, Tim, Shubhie, Philip, Yoav, Charles, Qingqian, Todd, 
Nolan, Xiaoqian, Guido, Nic, Philippe, Shiqing, Vlad
Regrets
Chair
Todd
Scribe
Yoav, Nolan, Tim
Contents

Topics
Follow Up discussions -- Long Tasks
Element timing
Open issues -- Resource Timing
Open issues -- User Timing L2
Open issues -- Page Visibility
Open issues -- Server Timing
Open issues -- Beacon
Open issues -- High Resolution Time L2
Open issues -- Other Specs
Summary of Action Items
Summary of Resolutions
Follow Up discussions -- Long Tasks

Tim: would like to clear up Todd’s misconception from yesterday
... Long Tasks will add an entry for any Long Task
... The reason Todd was confused is that detailed attribution only 
occurs for scripts
... Task types are not yet well specced
... Only reason they aren’t is that specifications don’t declare all 
task types so this is new.

Element timing

Proposal 
https://docs.google.com/presentation/d/1Xha-RVH_bz5mzOHi1wI5BT8AEaLd-fSYW4BKpmJmy5A/edit#slide=id.p

Tim: Goal is to observe when element are rendered
... Proposal is to register using CSS selectors
... Analytics providers don’t want to modify the HTML so attributes are 
not a great approach
... CSS selector approach means that we can’t buffer entries until an 
observer is registered, so observers need to register early on
... Analytics providers want to eventually register using HTTP headers, 
but shouldn’t block shipping element timing
... Current approach is a wrapper on intersection observer, which 
already gives us a way to see if an element is in the viewport. When 
intersection passes a ratio, we can dispatch element timing

Alex: Only first time, right? What happens when multiple element match a 
selector?

Ryosuke: Running CSS selectors on each node removal will be too 
expensive?

Tim: Can a list of IDs work?

Ryosuke: probably.

Todd: Because you have IDs, you can stop checking it

Ryosuke: Duplicate IDs?

Tim: We can probably ignore them and pick just the first one

Alex: getElementByID just returns the first one, we can do the same

Tim: The first element created with that ID will be observed

Ryosuke: so different from getElementById, which does tree order

[discussion on IDs vs. selectors vs. explicit attributes. Conclusion 
that we need to take it offline]

Tim: Is intersectionObserver a good approach?

Nolan: potential is layout viewport vs. visual viewport. 
http://www.quirksmode.org/blog/archives/2017/10/intersection_ob.html

Tim: I’ll take a look into that

Todd: IntersectionObserver can declare which viewport you mean to 
observe

Tim: Proposing `scrolledIntoView` to let people know when the element 
became visible

Charlie: Can we have 2 time stamps? One for rendered and one for 
visible?

Tim: That’s doable

[discussion about scrolledIntoView and it’s viability]

Tim: It’s a page load metric which ideally includes time spent on 
compositing

Todd: FP and FCP paved the way for that

Tim: My fear is that it would leak privacy information. 
IntersectionObserver would bypass those privacy concerns, because we 
can’t know of random draws.

Yoav: Relying on IntersectionObserver, out-of-viewport elements won’t 
get entries if the user never scrolled

Shubhie: I heard differently from developers

Ryosuke: I agree that there could be privacy concerns with exposing 
paint information

Shubhie: Didn’t we address that in FP?

[privacy discussion ensues]

Tim: We could say that hero element cannot contain third party elements.

Todd: That feels like declarative IntersectionObserver. I suggest that 
the security issues can be reviewed separately.

Yoav: Can we polyfill this with IS?

Tim: Registration is tricky, but otherwise it can be easily polyfilled.

Ryosuke: If we had an attribute in the element, you could collect the 
images, add the image decode time and this would give you a rough timing 
for what you want

Todd: Should we spec this as declarative intersectionObserver?

Nolan: We need to observe the visual viewport

Ojan: I believe that issue was fixed

Philip: I want to know when elements were visible on screen. Could we do 
it in a way that the entry includes time it was added to the DOM and 
viewport as well as when it was actually rendered? Otherwise, what can I 
do with that info?

Tim: I propose we ship this and iterate?

Shubhie: Would the IS approach work for fonts and stylesheets?

Tim: We’d need to extend it for those use cases

Philip: Ideally we’d want it in the same entry

Tim: Yeah, but would we wait for the entry for fonts, etc?

Yoav: What are the use cases that this solves beyond IS?

Tim: Even if there are none, this makes sense

Ojan: IS can be more expensive than this

Tim: We need a concrete plan of next steps that are not polyfillable 
today

Todd: A concrete site that can’t measure the thing it wants to measure 
would help

Philip: Attribute will give us buffering for free, advantage over IS

Open issues -- Resource Timing

Todd: issue 74 in resource-timing, new request for functionality. Any 
objections to move to L3?

[no objections]

Alex: why are people requesting access to this?

Todd: long discussion, don’t need to cover here
... issue 75, also L3
... issue 76, add info about local cache performance. Also new feature

Ryosuke: QUIC?

Yoav: With TLS and cypher discussion?

Ryosuke: TCP has clear steps

Yoav: TCP fast open too

Ryosuke: let’s consider those things

Yoav: The spec has to be able to deal with this

Todd: we discussed this. Many analytics vendors assume same order as 
HTTP 1.1. Need to review and clarify ordering expectations.

Nic: we filed browser bugs on this

Ryosuke: If you’re a website using analytics that doesn’t support QUIC, 
why move to QUIC

Todd: QUIC is able to be separated out
... issue 126, L2, question for the WG. Does L2 need compatibility with 
QUIC?

Ryosuke: IETF hasn’t finalized. This is google UAs only

Alex: also Google QUIC, not IETF QUIC

Yoav: standard version is not yet shipped but will be

Shubhie: we shipped because Chrome was already exposing through 
non-standard API, people were depending on it

Qingqian: blocks nginx from updating

Todd: so should it block L2?

Ryosuke: there’s only one browser that ships this

Yoav: issue is making spec resilient to variability in connection times. 
If we cover TFO and TLS 1.3 it will cover most of the QUIC-related 
issues

Ryosuke: it’s not a blocker for L2

Todd: I agree. QUIC is not yet a standard. L2 is past due

Yoav: TFO and TLS 1.3?

Todd: becoming blockers because L2 is late
... WPTests become hard

Ryosuke: if websites depend on Google’s implementation we may need to 
spec that

Yoav: goal is to merge IETF QUIC with Google QUIC

Todd: issue 87, missing test coverage

Ryosuke: do browsers support multi response?

Todd: yes, also not tested
... marking L2

Ryosuke: do we have tests for H2 push?

Todd: pushed to L3

Ryosuke: more realistic blocker than L2

Todd: should be added when we flip to fetch

Yoav: push cache is not well-specced anywhere. Spec assumes it pushes to 
the cache but no browser does that

Todd: this was triaged to L3
... issue 88, context of a SW
... this is specced. It is L2. Need tests
... issue 89, increase limit of 150

Nolan: also issue of resource buffer size vs user timing size

Nic: resource timing limits are 150, all browsers have it, this issue is 
UT not RT
... issue of 150 is fair for L3

Alex: we have the 150 limit

Todd: firefox removed it
... issue 90, add response status code, new feature, move to L3
... issue 93, determine whether to wait to queue entry

Nic: issue is for inflight resources

Todd: I made this L2 because this affects live analytics data
... issue 94, clarify if UA can clear buffer under memory pressure

Shubhie: already being addressed in perf timeline not resource timeline. 
Buffer limits are about entire timeline

Todd: this will go into performance timeline L2. pulled back into L2
... issue 95, clarify resourcetimingbufferfull conditions. The spec 
seems wrong. Moved to L2

Shubhie: we’re not forcing people to use PerformanceObserver yes?

Todd: that’s all in the perf timeline
... issue 96, clarify behavior of setResourceTimingBufferSize

Yoav: apparently there is no consistent behavior

Alex: spec should be behaved

Todd: Safari implemented since this issue
... either way, L2 with missing test coverage
... issue 100, what constitutes a downloadable resource

Tim: does fetch fix this?

Alex: no, not websockets

Yoav: file is also not in RT

Todd: Ilya says L2 is ambiguous, it’s too complex, let’s punt

Ryosuke: media range request is where UAs differ most

Todd: spec says WS and WebRTC should be excluded

Yoav: not sure why Ilya says this is a large change

Ryosuke: need to consider blob: too

Yoav: “fetch” refers to HTML5 entry point

Ryosuke: custom schemes are possible on iOS WKWebView

Todd: Windows too
... marking L2
... issue 102, expose a way to link a call to fetch to a RT object. New 
feature, L3

Yoav: back to 93. Two things. First should be L2, second should be L3

Todd: issue 107, link entry in IDL. spec formatting

Yoav: bikeshed is not a requirement here

Todd: this is L2
... issue 110, navigator preload service worker

Yoav: could add to L2

Todd: timing should be “navigation” is the issue

Ryosuke: browser could pretend to navigate without SW involved. In that 
case it’s “navigation.” this is no different

Yoav: thus should be clarifying note

Todd: marking L2
... issue 118, redirected navigations
... this is subtleties… this is L2. current tests don’t map
... issue 119, language around SW isn’t crisp
... tagging L2 given adoption of SW and fetch
... issue 122, TFO and secureConnectionStart

Alex: is it bad that those details are lost?

Todd: question is if there are problems with missing any branches

Yoav: TFO without TLS, requests fails then gets re-sent. First failed 
one is reported

Alex: can we update requestStart?

Yoav: could, but need to spec

Todd: current spec forces ordering
... TFO has deployment hurdles, but getting these orderings correct is 
goal

Yoav: what about retries?

Todd: e.g. DNS lookup, multiple IPs, first IP failed. On retry you don’t 
reset the starts

Ryosuke: from consumer’s perspective they probably care about last not 
first

Todd: details of minutia should be L3, but specifics of ordering should 
be L2
... (issue 120) implementation needs ordering to be specced
... need to figure out what impl’s are actually doing. Then maybe we can 
lock ordering

Nic: I can check data

Philippe: I’d classify this as an error, not exposed in L2

Todd: problem is order is not enforced

Philippe: if it’s not enforced, then we need to fix that

Todd: order is only partially enforced

Yoav: problem is secureConnectionStart. Everything else is covered

Todd: issue 122, NHP. we linked to wrong document

Philippe: HQ is not listed

Todd: just shipping NHP is not enough. HTTP 0.9 doesn’t have NHP, but 
Blink does return. Blink has more than what’s in the spec
... should we specify as MAY add? The list is limited

Philippe: do we need this list?

Alex: we have this in our Web Inspector, not sure how it’s implemented

Ryosuke: we use RC7301

Todd: RC7301 has a clear set of strings, and yet there are imp’s that 
expose more than this

Yoav: also there is no value between Goog QUIC and IETF QUIC. by the 
time IETF QUIC Goog QUIC will be the same thing

Philippe: maybe for experimental protocols we can add a note

Todd: as for old ones, the spec says no but implementors expose it. HTTP 
0.9, HTTP 1.0

Alex: QUIC won’t be end of experimentation in browsers

Todd: should we add old ones to the spec?

Alex: I don’t think we should add 0.9. Adding to spec legitimizes it

Todd: role of PT is to describe what is

Ryosuke: let’s aim for most interoperability. Focus on important ones

Todd: so what you’re saying is if analytics vendors get it wrong that’s 
okay
... 2 buckets. New experimental protocols. Then protocols from 15 years 
ago. And analytics vendors are using those latter protocols

Yoav: 1.0 is more prevalent than 0.9 probably

Philippe: maybe point the spec to a wiki page

Todd: 0.9 is not prevalent. But we should add 1.0.
... issue 123, how do dns and connectStart handle multiple IP
... this is L2 but no need to go deep

Alex: let’s update the processing model for resetting connectStart

Yoav: this creates holes in the timeline, which is fine. If you try the 
first connection and fail

Alex: not a hole, just time between DNS start and DNS end

Ryosuke: in H2 case you can have single DNS lookup with cross-domain 
push. You do domain lookup and everything else is zero. Can’t have two 
authoritative name servers.

Todd: is gap between domainLookupEnd and connectStart a problem?

Yoav: no

Ryosuke: could expose connection failure times in future

Todd: next goal is to drive L2 to shipping

Open issues -- User Timing L2

Todd: Triaged, we know what L2 issues exist. Nolan & Philip will 
eliminate L2 issues.

Philip: Issues seem straight forward.

Todd: Should we assign issues?

Nolan: Take this offline.

Todd: We need to lock L2 before we start L3.

Philip: How do we fork a new version?

Todd: Use a branch on the spec. We currently have a V1 and V2. We 
shouldn’t make a new branch until we’ve locked the current one.
... For server timing, with no adoption, everything is L1 until a second 
UA says they’ll ship.
... We can’t ship an RC until there are two implementations.

Ryosuke: Safari has shipped L2.

Open issues -- Page Visibility

Todd: Just published this. One L2 issue on the PR.
... https://github.com/w3c/page-visibility/issues/34
... Unclear whether an obscured window MAY flip page visibility or not.
... Current normative text mentions being obscured by an accessibility 
tool, etc
... but doesn’t cover being obscured by other things.
... Falls into the “not minimized and in the foreground tab” case.

Ryosuke: Can we just return hidden and say everything else is visible?

Todd: Being obscured by an accessibility tool is unique, so we need to 
cover that case.
... Let’s make it so browsers MAY return hidden for an occluded window.
... We have a statement about being obscured after the algorithm.
... Figuring out when a window is obscured is impossible on some 
platforms.
... MUST return visible for accessibility tool obscurement.
... Any pushback on adding this to existing PR (Page Visibility 2)

Ryosuke: The algorithm should have all of the logic, with nothing 
beneath.

Todd: Decided to add to existing PR.

Ryosuke: Can we also fix code vs strings in this block. (5.2)
... Section 6: Respec issue - visible not defined.

Todd: There may be a respec bug here, we should follow up.
... Filing respec issues in the same github issue.
... May have been respec becoming stricter.

Ryosuke: In section 4, we define hidden, but don’t define visible.
... Instead, we could add a new definition for what it means for the 
document to be visible.
... Return visible if we meet the previously defined requirements for 
“visible”.

Todd: Defining visibility states first does simplify things.

Ryosuke: What is visible and what is hidden doesn’t need to be 
algorithmic.
... This is a pretty big change though, we don’t necessarily need to do 
this.
... We may be able to make Respec happy without doing this.
... Or we can make all of these keywords strings instead of code.

Todd: Given that this is in PR, let’s do the minimal change for now.
... Another issue is that it’s hard to know if a page was ever visible.
... https://github.com/w3c/page-visibility/issues/29
... Facebook wants this to understand the period of time before they’ve 
registered their handler.

Philip: Seems like a reasonable, but short sighted request.
... There are a bunch of other things they might want to know 
retroactively.
... All lifecycle events. We could put these on the performance 
timeline.

Nic: Orientation changes would be useful here.

Ryosuke: Orientation is interesting, because it changes the viewport.
... Picture elements could fetch more resources.

Todd: Philip, you’re thinking that instead of building on top of page 
visibility,
... we could do something more general?

Philip: Yes.

Ryosuke: What signals would we want? Visibility, stopped, resumed, 
orientation.

Philip: Knowing whether any input has ever happened - TTI polyfill would 
like this.

Ryosuke: Sounds like a level 3 feature to me.

Todd: Definitely L3. Want to be careful we don’t expand the scope.
... Don’t get many asks for things other than visibility.
... Page visibility is the 80/90% scenario.

Nic: It is the most important thing for us.

Todd: Page Visibility is currently shelved in PR. I don’t think it has 
an active editor.

xiaoqian: Our last chance to update this is in 1 week.

Todd: I’ll deal with this ASAP.

Philip: We could ask Shubhie if she sees a place for this work with the 
lifecycle API.

Open issues -- Server Timing

Charlie: How do navigation timing and server timing interact?

Yoav: We need hooks in resource timing, which are called from server 
timing.

Todd: Resource Timing 2 is the place to inject this hook, as it’s 
getting ready to ship.
... Server timing just points to a linkable hook in Resource Timing 2.

Yoav: When we rebase on top of fetch, we’ll preserve this hook.

Todd: We want a pull request on resource timing 2.

Charlie: Sounds good.

Yoav: Is there a specific example we can use as prior art for this text?

Todd: Not sure. Resource Timing points at specific bits of Fetch.
... Where in the resource timing spec do we want to inject this?

Charlie: No. We may need something in navigation timing as well.

Todd: Is this before or after responseEnd?

Ryosuke: Maybe we don’t need a hook into this spec, maybe we can just 
copy some text?

Yoav: Between 15 and 16 in the processing model.

Todd: We can name these two, and then state “between these steps”.

Charlie: Or insert a step between 15 and 16 which runs something defined 
in another specification.

Todd: Up to you as an author.

Charlie: This could be any time after 15.

Yoav: If trailers is still on the table, needs to be after 16.

Ryosuke: Probably needs to be after 17 or 18.

Charlie: After we’ve got the whole response. After 17, I’ll put a named 
step.

Todd: Navigation Timing 2 explicitly says when to do resource timing 
work.

Charlie: After 19 in Navigation Timing 2, I’ll add a named step.

Ryosuke: These specs would ideally all defer to the fetch spec.

Todd: We’ve all agreed on this, but it should be in L3.

Ryosuke: So for server timing, do we want the spec to go in before or 
after we’ve rebased on fetch.

Todd: We can’t block on this. Multiple browsers have shipped for over a 
year.

Ryosuke: The question is whether server timing wants to refer to 
resource timing 2.
... Relying on fetch is probably the cleanest solution.

Todd: Oh, you’re saying server timing could say “set this member of 
resource timing when you hit this stage in fetch”?

Ryosuke: Yeah, we’ll need these hooks in the fetch spec eventually 
anyways.

Charlie: Either approach sounds fine to me.

Todd: I think Ryosuke’s feedback is good advice.
... Use a partial interface to set something on resource timing, which 
references the fetch spec.
... Should processing model cut the steps defined by 
PerformanceResourceTiming from Navigation Timing?
... https://github.com/w3c/navigation-timing/issues/78
... Would cut a bunch of words from nav timing 2.

Open issues -- Beacon

Todd: Beacon is in CR. Only thing blocking PR is tests for CORS 
requirements.
... These have been assigned to MS folks for many months.
... We haven’t gotten around to it.
... Anyone else interested in writing these tests?

Nic: Any idea how long this will take?

Todd: If no one else does anything, MS will complete this in the next 
two months.

Xiaoqian: How many tests missing?

Todd: Two to four tests, which should fit into the current framework.
... We just need to find what coverage is missing.
... Not obvious based on skimming the code what the missing tests are.
... Is there any deadline if we’re stuck in CR for too long?

Xiaoqian: No.
... Only requirement is that you need to go to CR again if there are 
substantive changes.

Todd: Seems unlikely that tests will show that spec text is incorrect.
... Let’s just wait.

Open issues -- High Resolution Time L2

Todd: Blocked on Dale on an unload test.
... There is a bug in the CR, which we should fix, in addition to adding 
this test.

Open issues -- Other Specs

Xiaoqian: We’re missing the definition for idle time in 
RequestIdleCallback,
... but we may want to address this in the HTML spec.

Todd: So this is an L1 blocker.

Xiaoqian: We could try to get consensus on Domenic’s proposal.

Ryosuke: We need some way to define idle time in terms of the HTML 5 
event loop.

Todd: Would Domenic’s proposal address Apple’s concerns?

Ryosuke/Todd: He’s saying that the event loop & microtask queue is empty 
and the browser has decided we don’t need to render, and there’s no 
worker work.

Ryosuke: This still doesn’t define how long we continue to stay idle.
... How do we decide when to set the idle deadline?
... Time in the future for which the browser “expects to remain idle”.
... If we define what it means to be idle, then perhaps this is okay.
... We should at least specify that time remaining shouldn’t exceed the 
time of the next timer, rAF, etc.
... We need normative text describing handling of active timers.

[discussion of how to clean this up]

Ryosuke: HTML 5 spec should provide a hook.
... Normative text isn’t precise enough - it conveys the intent.

Todd: We need an explicit entry in the event loop after step 8.

Ryosuke: It’s unclear what the list of “active timers” is. Should we pay 
attention to timers
... associated with other windows?

Todd: Can you file a new issue on github with your concerns regarding 
step 7 defining the duration of idle?

Ryosuke: We might want the HTML spec to define the list of active 
timers.

Xiaoqian: We’re already in PR, if we’re going to clarify this, do we 
want to hold Level 1 until
... these changes have been made, or should we go ahead with this?

Todd: This is a question for implementors who haven’t yet implemented.

Ryosuke: With only the spec text, I wouldn’t be able to implement this.

Todd: Both changes are clarifying, not changing the intent of the spec.
... List of active timers is on worker & window scope.
... Whether you listen to timers in the other scopes is an 
implementation detail, because everyone throttles background windows.
... Let’s take a minute to review the processing model.
... We need to email Ross McIlroy & Ilya to find out who is going to 
edit

Ryosuke: What’s the status of the memory pressure API?

Todd: Chrome punted on it.

Ryosuke: Can’t expose exact bytes due to security. What about bytes per 
document?

Tim: Harald proposed an event when memory has doubled.

Ryosuke: Leaks are the problem - pages pinned for months.
... You should be able to see when you ship a change whether or not 
memory pressure happens more frequently.

Tim: Ojan proposed exposing the number of documents that have been 
leaked.

Ryosuke: When performing GC, you should be able to tell how much memory 
each document holds on to. Most leaks are due to javascript objects or 
images. Images should be easy to find.

Todd: I think what you’re saying is: if you know JS heap size, image & 
video, you get most of the value.

Ryosuke: A common pattern is an app making image elements, and they fail 
to dispose of old images.

Todd: We see closures hooked up to events which reference globals.

Nolan: Given how many pages leak, the standard response might be to just 
call window.reload.

Vlad: We’ve had success using our tooling to dig in - it’s unclear how 
actionable this would be. Chrome’s performance.memory is of limited 
utility.

Todd: Are we missing telemetry, or tooling?

?: What we have in devtools is fine. We need to know there’s a problem, 
and then take it to the lab.

Nolan: You’re never going to take action based on this notification, 
it’s to dig in via developer tooling.

Ryosuke: Use case is seeing impact of shipping a new version.
... We could report with 10’s of MB’s granularity.

Todd: Let’s come back to this in a WG call. Apple cares about this.

?: We know we leak, but most pages leak. We need to know how badly we’re 
leaking.

Todd: Core question: what are the incentives to avoid leaking?
... It isn’t clear that performance.memory is actually useful.
... We talked about high/medium/low.

Charlie: What about messaging to the console.

Ryosuke: Authoring these heuristics is hard.

?: Large detached DOM trees are bad.

Ryosuke: There are some cases we can detect, but they’re cases where 
developers could easily fix if they cared.

Todd: Buggy tag managers often fix their leaks once we point them out.

Qingqian: We could penalize sites in search ranking due to memory usage.

Todd: So performance is currently used to impact rankings, so in theory 
memory could be used. But leaks tend to not happen in the first 30 
seconds. Over multiple visits you can get some idea of this though.

Qingqian: If there’s a memory API available, we’ll use it for an 
experiment.

Todd: Would you use data from multiple browsers for search ranking?

Ryosuke: One way to incentivize is to surface consumed memory. We’ve 
been very successful with this in power - people complain to sites using 
too much power.

Todd: Resource Hints - there are lots of open issues. Are we planning to 
try to publish this?

Yoav: Not sure yet.

Todd: Yoav has agreed to review issues and estimate whether he can get 
this spec to CR next quarter.

Yoav: Not aware of any open implementation issues in the implementation 
I’ve been working on.

Todd: The trickiest thing about this spec is that it’s pretty much just 
hints, which makes this hard to test.

Yoav: I think we can test that these do something - they “may” parts are 
for edge cases.

Xiaoqian: How do we determine if someone adheres to the spec if 
everything is “may”?

Yoav: In theory, every implementation passes.
... Practically, all implementations that have implemented have 
observable behavior.

Todd: We should have some more spec text to ensure browsers do 
something.
... For example, DNS prefetch. Can we test it?

Yoav: It’s testable if you have a DNS server that logs things.

Todd: So for WPT, this isn’t testable.

Charlie: Can we use resource timing data?

Todd: Networking stacks play tricks that will make this flaky.

Xiaoqian: Do we have any tests today?

Yoav: Not sure. I implemented preconnect, which mainly has Chrome 
specific tests.

Ryosuke: Perhaps we should add a test API to webdriver or similar, which 
forces these behaviors to take place.

Tim: I’m afraid of testing a browser that’s different from what we’re 
shipping.

Todd: Following up on github, let’s discuss testing strategy with 
Phillippe at a future call.

Ryosuke: Note that just because WebKit ships something doesn’t mean 
Safari will.

Todd: So should we be referring to WebKit instead of Safari?

Ryosuke: Yes.

Todd: Most spec issues appear to be editorial.

Qingqian: Can we add something to prefetch to let us know if it was 
successful?

Yoav: We could have an event triggered when a hint was ignored.

Ryosuke: There’s a risk here. Sites are more likely to start depending 
on implementation details.

Todd: What’s the use-case?

Qingqian: We try to prefetch a page, if it fails multiple times, we’ll 
stop prefetching for other users.

Yoav: Prefetch already has onerror, which you can use in the failure 
scenario.

Todd: Is it true that all link resource hints MUST implement all link 
element events.
... Current spec says SHOULD

Yoav: There’s also a lot of irrelevant stuff here. Hint probability 
should be removed.
... “as” attribute should be removed.
... Lots of cleanup.

Charlie: Giving DNS prefetch event handlers would make testing easier.

Ryosuke: It’s valid to fire neither onload or onerror, as a browser can 
just ignore the hint.

Yoav: You can test support with rel-list.
... Prefetch shouldn’t have a separate processing model, it should be 
hooks in the HTML spec.

Todd: This would mean onload & onerror SHOULD fire.

Xiaoqian: Is SetImmediate still in our charter?

Todd: Nope.

Xiaoqian: Should we move it to WICG?

Todd: Looks like we may need to. We’ll want to bring it back in to our 
charter soon.

Xiaoqian: Moving it to WICG and then into the charter means we don’t 
need to recharter.

Todd: We removed SetImmediate from the charter because Chrome and 
Firefox had pushback at the time.
... Now Firefox is interested in implementing, and some Chrome folks are 
interested.

Ryosuke: It would be nice if SetImmediate happened before painting.
... Suppose you have a click event handler. Scheduling something as a 
microtask causes it to run too early. We want to run something directly 
after we’re done dealing with event handlers.

Todd: rAF executes for the next paint in some browsers, not for the 
current frame.

Ryosuke: rAF as specced is about what we want.

Todd: But it wastes a bunch of time.
... Probably need multiple APIs.

[discussion around chartering etc]

Todd: We don’t need to move to the WICG, we’re fine just not formalizing 
further until we recharter.

Xiaoqian: Any thoughts on IntersectionObserver?

Todd: We’ve reviewed this spec a bunch of times.

Ryosuke: We’ve also looked through this.

Todd: There is one performance issue. dbaron has called out the the 
ordering of events seems wrong given that intersection observer is based 
on the output of style and layout.
... Maybe we should make it clear that render steps includes something 
called style and layout.
... The spec authors were trying to enable implementations off the UI 
thread.

Xiaoqian: I’ll take this feedback to the IntersectionObserver authors.

[concerns over making Navigation / Server timing be based on fetch]

Todd: We can refer to fetch directly instead of going through 
ResourceTiming for now.

Vlad: Can we get data on ResourceTiming when a service worker takes
... a long time to respond, and then doesn’t have a resource?

Yoav: Can we return server timing from the service worker?
... It gives you the most flexibility.

Xiaoqian: We could branch L3.

Todd: Because L2 is so far behind, we’ve chosen to lock at L2 before 
working on L3.

Summary of Action Items

Summary of Resolutions

[End of minutes]

Received on Wednesday, 8 November 2017 01:13:58 UTC