Available at
http://www.w3.org/2015/10/07-webperf-minutes.html
Text version:
Web Performance
07 Oct 2015
[2]Agenda
[2]
https://lists.w3.org/Archives/Public/public-web-perf/2015Oct/0003.html
Attendees
Present
yoav, plh, todd, ilya
Regrets
eliperelman
Chair
Ilya
Scribe
plh
Contents
* [3]Topics
1. [4]Definition of current document
2. [5]Clarify Resource Timing terminology
3. [6]Can hidden attribute be removed? (Page Visibility)
4. [7]queue Frame Timing events for each fully active
document
5. [8]User Timing rewrite and cleanup
6. [9]Implementation links in specs?
7. [10]Resources Hints
* [11]Summary of Action Items
__________________________________________________________
Date: 07 Oct 2015
Definition of current document
The term current document refers to the document associated
with the Window object's newest Document object.
The term current document refers to the Window object's newest
Document object.
Ilya: looks like it's in plh's pile
... we can raise a bug against the html spec
... I'll raise it
Clarify Resource Timing terminology
<igrigorik> @
[12]https://github.com/w3c/resource-timing/pull/38
[12] https://github.com/w3c/resource-timing/pull/38
plh: I'll address the history section
... and merge it after that
Can hidden attribute be removed? (Page Visibility)
[13]https://github.com/w3c/page-visibility/issues/12
[13] https://github.com/w3c/page-visibility/issues/12
Yoav: do we want to deprecate one?
[14]http://www.w3.org/2013/02/pv-cr-report.html
[14] http://www.w3.org/2013/02/pv-cr-report.html
Ilya: not sure if we have telemetry
Yoav: we could also add a note but we need stats first
Todd: the hidden attribute is one of the most used attributes
that are currently monitored
... visibilityState is used less
Ilya: sounds like we can add a note but not deprecate it
... I'll propose one
... also unloaded is not supported by any browser
... I'll open an issue
Yoav: it's optional in the spec. remove?
Ilya: we'll tackle those changes before publishing a new draft
queue Frame Timing events for each fully active document
<igrigorik> @ [15]https://github.com/w3c/frame-timing/pull/50
[15] https://github.com/w3c/frame-timing/pull/50
Ilya: FT doesn't account for iframe, only for current document
Todd: might be worth asking Eli to look at it
Ilya: ok
Yoav: diff between active and current document?
Ilya: some documents that may be suspended
Yoav: so they may be current but not active?
Ilya: correct
User Timing rewrite and cleanup
Todd: for clearMarks, it will change the return values for
getEntries
... it says it empties the mark list, but need to clean the
performance entry buffer
Ilya: set of objects associated with the performance object
... which is the timeline
... and user timing will follow that
plh: ok, i'll continue to iterate
Implementation links in specs?
plh: see what I did for
[16]http://w3c.github.io/page-visibility/
[16] http://w3c.github.io/page-visibility/
Ilya: I wouldn't want to keep an up-to-date list. linking to
can I use and make sure.
plh: I'll update all of our specs to add the info
[17]https://github.com/w3c/web-platform-tests/tree/master/page-
visibility
[17]
https://github.com/w3c/web-platform-tests/tree/master/page-visibility
[18]http://w3c-test.org/page-visibility/
[18] http://w3c-test.org/page-visibility/
plh: I'll link to both
Resources Hints
Yoav: dnsprefetch doesn't work when the page is https
... there is a flag for it
... it's off by default
<yoav>
[19]https://www.chromium.org/developers/design-documents/dns-pr
efetching#TOC-DNS-Prefetch-Control
[19]
https://www.chromium.org/developers/design-documents/dns-prefetching#TOC-DNS-Prefetch-Control
Yoav: same is true for firefox
... I don't understand the restriction, since we'll need to do
the dns request eventually
"This restriction helps prevent an eavesdropper from inferring
the host names of hyperlinks that appear in HTTPS pages based
on DNS prefetch traffic. "
Yoav: can we remove the restriction?
Ilya: my guess is that it's tied to the predictor
... and we didn't want to leak information
... and we just carried the same mechanism in the dns-prefetch
... but I agree with you
Yoav: I'll open an issue and loop in Mike West and Ryan, and
others (Firefox, MS)
... everyone should dns-prefetch over https because limitating
it doesn't make sense
... I'll raise a spec issue
[adjourned]
<yoav> igrigorik: You were right. The reason this dns-prefetch
limitation exists is coupling between explicit <link
rel=dns-prefetch> and speculative prefetching of DNS for <a
href> in the page
<yoav> I'm not sure it merits a spec issue, or just filing
patches to decouple that
Summary of Action Items
[End of minutes]
