| 08:10 | <MikeSmith> | annevk: if/when you’re around (and not in the middle of working on something else), I wanted to ask you what exactly needs doing for https://github.com/whatwg/html/issues/5539#issuecomment-627952544 as far as updating the MDN articles |
| 08:11 | <MikeSmith> | (either here on in MDN Web Docs on Mozilla Matrix) |
| 08:13 | <annevk> | MikeSmith: basically, whether a document is in a secure context is a function of its top-level document and doesn't depend on the opener chain |
| 08:14 | <annevk> | MikeSmith: so if http://example.com/ popups https://booyah.example/ the latter will be in a secure context |
| 08:15 | <annevk> | MikeSmith: thanks for fixing that, happy to review |
| 08:15 | <MikeSmith> | OK |
| 08:15 | <annevk> | And I guess then we can close out the HTML issue |
| 08:15 | <MikeSmith> | yup |
| 08:15 | <MikeSmith> | will try to get the changes made today |
| 08:17 | <MikeSmith> | right now I’m reviewing the set of features in the HTML spec that are known not to have two implementations |
| 08:18 | <MikeSmith> | starting from the raw list at https://w3c.github.io/mdn-spec-links/less-than-2.html?spec=html |
| 08:18 | <MikeSmith> | ...which has a number of false positives due to BCD having incomplete data |
| 08:19 | <MikeSmith> | so I need to update BCD for some of those features |
| 08:19 | <MikeSmith> | navigator.mimeTypes for example |
| 08:19 | <MikeSmith> | (not that any developers actually care about that at this point) |
| 11:05 | <benjamingr__> | Why is passing `undefined` or `null` supported in addEventListener? |
| 11:05 | <benjamingr__> | I mean, `addEventListener('eventName', undefined)` :]? |
| 11:06 | <annevk> | benjamingr__: refactoring event tests seems somewhat reasonable, but it might be worth opening an issue first to discuss an approach |
| 11:07 | <benjamingr__> | Hey, sure, so should I open an issue in the wpt repo? |
| 11:07 | <annevk> | benjamingr__: probably because not all user agents threw an exception there and adding exceptions later is hard |
| 11:07 | <annevk> | benjamingr__: yeah, that seems good |
| 11:07 | <benjamingr__> | thanks, I will :] |
| 11:07 | <annevk> | benjamingr__: cc @smaug---- and @domenic I guess and me |
| 11:16 | <benjamingr__> | Opened, thanks a lot https://github.com/web-platform-tests/wpt/issues/23858 |
| 11:38 | <benjamingr__> | I'm still a bit confused about passive listeners, why is "defaultPrevented" a property of the event but passive a property of the listener? So the event listener keeps context regarding whether or not it's part of a passive event listener and if it is `preventDefault` is a no-op? |
| 11:40 | <annevk> | benjamingr__: passive listeners are a bit of a hack to allow UAs to dispatch events differently |
| 11:40 | <annevk> | benjamingr__: based on the listeners |
| 11:41 | <benjamingr__> | Is my understanding correct and the events keep internal state about whether preventDefault is being called from the context of a passive listener? |
| 11:42 | <annevk> | benjamingr__: well, the dispatcher can keep that state I think |
| 11:42 | <annevk> | benjamingr__: as it will have inspected the listeners in order to determine if it can dispatch a passive event |
| 11:42 | <annevk> | iirc |
| 11:42 | <annevk> | it's been a while |
| 11:43 | <benjamingr__> | Thanks, I'll go digging through the spec and tests :] thanks a lot for the help btw, looking forward to having a universal spec compliant way to dispatch events and cancellation in JavaScript |
| 12:25 | <benjamingr__> | Just checking, how bad would it be for Node to behave differently from `EventTarget` regarding `addEventListener('eventName', null)`? https://github.com/nodejs/node/pull/33637#pullrequestreview-420889677 |
| 12:27 | <annevk> | benjamingr__: do you have a developer console equivalent? |
| 12:28 | <benjamingr__> | annevk: We have `stdout` (and stderr for warnings) :] |
| 12:28 | <annevk> | I'd use that; I think as Domenic mentioned elsewhere, if you're not going for full compatibility, it'll just be confusing |
| 12:29 | <benjamingr__> | Use that to do what? Emit a warning for example? |
| 12:29 | <annevk> | benjamingr__: yes |
| 12:30 | <benjamingr__> | I generally agree with Domenic (and that PoV). Would Node.js writing a warning to `stderr` for passing `undefined` or `null` as a second argument be allowed from a spec point of view? |
| 12:31 | <annevk> | benjamingr__: yeah, console is UI territory |
| 12:31 | <benjamingr__> | Ok great, thanks again. I'll go ahead and suggest that in the issue and see if it helps. |
| 12:32 | <annevk> | Although I guess in Node.js it's probably observable from script? Bit icky, but still seems okay to me |
| 12:34 | <benjamingr__> | It is observable from the script though generally `stderr` is used for things that are not part of the program output (which is why Node emits warnings there). The downside is that the user won't likely see the warning in production but that's true for all warnings Node emits (because stdout is considered, well, output :]) |
| 14:25 | <annevk> | Domenic: see also https://github.com/whatwg/storage/issues/95 |
| 14:25 | <annevk> | Domenic: still need to do Privacy/Security, maybe later, maybe next week |
| 14:26 | <annevk> | Domenic: and not really sure what to do with 5 MiB, perhaps just leave that locally, but in a different place, closer to all the Storage infrastructure (or perhaps the proxy map) |
| 14:26 | <annevk> | concept-Storage-map* |
| 14:31 | <Domenic> | annevk: makes sense. I'd appreciate more explicit links to the sections of the Storage Standard that you think contain the HTML text... it's not clear to me that Storage covers the same things, but I'm not the Storage editor. |
| 15:20 | <annevk> | Domenic: feel free to add questions there |
| 23:04 | <benjamingr__> | Hey, is https://dom.spec.whatwg.org/#window-current-event (window.event) fine not to implement in Node.js EventTarget? (Since it's marked "Legacy extensions") |
| 23:22 | <Domenic> | benjamingr__: yes, IMO. I would call it a separate API, similar to CustomEvent or MouseEvent. |
| 23:23 | <benjamingr__> | ack, thanks. |
| 23:23 | <Domenic> | Also, practically speaking, it is mostly used by code in event handler attributes, e.g. `<body onclick="console.log(event.target)">`. So I expect there to be very few interop issues that would come from omitting it. |