freenode :: #whatwg

7 Aug 2017
00:12TimothyGuHey all * seems to be down, is this a known issue?
00:12TimothyGucurl: (7) Failed to connect to port 443: Connection refused
01:22GPHemsleyTimothyGu: I'm going to say yes, assuming it's the same issue as
01:22GPHemsley(though the symptoms are different)
01:22TimothyGuhmm was down for me yesterday, while starts not working today
01:24GPHemsleywell then... MikeSmith?
02:08MikeSmithif is down its my fault, if is down its Hixies fault
02:08MikeSmithoh both are down
02:09MikeSmithI pinged Hixie about
02:09MikeSmithdid not hear back from him yet
02:11MikeSmithah about we changed the commands for starting it
02:11MikeSmith*the commands for starting wptserve
02:11MikeSmithso I need to update my init script
06:32MikeSmithGPHemsley: I run, Hixie runs
07:05MikeSmithDomenic: ah OK I see now is down?
09:45annevkMs2ger: yeah known
09:45Ms2gerI'd look at the logs, but they're down too
09:46annevkI don't think it was reported here yet, but I might have missed something
10:33Ms2gerIf a video stops because it reaches the end of the video, does it also get a 'pause' event?
10:57annevkWow, even Live DOM Viewer is down
10:57annevkIt's serious now
12:14DomenicEverything seems back up
12:15annevkWow that just happened then since I pushed something a minute or two ago and it failed
12:46rnd123hello, 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:24wanderviewDomenic: 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:24wanderviewI guess maybe the UA could do some kind of copy-on-write sort of thing
13:24JakeAwanderview: I think Domenic was thinking of a special stream type or option to enable transferring
13:25wanderviewthere is byob streams... but I think this is different, maybe?
13:25JakeAYeah they're different
13:25wanderviewJakeA: 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:25JakeAI think it's complicated if you have an object stream and you want to specify which parts are transferrable
13:26JakeAwanderview: It'd be great if it was supported if all parts of the stream were behind the scenes
13:27wanderviewJakeA: we definitely support it for native sourced streams
13:27JakeAeg, piping three items of the cache to a single transform stream that doesn't have a chunk handler
13:27wanderviewor will
13:28wanderviewI guess we would not support the appending without copying, though
13:28JakeAwanderview: I may be wrong
13:28wanderviewJakeA: 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:29JakeAoh, that link wasn't charable
13:29JakeAlooks like transferring happens by default with bytestreams
13:29JakeAdid not know
13:30wanderviewoh, ok
13:30annevkrnd123: probably not, I'd look at the URLs over at
13:30wanderviewJakeA: ok, I should feel bad we will be copying then
13:32annevkwanderview: do we at least invoke detach on the input buffer?
13:32wanderviewannevk: I assume so... I would have to check with till
13:32JakeAwanderview: this is only with {type: 'bytes'}
13:32wanderviewannevk: the bit I am talking about is specific to the fetch body stream being consumed by respondWith() or Cache.put()
13:33wanderviewJakeA: yea, but these native APIs will fail for non-byte streams anyway
13:33annevkwanderview: would it not still be observable? I might be missing something though
13:34JakeAwanderview: is that per spec? I thought fetch would allow a non-byte stream as long as it returned bytes
13:34wanderviewannevk: 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:34rnd123thanks annevk
13:34wanderviewJakeA: its likely I am confused and you are correct
13:35JakeAthat's not the way it usually goes
13:35wanderviewI meant UA consumption requires Uint8Array
13:35JakeAwanderview: yeah, but the transfer only happens if it was created like new ReadableStream({ start, pull, type: 'bytes' })
13:35wanderviewat this time of day you are better caffeinated than I am...
13:36wanderviewJakeA: so it would have to be a selective optimization... I wonder if the "type" option was added later...
13:36JakeAotherwise I assume it copies
13:37JakeAwanderview: Chrome currently throws if you set "type" to "bytes"
13:37JakeANot implemented
13:37wanderviewoh, I see... its a property on the source... not an option passed to the ReadableStream construcotr
13:37wanderviewI was getting confused by "type" not being in this line:
13:38JakeAI agree it feels more like an option
13:38JakeAbut then I guess it also describes the unerlyingSource
13:38wanderviewI think it fits with the underlying source
13:38wanderview"native" sources in theory always have it set
13:39wanderviewso its exposing that part of their optimizations to js sources
13:40wanderviewJakeA: we don't throw on type bytes
13:41JakeAwanderview: I guess in that case the buffer must appear transferred
13:42wanderviewJakeA: yea, we try to do it:
13:42wanderviewmaybe there is a test...
13:46wanderviewJakeA: maybe this tests it?
13:47wanderviewits confusing because it also uses a byob stream
13:48wanderviewwe seem to pass that test, though
13:53wanderviewJakeA: filed a bug to track this optimization in the future:
16:17annevkDomenic: thoughts on how to capture in the API guidelines?
16:18annevkDomenic: make your prose closely resemble an implementation in an imperative programming language and stay away from stack inspection and such?
16:44rbyersI'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:45rbyersThere's one line at the very bottom of the spec (at the end of acknowledgements), is that it?
16:45rbyersFor some reason I thought html was CC0?
16:45rbyersannevk/foolip: ^
16:46jgrahamrbyers: HTML isn't for historical reasons iiuc
16:46annevkrbyers: HTML is complicated
16:46jgrahamrbyers: DOM is though
16:46rbyersAh, figures. I'll use DOM as a better example. Thanks :-)
16:46annevkrbyers: everything else under WHATWG would be a good example
17:42TabAtkinsannevk: 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:43TabAtkinsAny 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:44TabAtkinsI'm thinking about appending circled-digits for the dedup process.
18:57Mekhmm, should windows opened by clients.openWindow be considered script-created (and thus be able to close themselves) or not?
18:58MekFrom 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:12wanderviewJakeA: would you expect to get DOMContentLoaded much sooner with your blog when streams+sw are enabled?
21:14JakeAwanderview: maybe due to the script and styles being cached. But in terms of html delivery it shouldn't be that much faster
21:14wanderviewJakeA: with streams enabled I see DOMContentLoaded dropping from ~150ms to ~35ms...
21:17JakeAwanderview: 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:18wanderviewJakeA: 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:19wanderviewJakeA: hmm... deleting the css and js files made DOMContentLoaded go up to 320ms... so maybe this is legit
21:20wanderviewJakeA: chrome on my machine gives DOMContentLoaded ~30ms as well... but I don't know how to test without streams there
21:21wanderviewJakeA: looks like most of the added time was the "include" call
21:23wanderviewanyway, I guess the good news is it works
21:32JakeA\o/ is this in nightly?
21:33wanderviewJakeA: not in nightly yet... a preliminary build
21:34MekJakeA/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:34wanderviewJakeA: 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:34wanderviewbut it was pretty intermittent
21:35wanderviewMek: 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:35wanderviewI have to run to dinner...
21:35* wanderview waves
21:36Mekwanderview: okay, thanks
21:38Mekactually, 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:06domfarolinoannevk: just a heads up will be about a week before I can revisit
8 Aug 2017
No messages
Last message: 9 days and 22 hours ago