| 07:27 | <annevk> | littledan: I'm not entirely following https://github.com/whatwg/html/pull/4352#issuecomment-496498523 |
| 07:27 | <annevk> | littledan: as I see it service workers relies on some functionality in HTML today |
| 07:28 | <annevk> | littledan: if you change that functionality as per the PR, service workers either ends up broken or we change things for them they are not comfortable with |
| 07:28 | <annevk> | littledan: is that an incorrect understanding of the situation? |
| 07:28 | <littledan> | Annevk, it seems like they are uncomfortable with the feature overall |
| 07:28 | <annevk> | littledan: sure |
| 07:29 | <littledan> | Yes, I agree this can't land without the plumbing change on their side. I will write that change after this TC39 meeting if it gets to Stage 3 |
| 07:29 | <annevk> | littledan: but either way, given that they directly plug into an HTML algorithm, it seems we need to take their needs into account somehow |
| 07:29 | <annevk> | littledan: that is, we care quite strongly about preserving downstream "invariants" |
| 07:29 | <littledan> | Yes, so, right now, the JS spec doesn't cleanly expose whether you encountered a TLA. The API is Promise-based. And now SW is asking to stick with a sync API |
| 07:30 | <littledan> | The JS spec API was based on Domenic's suggestion that I mentioned upthread, and I agree with the advice |
| 07:30 | <littledan> | So, I am not sure where to go from here |
| 07:31 | <littledan> | I would prefer to just say, "too bad SW, you have TLA anyway" but I don't know enough about that world to do so |
| 07:31 | <annevk> | This reminds of me of audio worklets rather not having all kinds of new JS APIs either |
| 07:31 | <littledan> | Hmm good analogy |
| 07:32 | <annevk> | I suspect they wouldn't want some of this either necessarily |
| 07:32 | <annevk> | Audio worklets probably only wants some flavor of wasm, really |
| 07:33 | <littledan> | Maybe they want to disable the Wasm instruction for Atomics.wait as well! |
| 07:33 | <annevk> | I'm surprised this doesn't come up from those embedding JS into microcontrollers and such |
| 07:33 | <littledan> | Or the instruction to grow memory |
| 07:34 | <annevk> | I hope Wasm's Atomics.wait pays attention to the Agent record, though of course none of that is properly layered |
| 07:34 | <littledan> | Well, we can go to TC53 and ask them, I suppose. We can start with rwaldron and Moddable at TC39. I don't know that world well. |
| 07:35 | <annevk> | It seems weird that browsers would be the first to raise the concern of the minimal JavaScript runtime being too big or having features that are incompatible with certain code architectures |
| 07:42 | <littledan> | Well, when embedded people come to TC39 historically, they used to ask for even more minimalism than this, leaving out some language features for simplicity and size. I think neither TC39 nor web standards are sympathetic to the idea of creating embedded profiles. There are lots of partial implementations of the web platform that just aren't seen as that interesting for standards (and I can't think of a better way to handle |
| 07:42 | <littledan> | it). |
| 07:46 | <annevk> | littledan: I see, yeah, profiles end up failing (see all the (X)HTML profiles back in the day). Hmm... |
| 07:46 | <littledan> | Step 6 of Atomics.wait checks the https://tc39.github.io/ecma262/#sec-atomics.wait , reading [[CanBlock]] from the "agent record", whereas HTML sets [[CanBlock]] in the "agent". It almost matches! https://html.spec.whatwg.org/#integration-with-the-javascript-agent-formalism |
| 07:48 | <littledan> | So it makes sense that restricted profiles start from the browser end, where it's about giving the capability to do work for the first time and getting interop there, rather than server or embedded use cases, where the motivation for using standards is more like compatibility with the web (which doesn't have the restrictions) |
| 07:48 | <annevk> | littledan: yeah, I guess I'll wait until agents are refactored to also account for Wasm |
| 07:48 | <littledan> | Anyway now that we got here maybe we should go back and ask them what they need |
| 07:48 | <annevk> | littledan: it's also not really clear to me the agent <> agent record <> agent signifier separation is worth it |
| 07:49 | <littledan> | Yeah I don't understand either. I will talk with Shu to understand better |
| 07:49 | <annevk> | Shu's reasoning seemed to be that you can only pass integers between agents or some such, but then if that were true it would mean that the whole structured serializing and deserializing specification is broken |
| 07:50 | <annevk> | So it seems better to accept the fact that there's need for sharing records across agents and at that point you might as well reconcile them all and make agent a record |
| 07:51 | <littledan> | Well, this is my intuition as well. I am not sure where the requirements on notation come from. I don't think we should adopt this notation in structured serialization. |
| 07:51 | <TimothyGu> | in general ES seems to like having some actual thing and something Record |
| 07:52 | <TimothyGu> | like the properties of a realm are captured in a Realm Record, but a Realm Record isn't really a realm, which is an abstract thing |
| 07:53 | <littledan> | TimothyGu: What do you make of the agent signifier? |
| 07:54 | <TimothyGu> | littledan: I feel like that's an unfortunate consequence of the fact that ES has this distinction between the thing and the Record |
| 07:54 | <TimothyGu> | I also don't think this impacts Structured Serialization/Deserialization in anyway |
| 07:55 | <TimothyGu> | because for that, the records are the only thing being transferred – there's no underlying entity like a realm or an agent |
| 07:56 | <annevk> | Interesting observation, maybe the problem is the abstract thing indeed |
| 08:28 | <littledan> | oh yeah, I guess this is based on the idea that only objects have internal slots, whereas records have fields, and other things don't use this notation (though I guess we softened on this for Symbol's [[Description]]?). The . notation was initially pretty restricted, and then later generalized |
| 08:58 | <gsnedders> | annevk: is it intended that given s' = URL serializer(URL parser(s)), s' will parse without validation errors? (I note for example most but not all non-URL code points are percent encoded in the query state.) |
| 09:34 | <annevk> | gsnedders: I don't think so |
| 09:35 | <annevk> | gsnedders: e.g., https://example.com/% should not change afaik |
| 10:43 | <gsnedders> | https://wiki.whatwg.org/wiki/DOM_XPath — should we create some spec for this somewhere? |
| 10:43 | <gsnedders> | or put it in a PR for DOM, that will probably hang around for ages because nobody will actually work on it? :/ |
| 10:44 | <gsnedders> | But it seems kinda bad having the actual IDL people are implementing only on the wiki |
| 11:10 | <annevk> | gsnedders: DOM is the place and someone doing the work is the problem |
| 11:11 | <annevk> | gsnedders: a good next step might be to write up an issue with the TODO list for this |
| 11:12 | <gsnedders> | hah, https://github.com/whatwg/dom/issues/67 |
| 11:12 | <gsnedders> | that's… a while ago |
| 11:14 | <annevk> | meh, "16:24, 12 September 2011 Annevk (talk | contribs | block) . . (538 bytes) (+538) . . (notes for a future XPath spec)" |
| 11:15 | <annevk> | And even that doesn't seem that long ago 😛 |
| 11:39 | <gsnedders> | It's super annoying having WebIDL that's not covered by any of the auto-extraction tools though. Dunno. :/ |
| 12:08 | <annevk> | gsnedders: I could see making a policy exception if we also add the appropriate XXX block |
| 12:08 | <annevk> | gsnedders: in particular as having the IDL shared and in WPT is better than not having that indeed |
| 12:08 | <annevk> | gsnedders: would you be willing to drive that? |
| 12:17 | <gsnedders> | Yeah, it seems a bit different given it's one of the few interfaces we have that isn't actually in a spec yet is implemented everywhere. |
| 12:17 | <gsnedders> | annevk: bit marginal as to whether it's in scope for what I'm paid to do, though :/ |
| 12:19 | <annevk> | maybe foolip can take it on |
| 12:20 | <foolip> | annevk: is it xpath IDL you'd like to have tested? |
| 12:20 | <gsnedders> | foolip: we have them tested, but having them somewhere where they're found by automatic tools would be good |
| 12:21 | <foolip> | gsnedders: interfaces/xpath.idl doesn't exist though |
| 12:21 | <annevk> | foolip: the idea is to take the DOM XPath wiki page and put it in the DOM Standard with a policy exception for detailed processing model and testing due to it already existing and have a XXX block explaining that situation |
| 12:21 | <annevk> | foolip: this would a) make it clearer DOM XPath is in fact a (problematic) part of the platform and b) help with getting some test coverage in WPT |
| 12:21 | <foolip> | annevk: putting it in a spec would be good, then it'd be picked up by reffy-reports as wel |
| 12:21 | <annevk> | right |
| 12:22 | <annevk> | foolip: and I was volunteering gsnedders / you to do it 😊 |
| 12:22 | <foolip> | annevk: aha :) alright, I'll spend 15 minutes and see what happens |
| 12:26 | <gsnedders> | foolip: yeah, getting it picked up by reffy-reports is basically the motivating factor, because then we keep the "spec" and WPT in sync, and tools that compare impls' IDL to the spec also get it |
| 12:26 | <gsnedders> | foolip: given I don't think anything is going to start crawling the current "spec" we have of WebXPath :) |
| 12:27 | <foolip> | gsnedders: no, I don't think setting that up would be time well spent :) |
| 13:14 | <foolip> | annevk: https://github.com/whatwg/dom/pull/763 |
| 13:15 | <foolip> | Seems like I spent 52 minutes :) |
| 13:24 | <annevk> | foolip: thanks, it might take a while before I get to this, hope that's not a problem |
| 13:25 | <foolip> | annevk: I can't imagine much bad stuff happening because of XPath maintenance falling behind a bit :D |
| 13:45 | <gsnedders> | foolip: https://github.com/web-platform-tests/wpt/pull/17060 is what prompted this, FWIW; you up for reviewing interface/dedicated-worker.idl? |
| 14:30 | <innovati> | It this new Memorandum of Understanding big news? |
| 14:33 | <innovati> | if I understand this correctly, this means the W3C-published text will now be the WHATWG text verbatim? |
| 14:38 | <dtapuska> | annevk: Any thoughts on my latest changes: https://github.com/whatwg/html/pull/4664 were you waiting on @Domenic? |
| 14:46 | <Domenic> | innovati: no, there will be no W3C-published text, just 302 redirects to whatwg.org |
| 14:47 | <innovati> | 🥰 that's the most beautiful thing I've ever heard |
| 14:47 | <innovati> | congrats on making progress! |
| 16:01 | <foolip> | gsnedders: done |
| 16:55 | <annevk> | dtapuska: I didn't get to it today and won't until Monday at the earliest |
| 16:55 | <annevk> | dtapuska: if Domenic could do a pass that'd be good and maybe Domenic remembers the other person from Chrome looking at navigation, they might have good insights as well |
| 17:28 | <Domenic> | I can give a try, still kind of drowning in post long weekend + being sick backlog |