| 00:07 | <GPHemsley> | grazie |
| 00:12 | <TimothyGu> | Hey all *.spec.whatwg.org seems to be down, is this a known issue? |
| 00:12 | <TimothyGu> | curl: (7) Failed to connect to html.spec.whatwg.org port 443: Connection refused |
| 01:22 | <GPHemsley> | TimothyGu: I'm going to say yes, assuming it's the same issue as w3c-test.org |
| 01:22 | <GPHemsley> | (though the symptoms are different) |
| 01:22 | <TimothyGu> | hmm w3c-test.org was down for me yesterday, while whatwg.org starts not working today |
| 01:24 | <GPHemsley> | well then... MikeSmith? |
| 02:08 | <MikeSmith> | if w3c-test.org is down it’s my fault, if whatwg.org is down it’s Hixie’s fault |
| 02:08 | <MikeSmith> | oh both are down |
| 02:09 | <MikeSmith> | I pinged Hixie about whatwg.org |
| 02:09 | <MikeSmith> | did not hear back from him yet |
| 02:11 | <MikeSmith> | ah about w3c-test.org we changed the commands for starting it |
| 02:11 | <MikeSmith> | *the commands for starting wptserve |
| 02:11 | <MikeSmith> | so I need to update my init script |
| 06:32 | <MikeSmith> | GPHemsley: I run w3c-test.org, Hixie runs whatwg.org |
| 07:05 | <MikeSmith> | Domenic: ah OK I see now |
| 09:42 | <Ms2ger> | whatwg.org is down? |
| 09:45 | <annevk> | Ms2ger: yeah known |
| 09:45 | <Ms2ger> | I'd look at the logs, but they're down too |
| 09:46 | <annevk> | I don't think it was reported here yet, but I might have missed something |
| 10:33 | <Ms2ger> | If a video stops because it reaches the end of the video, does it also get a 'pause' event? |
| 10:57 | <annevk> | Wow, even Live DOM Viewer is down |
| 10:57 | <annevk> | It's serious now |
| 12:14 | <Domenic> | Everything seems back up |
| 12:15 | <annevk> | Wow that just happened then since I pushed something a minute or two ago and it failed |
| 12:46 | <rnd123> | hello, i have a problem with my implementation of microdata and google's image search service, is this the right place to ask things about it? |
| 13:24 | <wanderview> | Domenic: if the UA is consuming a ReadableStream with a js internal source... is the UA allowed to "steal" or transfer the Uint8Array buffer to avoid copying? I assume its not since in theory the js internal source could still be holding on to it? |
| 13:24 | <wanderview> | I guess maybe the UA could do some kind of copy-on-write sort of thing |
| 13:24 | <JakeA> | wanderview: I think Domenic was thinking of a special stream type or option to enable transferring |
| 13:25 | <wanderview> | there is byob streams... but I think this is different, maybe? |
| 13:25 | <JakeA> | Yeah they're different |
| 13:25 | <wanderview> | JakeA: we're not really in a position to do the no-copying optimization stealing the buffer would allow... but if it wasn't permitted by the spec then I would feel better about not implementing it :-) |
| 13:25 | <JakeA> | I think it's complicated if you have an object stream and you want to specify which parts are transferrable |
| 13:26 | <JakeA> | wanderview: It'd be great if it was supported if all parts of the stream were behind the scenes |
| 13:27 | <wanderview> | JakeA: we definitely support it for native sourced streams |
| 13:27 | <JakeA> | eg, piping three items of the cache to a single transform stream that doesn't have a chunk handler |
| 13:27 | <wanderview> | or will |
| 13:27 | <wanderview> | hmm |
| 13:28 | <wanderview> | I guess we would not support the appending without copying, though |
| 13:28 | <JakeA> | wanderview: I may be wrong https://streams.spec.whatwg.org/#dfnReturnLink-1 |
| 13:28 | <wanderview> | JakeA: I guess you mean if the Uint8Array chunk was marked as "originally came from native code" and we never dirtied that bit by going through a js handler... then we could steal it |
| 13:29 | <JakeA> | oh, that link wasn't charable |
| 13:29 | <JakeA> | shareable |
| 13:29 | <JakeA> | wanderview: https://streams.spec.whatwg.org/#transfer-array-buffer |
| 13:29 | <JakeA> | looks like transferring happens by default with bytestreams |
| 13:29 | <JakeA> | did not know |
| 13:30 | <wanderview> | oh, ok |
| 13:30 | <annevk> | rnd123: probably not, I'd look at the URLs over at http://schema.org/docs/about.html |
| 13:30 | <wanderview> | JakeA: ok, I should feel bad we will be copying then |
| 13:32 | <annevk> | wanderview: do we at least invoke detach on the input buffer? |
| 13:32 | <wanderview> | annevk: I assume so... I would have to check with till |
| 13:32 | <JakeA> | wanderview: this is only with {type: 'bytes'} |
| 13:32 | <wanderview> | annevk: the bit I am talking about is specific to the fetch body stream being consumed by respondWith() or Cache.put() |
| 13:33 | <wanderview> | JakeA: yea, but these native APIs will fail for non-byte streams anyway |
| 13:33 | <annevk> | wanderview: would it not still be observable? I might be missing something though |
| 13:34 | <JakeA> | wanderview: is that per spec? I thought fetch would allow a non-byte stream as long as it returned bytes |
| 13:34 | <wanderview> | annevk: yea, it should detach... but that is handled in the js engine part of streams and not in the DOM integration code I'm looking at |
| 13:34 | <rnd123> | thanks annevk |
| 13:34 | <wanderview> | JakeA: its likely I am confused and you are correct |
| 13:35 | <JakeA> | that's not the way it usually goes |
| 13:35 | <wanderview> | I meant UA consumption requires Uint8Array |
| 13:35 | <JakeA> | wanderview: yeah, but the transfer only happens if it was created like new ReadableStream({ start, pull, type: 'bytes' }) |
| 13:35 | <wanderview> | at this time of day you are better caffeinated than I am... |
| 13:35 | <wanderview> | ok |
| 13:36 | <wanderview> | JakeA: so it would have to be a selective optimization... I wonder if the "type" option was added later... |
| 13:36 | <JakeA> | otherwise I assume it copies |
| 13:37 | <JakeA> | wanderview: Chrome currently throws if you set "type" to "bytes" |
| 13:37 | <JakeA> | Not implemented |
| 13:37 | <wanderview> | oh, I see... its a property on the source... not an option passed to the ReadableStream construcotr |
| 13:37 | <wanderview> | I was getting confused by "type" not being in this line: https://streams.spec.whatwg.org/#rs-constructor |
| 13:38 | <JakeA> | I agree it feels more like an option |
| 13:38 | <JakeA> | but then I guess it also describes the unerlyingSource |
| 13:38 | <wanderview> | I think it fits with the underlying source |
| 13:38 | <wanderview> | "native" sources in theory always have it set |
| 13:39 | <wanderview> | so its exposing that part of their optimizations to js sources |
| 13:40 | <wanderview> | JakeA: we don't throw on type bytes |
| 13:41 | <JakeA> | wanderview: I guess in that case the buffer must appear transferred |
| 13:42 | <wanderview> | JakeA: yea, we try to do it: http://searchfox.org/mozilla-central/source/js/src/builtin/Stream.cpp#801 |
| 13:42 | <wanderview> | maybe there is a test... |
| 13:46 | <wanderview> | JakeA: maybe this tests it? http://searchfox.org/mozilla-central/source/testing/web-platform/tests/streams/readable-byte-streams/general.js#816 |
| 13:47 | <wanderview> | its confusing because it also uses a byob stream |
| 13:48 | <wanderview> | we seem to pass that test, though |
| 13:53 | <wanderview> | JakeA: filed a bug to track this optimization in the future: https://bugzilla.mozilla.org/show_bug.cgi?id=1388050 |
| 13:53 | <JakeA> | cheers! |
| 16:17 | <annevk> | Domenic: thoughts on how to capture https://github.com/w3c/requestidlecallback/issues/61 in the API guidelines? |
| 16:18 | <annevk> | Domenic: make your prose closely resemble an implementation in an imperative programming language and stay away from stack inspection and such? |
| 16:44 | <rbyers> | I've been searching for 5 minutes to try to find the license / copyright notice for HTML (so I can link to it as a GOOD example of a spec that allows forking). Am I just blind? I'm surprised it's so hard to find. |
| 16:45 | <rbyers> | There's one line at the very bottom of the spec (at the end of acknowledgements), is that it? |
| 16:45 | <rbyers> | For some reason I thought html was CC0? |
| 16:45 | <rbyers> | annevk/foolip: ^ |
| 16:46 | <jgraham> | rbyers: HTML isn't for historical reasons iiuc |
| 16:46 | <annevk> | rbyers: HTML is complicated |
| 16:46 | <jgraham> | rbyers: DOM is though |
| 16:46 | <rbyers> | Ah, figures. I'll use DOM as a better example. Thanks :-) |
| 16:46 | <annevk> | rbyers: everything else under WHATWG would be a good example |
| 17:42 | <TabAtkins> | annevk: Sorry about the failure on DOM - I spotted the issue on Friday and fixed it, but it looks like I didn't push my code. :( Fixing it again now on my desktop, but I have a quick question. |
| 17:43 | <TabAtkins> | Any opinion on using unicode characters for doing the deduping? I'm trying to make it much less likely that things will collide with intended URLs; in particular, that some of the multiple refs for a "foo" term collide with the refs for a "foo-0" term. |
| 17:44 | <TabAtkins> | I'm thinking about appending circled-digits for the dedup process. |
| 18:57 | <Mek> | hmm, should windows opened by clients.openWindow be considered script-created (and thus be able to close themselves) or not? |
| 18:58 | <Mek> | From a quick test it seems neither chrome nor firefox considers them script created currently (although chrome allows self.close() if no navigation occured after opening, while firefox doesn't seem to allow self.close() even in that case) |
| 21:12 | <wanderview> | JakeA: would you expect to get DOMContentLoaded much sooner with your blog when streams+sw are enabled? |
| 21:14 | <JakeA> | wanderview: maybe due to the script and styles being cached. But in terms of html delivery it shouldn't be that much faster |
| 21:14 | <wanderview> | JakeA: with streams enabled I see DOMContentLoaded dropping from ~150ms to ~35ms... |
| 21:17 | <JakeA> | wanderview: that's really cool… but I can't explain how streams cause that. If the CSS and JS is removed from the cache, is it still as fast? |
| 21:18 | <wanderview> | JakeA: yea, I more suspect something is broken... but let me check... (I'm really annoyed our network monitor pretends things coming from cache/SW are zero time) |
| 21:19 | <wanderview> | JakeA: hmm... deleting the css and js files made DOMContentLoaded go up to 320ms... so maybe this is legit |
| 21:20 | <wanderview> | JakeA: chrome on my machine gives DOMContentLoaded ~30ms as well... but I don't know how to test without streams there |
| 21:21 | <wanderview> | JakeA: looks like most of the added time was the "include" call |
| 21:23 | <wanderview> | anyway, I guess the good news is it works |
| 21:32 | <JakeA> | \o/ is this in nightly? |
| 21:33 | <wanderview> | JakeA: not in nightly yet... a preliminary build |
| 21:34 | <Mek> | JakeA/wanderview: either of you have opinions on wether clients.openWindow opened windows should be considered "created by script", and thus be able to self.close() themselves? |
| 21:34 | <wanderview> | JakeA: also there is probably a bug somewhere... the image on your blog and the bg image on surma's site did not load a couple times |
| 21:34 | <wanderview> | but it was pretty intermittent |
| 21:35 | <wanderview> | Mek: I wasn't aware of that restriction or feature... so don't really have an opinion... at first glance it seems "created by script", though |
| 21:35 | <wanderview> | I have to run to dinner... |
| 21:35 | wanderview | waves |
| 21:36 | <Mek> | wanderview: okay, thanks |
| 21:38 | <Mek> | actually, the browsing context wouldn't be an auxiliary browsing context so the html "script-closable" defintion wouldn't care if it was created by script or not... |
| 23:06 | <domfarolino> | annevk: just a heads up will be about a week before I can revisit https://github.com/whatwg/html/issues/2886 |