| 00:24 | <jmdyck> | I just noticed that, in the HTML spec, if you have a variable like <var>x<sub>current</sub></var> and you click on the 'x' part, it highlights, but if you click on the 'current' part, it doesn't. I guess that's because the target of the click event is the sub, not the var, and the sub doesn't care about clicks. |
| 01:35 | <Domenic> | We should be able to fix this with a .closest() check in the click handler. (Ideally we should PR also to the Bikeshed version as having them diverge could cause problems down the line, but that's not a big deal.) |
| 01:42 | <Domenic> | bakkot: I've been banging the drum about how event-based aborting and internal web platform aborting having different semantics is bad for quite a while, but annevk always insists it's a feature not a bug. I appreciate you laying out all the problems it causes clearly. My preferred fix would be to improve the event-based infrastructure until it has all the nice properties, and then make the internal web platform code paths use it as well. There are various issues gesturing in that direction; I guess https://github.com/whatwg/dom/issues/1195 is the latest. It feels like something that might be simple enough that one person writing spec + tests, and attending WHATNOT to pin down implementer interest, could succeed. |
| 01:48 | <bakkot> | Do you think we could get away with changing the way the event-based infrastructure currently works? I would not be surprised to learn e.g. someone is relying on the stopImmediatePropagation behavior |
| 01:48 | <bakkot> | though, I mean, it is a pretty weird thing to rely on, so maybe we could |
| 01:50 | <bakkot> | I don't think it's currently possible to make an event which doesn't respect stopImmediatePropagation, but I suppose we could introduce such a thing. Domenic is that the kind of thing you mean by "improve the event-based infrastructure"? |
| 01:51 | <Domenic> | Yes exactly. |
| 01:52 | <Domenic> | One possible end result would be that to get good behavior you have to do abortSignal.addEventListener("abort", listener, { a bunch of strange options }) and then we sugar that over with abortSignal.whenAborted(listener)?? Or something??? Not 100% satisfying; just spit balling. |
| 01:53 | <Domenic> | Or maybe it's configurable at the new EventTarget() level instead of the addEventListener() level, and then we can hopefully retroactively say all AbortSignals are configured that way. |
| 01:56 | <bakkot> | I would very much like a whenAborted anyway, especially if it has the behavior of immediately invoking listener if the signal is already aborted, because I think the existence of such a method is the only way we could conceivably start using AbortController in the actual JS (writeup of thoughts on that topic at https://github.com/tc39/proposal-concurrency-control/issues/14, there spelled addTeardown) |
| 03:39 | <Domenic> | The "run immediately or async" behavior is a pretty good argument for such a method. Although, do we still worry about zalgo? |
| 06:15 | <annevk> | Congrats to Domenic on retiring and congrats to zcorpan and Mattias Buelens for becoming the new HTML and Streams Workstream editors, respectively! 🎉 |
| 06:18 | <annevk> | Domenic: do you want to finish https://github.com/whatwg/sg/pull/253 before you leave? Just noticed that is still open. |
| 07:04 | <Domenic> | Done! |
| 07:35 | <Ms2ger> | Enjoy the new situation! |
| 09:55 | <zcorpan> | What did Ladybird implement here? https://github.com/whatwg/html/pull/7205 |
| 09:59 | <sideshowbarker> | @akaster:serenityos.org would know, but I'd reckon it follows the existing spec text — not what's in that patch |