| 02:23 | <Domenic> | TabAtkins: yes, in theory, but unfortunately annevk's multimaps went with null, and he says it's probably too late to change |
| 02:23 | <TabAtkins> | Null, seriously? When Maps return undefined? |
| 02:23 | <Domenic> | Yes. |
| 02:23 | <Domenic> | Although belay my above |
| 02:24 | <Domenic> | Apparently they return [] |
| 02:24 | <Domenic> | Which seems pretty good now that I think about it |
| 02:24 | <TabAtkins> | Okay. |
| 02:24 | <Domenic> | Less null/undefined-testing |
| 02:24 | <TabAtkins> | Yeah, I could lean either way |
| 02:24 | <TabAtkins> | If you're expecting to get an array of stuff, getting an empty one is usually what you want I think. |
| 02:25 | <TabAtkins> | Better if js had falsey empty arrays, but eh. |
| 02:29 | <TabAtkins> | Domenic: .get() returns undefined tho? |
| 02:29 | <TabAtkins> | If it returns null I'm not matching that. |
| 02:29 | <Domenic> | TabAtkins: that'd be good, to be consistent with JS, although it's not what Headers and URLSearchParams due, very sadly. |
| 02:30 | <Domenic> | Looks like maplike also does undefined for get() |
| 02:30 | <TabAtkins> | I'll just write those off as legacy mistakes, yeah. |
| 08:00 | <tobie> | "Better if js had falsey empty arrays, but eh." O_O |
| 08:15 | <nox> | tobie: Not as good as falsey midnight though! |
| 08:16 | <tobie> | nox: wow. Did not know that was a thing. |
| 08:16 | <nox> | tobie: In Python it is. |
| 08:17 | <tobie> | nox: yeah--googled it. |
| 08:17 | <nox> | tobie: Why did you inflict this upon yourself! |
| 08:17 | <nox> | Some things are better left unknown. |
| 08:18 | <annevk> | JakeA: patches for https://bugzilla.mozilla.org/show_bug.cgi?id=1378342 are coming in atm |
| 08:18 | <annevk> | [insert it's happening gif] |
| 08:21 | <JakeA> | yay!! |
| 10:14 | <annevk> | tobie: I lost your train of thought in https://github.com/heycam/webidl/issues/365 |
| 10:14 | <annevk> | tobie: I'd like that issue to be focused on removing the need for PrimaryGlobal |
| 10:14 | <annevk> | tobie: by adding Exposed= everywhere |
| 10:15 | <annevk> | tobie: and just that as that's a big enough task |
| 10:15 | <tobie> | OK, see, that's the part I was missing. |
| 10:15 | <annevk> | tobie: I don't want to couple it with secure context changes |
| 10:15 | <tobie> | I'm just going to edit the comments to makes things less confusing to others. |
| 10:16 | <annevk> | tobie: and I guess I was wondering if we have enough consensus so that I could start doing some things in that direction |
| 10:16 | <annevk> | ta |
| 10:20 | <tobie> | annevk: we might have had this discussion already, but I'm not sure how making [Exposed] mandatory allows us to remove [PrimaryGlobal]. |
| 10:21 | <annevk> | tobie: PrimaryGlobal is a fallback |
| 10:21 | <annevk> | tobie: if you haven't declared a global, you'll be exposed on PrimaryGlobal |
| 10:21 | <annevk> | tobie: if everything declares a global, there's no need for a fallback |
| 10:21 | <tobie> | annevk: oh. So all PrimaryGlobal -> Global |
| 10:22 | <tobie> | "all" |
| 10:22 | <annevk> | tobie: [PrimaryGlobal] is a marker on the Window object and IDL uses that as marker as a fallback for when an interface lacks Exposed |
| 10:22 | <annevk> | tobie: that this is still causing confusion is even more reason to get rid of it |
| 10:22 | <tobie> | We had this discussion already. |
| 10:22 | <annevk> | yeah |
| 10:23 | <annevk> | But it's easy enough to explain |
| 10:23 | <tobie> | Indeed. |
| 10:27 | <tobie> | annevk: Alright. Updated the issue with the above so I don't ask about it again in n months. |
| 10:28 | <tobie> | annevk: churn wise, it does seem however that inverting [SecureContext] at the same time would make sense. |
| 10:35 | <tobie> | annevk: wrt your initial question, who should we gather consensus from to proceed with this? |
| 10:39 | <Ms2ger> | I'm in favour |
| 11:12 | <annevk> | tobie: I think I'm just going ahead and make it happen |
| 12:55 | <tobie> | annevk: might be wrong, but I think the warning belongs at the BS/ReSpec layer rather than at the parser level. |
| 12:57 | <annevk> | tobie: well this is basically saying you can't write interface without Exposed so I don't really see how it's not a parser concern |
| 12:58 | <tobie> | annevk: Because it's described in prose, not as part of the grammar. |
| 12:58 | <tobie> | annevk: also it's ES-binding specific. |
| 13:01 | <Ms2ger> | Not sure I agree with that |
| 13:01 | <tobie> | Ms2ger: with what? |
| 13:02 | <Ms2ger> | That Exposed is ES-specific |
| 13:02 | <annevk> | Yeah, seems that would apply to Wasm and such too |
| 13:02 | <Ms2ger> | OTOH, all of WebIDL is de facto ES-specific, so it doesn't really matter :) |
| 13:02 | <tobie> | Ms2ger: "This section defines a number of extended attributes whose presence affects only the ECMAScript binding." |
| 13:02 | <annevk> | That's probably wrong |
| 13:03 | <tobie> | Well, we can't really find out, can we? |
| 13:03 | <tobie> | :D |
| 13:07 | <tobie> | Anyway, for our specific concerns, here, I'm not sure how this is implemented in BS, but in ReSpec and idlharness, this would need to happen at above the parser level (as the code is designed to handle parser errors, but not warnings). |
| 13:11 | <annevk> | tobie: do you have the ability to warn there in a way that gets folks to fix things? |
| 13:14 | <tobie> | annevk: well, it's an extra check to add to do on the AST, but in practice that should be a lot easier than adding such logic to the parser (which isn't designed to check things like that). |
| 13:15 | <annevk> | Okay, I don't really care how it gets done, just needs to be done |
| 13:25 | <tobie> | annevk: agreed. It just has a higher prob of getting done if the issue is on the right repository. ;) |
| 13:26 | <annevk> | plinss seems pretty good at closing issues so we'll find out soon enough |
| 14:26 | <annevk> | quarter-millimeters |
| 14:26 | <annevk> | I wonder what the use case for that was |
| 14:31 | <annevk> | ah okay, common in Japanese typesetting |
| 16:43 | <gsnedders> | if you have multiple event listeners on an event, is event dispatcher order defined? |
| 16:43 | <gsnedders> | *dispatched |
| 16:43 | <gsnedders> | *dispatch |
| 16:51 | <jyasskin> | gsnedders: i.e. you called addEventListener() multiple times? |
| 16:51 | <gsnedders> | jyasskin: yeah |
| 16:52 | <jyasskin> | The order of addEventListener() calls determines the order the listeners are called. |
| 16:52 | gsnedders | wonders why his Google-foo couldn't find a clear statement saying that :) |
| 16:52 | <gsnedders> | jyasskin: thx! |
| 16:55 | <jyasskin> | gsnedders: https://dom.spec.whatwg.org/#concept-event-listener-invoke is probably a good place to start if you want to trace exactly how it's defined. |
| 16:56 | <gsnedders> | jyasskin: "for each event listener associdated with object" isn't that explicit about iteration order |
| 16:57 | <gsnedders> | also I've basically given up on the DOM spec when it comes to understanding events, given https://github.com/whatwg/dom/issues/474 makes it hard to understand stuff :\ |
| 16:57 | <jyasskin> | It'd be nice to be a bit clearer about that, but https://infra.spec.whatwg.org/#list-iterate says to go in order, and elements are added with https://infra.spec.whatwg.org/#list-append. |
| 16:59 | <gsnedders> | right, the list side is clear |
| 17:01 | <gsnedders> | it's not clear to me what the type of the association is |
| 17:02 | <jyasskin> | gsnedders: Ah, that looks like a bug: "For each event listener associated with object" should be "For each |listener| in the list of event listeners associated with object", since https://dom.spec.whatwg.org/#interface-eventtarget is clear that the EventTarget has a *list* of associated listeners, not just a pile. |
| 17:02 | <gsnedders> | jyasskin: right, and that would be unambiguous |
| 17:36 | <annevk> | If only we had formalized slots long ago this kind of stuff would have been patterned and addressed |
| 17:38 | <annevk> | I also hope that nobody tries to copy the Event specification text since it's full of badness |
| 17:38 | <annevk> | In particular around slots |
| 17:38 | <jyasskin> | The best time to [fix spec infrastructure] is 20 years ago. ;) |
| 17:38 | annevk | wonders if slots are still on tobie's radar |
| 17:39 | <annevk> | jyasskin: I like to stay optimistic and hope we're still at the start of it all |
| 17:39 | <jyasskin> | That's the second half of the quote: "The second-best time is now." :) |
| 17:39 | <annevk> | heh |
| 17:45 | <nox> | They should just be rewritten in Rust. |
| 17:46 | <gsnedders> | can we not rewrite them in something where we can more easily to formal analysis? |
| 17:46 | <nox> | gsnedders: I wasn't being serious. :p |
| 17:48 | <gsnedders> | nox: I was only being somewhat serious. :P |
| 17:49 | <nox> | gsnedders: Too late. Rewrite all specs in Coq, you have two hours. |
| 17:49 | <gsnedders> | nox: Coq? You are so French. ;P |
| 17:49 | <nox> | 🥖🥖 |
| 17:50 | <jyasskin> | The glue code for specs should be something with a formal definition, but after thinking about the purpose of specs for a while, I've concluded that there are some bits in the core where we specifically have to avoid being too formal, either because we want to let implementations innovate (e.g. all the UI parts: how do you formalize "ask the user for permission"?) or because we're referring to other specifications |
| 17:50 | <jyasskin> | that use different styles. |
| 17:51 | <nox> | jyasskin: Just wait two hours and all of them will be specified by gsnedders! |
| 17:52 | <nox> | formally* |
| 17:52 | jyasskin | holds breath |
| 17:52 | <gsnedders> | nox: unforuntately, I've already proven it impossible to formalise the HTML parser in Coq |
| 17:52 | <gsnedders> | (okay, a bit hand-wavey argument, but I did do this in my bachelor's thesis) |
| 17:53 | <nox> | gsnedders: Why? |
| 17:53 | <nox> | Formalise, or implement? |
| 17:55 | <nox> | Apart from the elephant in the room that is JS, I mean. :P |
| 18:06 | <gsnedders> | nox: the elephant in the room is the fact that HTML defines how to parse infinitely long documents, and Coq requires termination |
| 18:07 | <nox> | gsnedders: That's for implementation. |
| 18:07 | <nox> | gsnedders: You can still formalise it. |
| 18:07 | <gsnedders> | nox: yeah, ok |
| 18:08 | <nox> | Otherwise AFAIU CompCert wouldn't be a thing. |
| 18:08 | <nox> | Or https://www.microsoft.com/en-us/research/wp-content/uploads/2016/12/coqasm.pdf which is pretty cute. That being said, I've never did a thesis or whatsoever and I only know Coq superficially. |
| 18:09 | <gsnedders> | IIRC there were some limitations on stuff which doesn't terminate |
| 18:09 | <gsnedders> | but it's been years since I've touched Coq at all, and even that was only a bit superficial |
| 18:11 | <gsnedders> | OK, so you can do nontermination provided you explicitly state where it is and prove each iteration is well-typed |
| 18:11 | <tobie> | annevk: I want to tackle mixins first. |
| 18:28 | <nox> | gsnedders: The naive young me wanted to formalise the semantics of the Erlang VM, then I quickly realised I didn't have the skills. |
| 18:29 | <nox> | The naive less young but still young me thinks maybe in a decade he will be able to do that. |
| 18:36 | <gsnedders> | nox: you have me looking at stuff around Coq for the first time in years; I just about knew enough maths a few years ago to do some basic stuff, now I don't |
| 18:36 | <nox> | gsnedders: Eh eh. |
| 19:57 | <nox> | gsnedders: It's been 10 minutes and you've yet to give me the formalised specs in Coq. |
| 21:26 | <tobie> | If we remove [PrimaryGlobal], where do we define the primary global interface? |
| 21:35 | <Domenic> | I think the idea is that there is no longer a concept of primary global interface |
| 21:35 | <Domenic> | Since IIUC it's only used to determine the exposure set when there's no [Exposed] |
| 21:47 | <tobie> | Domenic: well, at least LegacyWindowAlias relies on that concept. |
| 21:47 | <Domenic> | lol, I thought it'd hard-code Window, per the name. |
| 21:47 | <tobie> | Domenic: I can replace it by Window instead. |
| 21:48 | <Domenic> | I'd kind of rather leave this to annevk since he's excited about it; I think mixins would be more impactful right now. |
| 21:49 | <tobie> | Domenic: Well, I'm half-way through the PR at this point, so… |
| 21:50 | <tobie> | But yeah, agreed wrt to mixins |
| 21:50 | <Domenic> | Mmm, OK' |