Date: 07 Oct 2015
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
<igrigorik> @ https://github.com/w3c/resource-timing/pull/38
plh: I'll address the history section
... and merge it after that
https://github.com/w3c/page-visibility/issues/12
Yoav: do we want to deprecate one?
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
<igrigorik> @ 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
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
plh: see what I did for 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
https://github.com/w3c/web-platform-tests/tree/master/page-visibility
http://w3c-test.org/page-visibility/
plh: I'll link to both
Yoav: dnsprefetch doesn't work when the page is https
... there is a flag for it
... it's off by default
<yoav> 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