| 08:16 | <philipj> | annevk, Domenic, about CDATASection, that's a removal I think *could* work out, but it wouldn't be completely purged because https://www.chromestatus.com/metrics/feature/timeline/popularity/113 so I'm a bit on the fence |
| 08:18 | <philipj> | Domenic is right that it'd break some serialization tests, but that's not really the problem, the problem would be to get everyone to care enough to actually make this change. Less valuable than Attr simplification I think. |
| 08:19 | <philipj> | annevk: I'll add the ? to insertAdjacentElement's return type in Blink. Note that this doesn't actually change any behavior, the nullability of return types doesn't change the generated code. (so if things that shouldn't return null do, there's no assert there) |
| 08:21 | <annevk> | philipj: I figured that was what was going on |
| 08:21 | <annevk> | philipj: Gecko uses the return values to inform the JIT aiui |
| 08:22 | <annevk> | return types* |
| 08:22 | <philipj> | hmm, so if something that shouldn't return null does, it would crash, most likely? |
| 08:26 | <annevk> | philipj: I guess that would be problematic, I don't know the specifics |
| 08:26 | <annevk> | philipj: WebAssembly folks also have some ideas around type-informed optimizations |
| 08:27 | <philipj> | oh well, I hope that when the return types are all per spec in Blink, one might add asserts to find some lies |
| 08:27 | <annevk> | philipj: basically skipping a whole lot of the checks IDL does to guarantee you have objects of the proper brand |
| 08:27 | <annevk> | Should speed up things a little too if that works out |
| 08:28 | <annevk> | JakeA: you know you're feeding a troll, right? |
| 08:30 | <JakeA> | annevk: yeahhhh. I want going to reply, but I saw his post getting shared on Twitter so figured I'd see how far a reasonable response would get |
| 08:30 | <JakeA> | But you're right it's not helping |
| 08:32 | <annevk> | Been a while since I saw someone using all caps words (apart from constants) |
| 08:37 | <annevk> | https://w3c.github.io/DOM-Parsing/ hasn't been maintained since June 2014, ugh |
| 08:50 | <tobie> | TabAtkins: are the enum values documented anywhere? |
| 09:18 | <tobie> | In one of the algorithm steps in the sensor spec, I need to iterate over a set of sensor instances to resolve promises and fire events. |
| 09:18 | <tobie> | In the polyfill, I clone the set before doing so, to avoid unwanted side effects if one of the handler actually removes a sensor from the set. |
| 09:18 | <tobie> | Is there spec language to describe this? |
| 09:20 | <tobie> | For ref, here are the polyfill lines: https://github.com/w3c/sensors/blob/cfc3932/polyfills/geolocation.js#L124-L126 |
| 09:37 | <annevk> | zcorpan: do you happen to know if we have a test for https://github.com/whatwg/html/issues/842? |
| 09:43 | <zcorpan> | annevk: ./Secure-Close-1005-verify-code.htm: assert_equals(evt.code, 1005, "CloseEvent.code should be 1005"); |
| 09:45 | <zcorpan> | though wss: might not work, on w3c-test.org at least |
| 09:46 | <annevk> | zcorpan: that tests what the server transmitted, not what the client transmitted |
| 09:46 | <zcorpan> | annevk: the server echos the client's code |
| 09:46 | <zcorpan> | or that seems to be the intent |
| 09:46 | <annevk> | zcorpan: so by default the client transmits 1005, a code developers cannot set? |
| 09:47 | <zcorpan> | i don't know what browsers do or if this test is correct per spec |
| 09:47 | <zcorpan> | i think this test was written by MS |
| 09:47 | <zcorpan> | the tests i wrote predated close codes |
| 09:48 | <annevk> | Hmm, they don't seem great |
| 09:50 | <annevk> | Okay, so WSP has internal contradictions |
| 09:51 | <zcorpan> | "If this Close control frame contains no status code, _The WebSocket Connection Close Code_ is considered to be 1005." -- though this doesn't mean that close() should send 1005 |
| 09:52 | <zcorpan> | in fact 1005 must not be sent explicitly |
| 09:52 | <annevk> | close() invokes https://tools.ietf.org/html/rfc6455#section-7.1.2 which requires a /code/ |
| 09:52 | <zcorpan> | right |
| 09:52 | <annevk> | Though it seems you can transmit an empty Close frame (without body) too |
| 09:52 | <zcorpan> | it seems to me close() should be equivalent to close(1000) |
| 09:53 | <annevk> | Maybe clients do that? |
| 09:53 | <annevk> | And just ignore that the protocol requires /code/ not to be optional (since it describes elsewhere that it is) |
| 09:56 | <annevk> | zcorpan: emailed hybi |
| 09:56 | <annevk> | zcorpan: copied you and tyoshino |
| 10:04 | <annevk> | Why does The WebSocket Protocol use both "Close message" and "Close frame"? |
| 10:10 | <zcorpan> | no idea. i assume they mean the same thing (and Close frame is the correct one) |
| 10:11 | <annevk> | zcorpan: hmm, the spec says that messages consist of one or more frames |
| 10:11 | <annevk> | zcorpan: but I'm not sure if it actually uses that terminology consistently |
| 10:12 | <zcorpan> | http://w3c-test.org/websockets/closing-handshake/003.html is a simple test for close(), i'll inspect it with packetpeeper |
| 10:13 | <zcorpan> | annevk: ah yeah, but iirc you're not allowed to fragment close into multiple frames |
| 10:15 | <zcorpan> | "Control frames themselves MUST NOT be fragmented." |
| 10:26 | <zcorpan> | well... i've found the packet that contains the close frame from the client but i can't make much sense of it, i can't seem to get the payload itself (only in a form where it's converted to text in a lossy way) |
| 10:30 | <zcorpan> | annevk: http://imgur.com/1dS4le4 |
| 10:31 | <zcorpan> | annevk: this is with Nightly with closing-handshake/003.html, the last PSH packet from the client |
| 10:32 | <annevk> | zcorpan: hmm, there's some kind of obfuscation going on, right? |
| 10:35 | <annevk> | zcorpan: not really sure what to make of that either |
| 10:37 | <annevk> | zcorpan: in Chrome I get "e.wasClean expected true but got false" for that test |
| 10:38 | <zcorpan> | annevk: don't think so, the websocket frame header shouldn't be obfuscated i think. it's just that this is the whole TCP packet and i don't know how to parse TCP in my head :-) |
| 10:39 | <annevk> | I wonder why Firefox doesn't have debugging for WebSocket |
| 10:40 | <zcorpan> | chrome's devtools can inspect messages but not close frames last i checked |
| 10:40 | <annevk> | https://addons.mozilla.org/en-US/firefox/addon/websocket-monitor/ |
| 10:41 | <annevk> | zcorpan: with that addon I get disconnected, code 1005 |
| 10:45 | <annevk> | zcorpan: that addon doesn't really log the close reason though, if I provide one, but it does allow me to disconnect with 1000 |
| 11:11 | <zcorpan> | i suppose the TCP payload must be the trailing 6 bytes, thus F1 86 4A |
| 11:13 | <zcorpan> | er |
| 11:14 | <zcorpan> | 88 80 CC F1 86 4A |
| 11:23 | <zcorpan> | and from what i can tell from the WebSocket framing, that means the payload length is 0 and therefore no close code is sent |
| 11:24 | zcorpan | wipes his forehead |
| 11:39 | <zcorpan> | in Chrome the close frame also has no payload (though Chrome fails the test for .wasClean; not sure why, the close handshake looks OK to me) |
| 11:43 | <zcorpan> | WebKit also no payload (and it passes the test) |
| 11:45 | <zcorpan> | .code returns 1005 in webkit and gecko; 1006 in chrome |
| 12:16 | <smaug____> | Ms2ger: since I don't understand github jargon, https://github.com/w3c/web-platform-tests/pull/2665 means the tests are now in wpt? |
| 12:31 | <smaug____> | I guess so |
| 12:31 | <smaug____> | silly me |
| 14:02 | <annevk> | mkwst: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27852 waits for a reply from you |
| 14:14 | <mkwst> | Replied, sorry I missed it. |
| 14:17 | <MikeSmith> | annevk: I removed the HISTORICAL- prefix from a bunch more bugzilla components. So hopefully that will un-break some links. But if later you notice any specific ones I missed, lemme know |
| 14:18 | <mkwst> | annevk: If you want that in Fetch, let's just move the bug to GitHub and I'll try to send you a PR later in the week. If you want in HTML, then maybe I'll let Domenic write a PR because HTML is huge. :) |
| 14:21 | <annevk> | Domenic: what do you think? ^ |
| 14:21 | annevk | doesn't care strongly about the layering, and Fetch already has some MIME type blocking |
| 14:22 | <annevk> | mkwst: Domenic: actually, maybe Fetch is better if we just want to treat image MIME types as a network error |
| 14:23 | <annevk> | mkwst: Domenic: aaah, starting to second guess, HTML has some MIME type checks for <script> too now, with <script type=module> |
| 14:23 | annevk | drops mic |
| 14:23 | <annevk> | MikeSmith: ta |
| 14:24 | <Domenic> | annevk: happy to let Fetch handle that. It seems potentially better there. Based on destination etc. |
| 14:28 | <annevk> | Okay, mkwst, PR Fetch then 😃 |
| 14:33 | <annevk> | TabAtkins: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17632 styling of <li> in terms of CSS, is that possible yet? |
| 15:56 | <TabAtkins> | annevk: start and value, yes. reverse, no. |
| 15:58 | <TabAtkins> | Handling value required the new counter-set property from the Lists spec, which I think Gecko implements. |
| 16:15 | <TabAtkins> | tobie: In the autolinking section of the docs, like all the other linking types. |
| 16:17 | <tobie> | TabAtkins: oh, right, saw it now. |
| 16:24 | <annevk> | TabAtkins: should HTML define some kind of magical value for something in the rendering section? |
| 16:24 | <annevk> | TabAtkins: similar to xxx-large |
| 16:24 | <TabAtkins> | Say that, in the reverse case, implementations must act as if counter-reset were set to XXX value. |
| 16:30 | <annevk> | TabAtkins: I guess that works, though we might still run into trouble with getComputedStyle |
| 16:32 | <annevk> | TabAtkins: anyway, added your suggestion to the bug, thanks |
| 16:41 | <gabr13l> | Hello WHATWG crew! o/ |
| 17:43 | <annevk> | Does anyone know if junov ever hangs out on IRC? |
| 17:43 | <annevk> | There's a bunch of legacy <canvas> bugs they might be interested in |
| 18:31 | <annevk> | TabAtkins: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17770 is another <li> thingie |
| 18:31 | <annevk> | TabAtkins: awaiting attention from you |
| 18:32 | <annevk> | JakeA: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27875 is awaiting an answer from you |
| 18:50 | <Domenic> | Ahhhhh whaaaaat environment settings objects are not 1:1 with Windows whaaaat |
| 19:10 | <mkwst> | TabAtkins: Once you're done doing whatever annevk wants you to do, tell me all about how easy it must be by now to magically publish daily drafts to /TR via Bikeshed and Whatever They've Called Their Tool(tm). :) |
| 19:10 | <mkwst> | (Also, thanks for fixing Bikeshed this morning. :) ) |
| 19:14 | <annevk> | Domenic: 😠|
| 19:14 | <annevk> | Domenic: not looking forward to reading about that tomorrow |
| 19:16 | <Domenic> | annevk: it explains why nothing gets stored on settings objects, and instead they all have algorithms that grab things from places... |
| 19:16 | <Domenic> | Until I messed up and did module map :( |
| 21:13 | <TabAtkins> | annevk: That bug is still pending me updating Lists and getting the WG to sign off on it. |
| 21:13 | <TabAtkins> | Which I plan to do in the next few months, but I've said that for about two years, so who knows whether I"ll actually achieve it. |
| 22:02 | <TabAtkins> | mkwst: It's not easy *quite* yet, but I *think* all the necessary bits are in place, I just need to fiddle with them and make them work. |
| 22:58 | <tobie> | Probably a very noob question, but should you always queue a task to dispatch events or are there legitimate cases where you shouldn't do so? |
| 22:59 | <jgraham> | Certianly not all existing events queue a task |
| 22:59 | <jgraham> | Legitimately it makes sense during navigation and so on, I think |
| 23:03 | <tobie> | mmm |
| 23:03 | <tobie> | While on the topic, I guess there's no simple way to polyfill "queue a task" |
| 23:06 | <jgraham> | Sure there is |
| 23:07 | <jgraham> | Use postMessage |
| 23:09 | <tobie> | jgraham: oh, cool. Thanks |
| 23:27 | <tobie> | jgraham: arg, that's more complicated than I initially expected. Giving seTimeout(fn, 0). Probably sufficient for my needs. |
| 23:31 | <jgraham> | k |
| 23:35 | <tobie> | jgraham: was looking at this: https://github.com/YuzuJS/setImmediate/blob/master/setImmediate.js |