| 01:28 | <MikeSmith> | TabAtkins: you around? |
| 07:48 | <tobie> | So W3C needs to fix this shortname-level trend. Look at https://www.w3.org/TR/service-workers/ and https://www.w3.org/TR/service-workers-1/. This is completely broken. |
| 07:49 | <tobie> | Not to mention level-1 points to a dedicated ED and not the real ED which only the old /service-workers/ WD points to. |
| 08:01 | <annevk> | TabAtkins: happy b-day! |
| 08:09 | <tobie> | TabAtkins: oh wow, happy birthday! |
| 10:26 | <annevk> | JakeA: Domenic: any updates on canceling fetch()? |
| 10:26 | <annevk> | JakeA: Domenic: marcosc told me that the payments API might need something similar, but I guess it's already too late there and they'll have something ugly instead |
| 10:40 | <JakeA> | annevk: cancelable promises are still making their way through tc39. If that takes too long we can do some rewiring and make request.error() a thing (which rejects the promise) |
| 10:40 | <JakeA> | Although that won't work for .json() etc |
| 10:41 | <annevk> | JakeA: you suggested that before and I countered with the fact that request is cloned once passed to fetch() |
| 10:41 | <annevk> | JakeA: radio silence after that on that issue (which was closed before that) |
| 10:42 | <JakeA> | annevk: yeah, the clone would have to be linked to the original for error() to work |
| 10:42 | <annevk> | JakeA: and yeah, I still have the concern that even with a cancel token, we might want to have something higher-level too to cancel both |
| 10:43 | <annevk> | JakeA: so whenever you do new Request(request) we now need to set up linking and maintain some kind of relationship? |
| 10:43 | <JakeA> | annevk: if we wanted cancel() to work, yeah |
| 10:43 | <annevk> | JakeA: for previously static objects that seems like a major surge in complexity |
| 10:44 | <JakeA> | We'd have to do the same with the tokens right? |
| 10:44 | <annevk> | Maybe surge is not the right word |
| 10:44 | <JakeA> | For tokens to work the copy would have to take the token |
| 10:44 | <annevk> | JakeA: the token could be copied, just like all kinds of stuff is copied today |
| 10:44 | <annevk> | JakeA: no need to maintain a link |
| 10:45 | <JakeA> | annevk: we could make error() work the same way |
| 10:45 | <JakeA> | Use a token under the hood |
| 10:46 | <annevk> | JakeA: that'd be like using json() on the old request object having an effect on the new one |
| 10:47 | <JakeA> | Hm |
| 10:47 | <annevk> | JakeA: I don't think we should go with that kind of design unless we really embrace requests is more of an ongoing thing and maybe figure out if we can change the way fetch() works |
| 10:47 | <JakeA> | annevk: if the blocker is cancelable promises, we could look at getting token support in earlier |
| 10:48 | <JakeA> | But it could be an error token rather than a cancel token |
| 10:48 | <JakeA> | :/ |
| 11:21 | <nox> | annevk: Why is </> special in XML 5? |
| 11:22 | <annevk> | nox: tribute to Hixie |
| 11:23 | <nox> | annevk: I was trying to unify html5ever and xml5ever and this is the only thing I can't work around I think. |
| 11:23 | <annevk> | nox: also, it's XML5 sans space |
| 11:23 | <nox> | Ok. |
| 11:23 | <annevk> | nox: really? Huh |
| 11:23 | <nox> | I can work around the absence or processing instructions in the former, but the short end tag in the latter makes my unification quite impossible. |
| 11:23 | <nox> | annevk: It changes the type that represents tokens. |
| 11:24 | <annevk> | nox: can't you just re-interpret the </> token in html5ever? |
| 11:24 | <nox> | What do you mean? |
| 11:24 | <annevk> | nox: do whatever HTML says to do for it |
| 11:24 | <annevk> | Aside: is it meant to be read as "fever"? |
| 11:25 | nox | goes back to the HTML spec and squints trying to find where it is. |
| 11:25 | <nox> | annevk: Maybe, the pun is mostly about html4ever-but-for-html5. |
| 11:25 | <annevk> | nox: there's an html4ever? |
| 11:25 | <nox> | annevk: No but that's something you can say, and it fits the previous version of HTML. |
| 11:25 | <annevk> | nox: I see |
| 11:26 | <annevk> | I'm still a little sad we didn't have the foresight with html5lib to leave versioning out of the name |
| 11:26 | <nox> | annevk: https://html.spec.whatwg.org/multipage/syntax.html#end-tag-open-state "Anything else" Yeah I guess I could do that. |
| 11:27 | <nox> | annevk: So in HTML syntax, </> == <!--/-->? |
| 11:27 | <annevk> | nox: to be clear, it's not just Hixie, it also happens to be quite useful |
| 11:27 | <nox> | How? |
| 11:27 | <annevk> | nox: hmm, are you making me read the parser spec? |
| 11:28 | <annevk> | nox: since you don't have to write out the closing tag |
| 11:28 | <nox> | annevk: Ah ah, nah, I'm confident in my reading don't force yourself. |
| 11:28 | <nox> | annevk: It behaves completely different than HTML, |
| 11:28 | <nox> | and it isn't needed for webcompat, |
| 11:28 | <nox> | so I would say it was a bad thing. |
| 11:28 | <annevk> | nox: afaict it's <!----> without the / |
| 11:29 | <nox> | annevk: "Parse error. Create a comment token whose data is the empty string. Reconsume in the bogus comment state." |
| 11:29 | <nox> | And in bogus comment state: "Anything else: Append the current input character to the comment token's data." |
| 11:29 | <annevk> | nox: actually, I think it's just ignored |
| 11:29 | <annevk> | nox: </ brings you into end tag open state |
| 11:30 | <nox> | Oh right, silly me. |
| 11:30 | <annevk> | nox: > brings you back to data state with the token ignored |
| 11:30 | <annevk> | nox: so it should be very easy to support in both |
| 11:30 | <nox> | So anyway, I'm not sure XML5 should include novelty convenience stuff that behaves quite differently from HTML5. |
| 11:30 | <annevk> | nox: in HTML you ignore, in XML you pop |
| 11:31 | <annevk> | If we're going to do XML5 at all, why would we not add something nice |
| 11:31 | <nox> | annevk: But more than Hixie tribute, it's also a syntax in E4X no? |
| 11:31 | <annevk> | I don't think E4X has </> |
| 11:31 | <annevk> | SGML might |
| 11:32 | <annevk> | There's no HTML parity anyway |
| 11:32 | <annevk> | By default you don't get namespaces, you can create arbitrary trees, etc. |
| 11:32 | <nox> | annevk: I wanted to check... |
| 11:32 | <nox> | annevk: http://www.ecma-international.org/publications/standards/Ecma-357.htm |
| 11:32 | <nox> | click on the PDF link. |
| 11:33 | nox | facepalms. |
| 11:34 | <annevk> | nox: heh, www.ecma-international.org/publications/files/ECMA-ST/ECMA-357.pdf even redirects it seems |
| 11:34 | <nox> | Ah ah ah. |
| 12:02 | <annevk> | JakeA: :focusring vs :focus:not(:active) gives? |
| 12:05 | <JakeA> | annevk: I don't think active happens on buttons, or it happens but even after activation via keyboard |
| 12:06 | <JakeA> | It's definitely something I've struggled with in the past, and usually end up calling blur() after clicks, which isn't great |
| 12:07 | <annevk> | I see |
| 15:04 | <Domenic> | nox: per http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4670 it seems like the </> gets totally eaten, not turned into a comment |
| 15:04 | <nox> | Domenic: Yeah I figured that out afterwards, |
| 15:04 | <nox> | was misreading the spec, |
| 15:04 | <nox> | AS USUAL |
| 15:05 | <Domenic> | i see, that's what i get for typing as i read the backscroll |
| 15:05 | <nox> | Domenic: Can't blame you for replying me, hah, thanks anyway. :) |
| 17:18 | <ondras> | quick question - ImageData.data is Transferrable, e.g. can i efficiently move it to a web worker? |
| 17:20 | <annevk> | ondras: what is the question? |
| 17:32 | <annevk> | mkwst: https://infra.spec.whatwg.org/ |
| 17:43 | <ondras> | annevk: can I transfer canvas ImageData to a Worker without copying? |
| 17:45 | <nox> | annevk: You should have named it utils or misc, come on. :P |
| 17:46 | <annevk> | ondras: sure, just pass imageData.data.buffer to the transfer map |
| 17:47 | <annevk> | nox: I'm hoping this is not going to be a thing where everyone has opinions about the name... |
| 17:48 | <nox> | annevk: Sorry, kidding, I like the name you chose. :P |
| 17:48 | <nox> | annevk: I hate the utils module in Servo with a passion. |
| 17:55 | <ondras> | annevk: thanks! |
| 18:13 | <Krinkle> | I'm trying to understand how browsers work (or are supposed to) with regards to event handling and the event loop. For example, is it true that attaching an event handler earlier in the same function will make any difference (however small and unlikely?). E.g. document.addEventListener('visibilitychange', ..) as first line or last line of a long function. |
| 18:13 | <Krinkle> | I always thought that events would be queued after the current execution so it will get triggered either way |
| 18:13 | <Krinkle> | but then I realised that maybe browsers disregard events if there are no listeners bound |
| 18:14 | <Krinkle> | annevk: Do you know if the spec prescribes anything on this point? Or is it up to user agents to decide? |
| 18:38 | <annevk> | Krinkle: most events get queued but not all |
| 18:39 | <annevk> | Krinkle: depends on whether they dispatch from a new task |
| 18:39 | <annevk> | Krinkle: for your sample event it should not matter |
| 18:40 | <Krinkle> | I'm curious in general, but for this particular example it's about whether or not it is possible to miss information if you do: if (document.hidden){ yup(); } and then doc.addEventListener(visibilitychange, yup); or that in theory hidden can happen in between but not dispatched |
| 18:40 | <Krinkle> | annevk: Interesting. |
| 18:40 | <Krinkle> | annevk: So the spec says whether or not to dispatch from a task? Or is that implementation detail? |
| 18:41 | <annevk> | Krinkle: specs need to |
| 18:41 | <Krinkle> | I assume you mean that some events queue event handlers directly as individual tasks, and others queue a task to do the dispatching? |
| 18:41 | <annevk> | Krinkle: some operations dispatch directly |
| 18:42 | <Krinkle> | annevk: Ah you mean synchronously |
| 18:42 | <annevk> | Krinkle: others queue a task to dispatch |
| 18:42 | <Krinkle> | Right |
| 18:42 | <annevk> | Krinkle: indeed |
| 18:42 | <Krinkle> | So if it's queued , then it will always defer the entire thing, which means new handlers will be seen still. |
| 18:42 | <Krinkle> | annevk: Thanks :) |
| 18:43 | <Krinkle> | annevk: I imagine there may be some exceptions with regards to optimizing for there not being any handlers, but maybe that optimization is also deferred. I'm thinking about scroll events and such perf hurdles for mobile. |
| 18:43 | <annevk> | Krinkle: oh yes |
| 18:43 | <Krinkle> | I imagine it would be able to natively see if there are handlers without requiring JS execution to be interupted. |
| 18:44 | <annevk> | Krinkle: impls optimize alll kinds of things |
| 18:44 | <Krinkle> | which would allow for races. |
| 19:45 | <wanderview> | JakeA: ping |
| 19:46 | <wanderview> | have you survived Chrome Dev Summit? |
| 19:51 | <wanderview> | hmm... nm |
| 19:51 | <JakeA> | wanderview: back in the office tomorrow! |
| 19:51 | <wanderview> | ah, ok |
| 19:52 | <wanderview> | thanks |
| 19:52 | <gsnedders> | speaking of which, I'm in London from, uh, 40 minutes from now |
| 19:52 | <gsnedders> | s/40/30/ |
| 19:53 | <jgraham> | s/30/29/ |
| 19:54 | <gsnedders> | well, we're running late, but there's enough pathing allowances that we could make up some of it |
| 19:54 | <gsnedders> | so I dunno when we'll get in |