| 08:46 | <JakeA> | Domenic: annevk: happy to look at particular fetch+streams issues during the service worker meeting tomorrow since we're in the same building |
| 08:49 | <annevk> | sg |
| 09:12 | <smaug> | esprehn: ok, the global delayed microtask delivery point would still be consistent, so I can buy that. I assume it would be per global and not per connected-same-origin-global or such |
| 09:14 | <annevk> | mkwst: https://bugzilla.mozilla.org/show_bug.cgi?id=1302539 seems weird? |
| 09:34 | <annevk> | yoav: FWIW https://twitter.com/annevk/status/777800561366274048 |
| 09:34 | <annevk> | FYI, really |
| 09:35 | <yoav> | annevk: Saw it :) |
| 09:35 | <yoav> | not my call, but I think we should just break those pages and make them feel bad about themselves |
| 09:35 | <yoav> | (assuming usage is low enough) |
| 09:38 | <mkwst> | Hi! Yeah, WebKit/Blink never implemented `nosniff` for anything other than script and style. From a security perspective, there didn't seem to be much value to doing so. |
| 09:38 | <mkwst> | If it's hurting interop, it's certainly something we could investigate doing. |
| 09:38 | <mkwst> | Do y'all have any numbers? |
| 09:39 | <Ms2ger> | If only someone wrote a fucking spec when it was implemented |
| 09:40 | <mkwst> | Ms2ger: Eh. It's an artifact from a different era. I think it shipped in IE8 or something. |
| 09:42 | <mkwst> | Like I said, if Chrome's behavior is breaking Firefox, then it's something we should address. But Chrome's behavior hasn't changed in at least ~3 years, so... |
| 09:47 | <annevk> | mkwst: I asked for numbers in the bug |
| 10:19 | <MikeSmith> | annevk: now would be a the right time to visit the Web Payments room |
| 10:19 | <MikeSmith> | same for anybody else here who’s interested in the payments stuff |
| 10:19 | <mkwst> | MikeSmith: What's the topic? |
| 10:20 | <MikeSmith> | mkwst: Rouslan talking about the Chrome implementation of the PaymentRequest API |
| 10:21 | <annevk> | MikeSmith: stuck elsewhere |
| 10:21 | <MikeSmith> | and in general about POV from implementors |
| 10:21 | <MikeSmith> | annevk: ok |
| 10:21 | <esprehn> | smaug: yeah per global, I don't understand the implementation complexity there since our microtask queue is inside v8 though |
| 10:22 | <gsnedders> | we're about to reach testing in the CSS WG, FWIW |
| 10:26 | <smaug> | esprehn: in Gecko microtask handling (used by MutationObserver, not Promises yet) could be quite easily modified to that delivery happens at end of task. I think. Except in case one MutationObserver is used to observe changes from a normal document _and_ changes form a document where delayed delivery is needed |
| 10:26 | <smaug> | hmm, I guess that should be reasonable easy too |
| 10:27 | <smaug> | (need to still sort out microtask handling in the spec too. I think there are couple of bugs and it is unclear to me why there ended up this special microtask thingie for mutation observers.) |
| 10:27 | <esprehn> | okay |
| 10:28 | <esprehn> | I need to think about the complexity of delivering for some documents and not others. I was imagining that the thing doing the calling skips it, so it'd be all contexts that would be invoked there |
| 10:29 | <esprehn> | ex. a child iframe that does parentWindow.requestAnimationFrame or a childWindow.mutationObserver.observe(parentWindow) wouldn't make it behave different |
| 10:29 | <esprehn> | if that's what you're suggesting, but it might be possible :) |
| 10:33 | <smaug> | esprehn: so if the behavior is per global and parent window has delayed mt but child doesn't, and childWindow's MO observes itself and parent, that is the case I'm talking about |
| 10:36 | <smaug> | I still wonder if the issue could be solved in Custom elements level |
| 10:37 | <smaug> | maybe not |
| 10:38 | <smaug> | it could be solved there, that during parsing callbacks are called at the end of the task |
| 12:42 | <Ms2ger> | CSSWG seems to be discussing XSL:FO |
| 12:43 | <Ms2ger> | What year is it? |
| 12:47 | <TabAtkins> | Nah mang it's dead. |
| 12:47 | <TabAtkins> | But still had some useful things that we had plans to import, if someone will actually do the work to dig it out. |
| 14:31 | <jgraham> | Ms2ger: Earlier they were discussing tables. Next up jsss |
| 14:32 | <zcorpan> | spaces gifs were also mentioned |
| 22:22 | <jyasskin> | I have a map from shorts to a particular dictionary type ({data:BufferSource, mask:BufferSource}), to express as an argument to a function. I want to have folks just pass objects, but getting the k/v pairs out is pretty hard to express in WebIDL. My fallback is to express it as an array of {id: short, data: bufferSource, mask: BufferSource}, and I'm leaning |
| 22:22 | <jyasskin> | toward that. Anyone have preferences? |