| 01:40 | <oliver> | I have some problems keeping the Websocket connection alive in Apache since they deprecated mod_proxy_wstunnel. Now it’s disconnecting after the ProxyTimeout or Timeout is reached. If I understand the spec correctly the ping mechanism is the right way to keep the connection alive. Is it by means of the websocket specification correct to disconnect the websocket if it was idle for only a short time like the timeout interval? It seems inefficient to me to send ping and pong below such an interval from many clients for keepalive purposes. |
| 01:52 | <Domenic> | smaug: jarhar: I think the DOM spec is fine with sync events, but I agree this does seem counter to our goals of removing mutation events. |
| 01:54 | <Domenic> | annevk: keithamus: I agree that OpenUI thread is very weird. It got even weirder if you read their minutes on a related issue. https://github.com/openui/open-ui/issues/532#issuecomment-1934844026 . My current hypothesis is that OpenUI has decided to conflate the four separate things: parser behavior, styling, shadow DOM structure, and changed keyboard/a11y behavior, and so whenever annevk talks about one of those, they go "what about the other?", and confusion follows. |
| 01:54 | <smaug> | removeNamedItem starts to behave a bit oddly if removing attribute may have already executed js. (I'm excluding custom elements here) |
| 01:56 | <Domenic> | I guess odd is in the eye of the beholder; seems fine to me. |
| 01:57 | <smaug> | and CEReaction happens after attribute change steps, so it doesn't play nicely with that either |
| 02:06 | <sideshowbarker> | (oh, details has some rather unusual mutation events flag usage in the spec) Yeah I don’t know the background on the decision to include that suppress-firing-of-mutation-events behavior in the requirements for details@name; but I can say that in the case of the WebKit at least, without suppressing mutation events in that way — even if it weren’t required by the spec — the WebKit implementation would otherwise run into existing security asserts in the code that’d prevent firing mutation events in that case anyway. And implementing Anyway, I wish we all could all just go ahead and disable mutations-events support in all engines in the very near future. I know Chrome at least is scheduled to do so later this year. I don’t know if other engines have it scheduled yet. Otherwise, it seems like we’re letting the overhead of needing to deal with mutation events when implementing new features (and in the spec) just keep on being an ongoing PITA indefinitely. |
| 02:08 | <smaug> | It was agreed already 2011 or 2012 to remove mutation events and FF has warned about them being deprecated since 2012 😉 |
| 02:15 | <sideshowbarker> | Yeah, definitely not a case where developers haven’t got plenty of warning. Maybe once (if) Chrome actually manages to drop support this year, then other engines will finally be able to go ahead with dropping support too. I mean, once they’re not supported in Chrome any longer, you’d have to wonder what kind of existing apps/code with mutation events that developers would have running that weren’t already now broken in Chrome. I guess at that point it would be apps intentionally targeted only to Firefox or Safari users. Some extensions maybe, I dunno |
| 02:17 | <sideshowbarker> | So anyway, fingers crossed on Chrome actually being able to successfully drop support for mutation-events this year |
| 07:36 | <annevk> | smaug: what will be weird for removeNamedItem that's not weird for removeAttribute? |
| 07:47 | <annevk> | Domenic: should https://html.spec.whatwg.org/multipage/nav-history-apis.html#dom-navigation-cangoforward be size - 1? |
| 07:47 | <annevk> | (Via https://github.com/WebKit/WebKit/pull/23578.) |
| 07:48 | <Domenic> | annevk: I don't understand the question |
| 07:48 | <Domenic> | Oh, size minus 1, not size negative 1 |
| 07:48 | <annevk> | Domenic: since the index is 0-based, how can it ever match size? |
| 07:49 | <Domenic> | Yes, that seems clearly like a bug... let me double-check Chromium to confirm there's not something galaxy-brained going on |
| 07:49 | <Domenic> | Yes indeed, Chromium has it correct |
| 07:49 | <Domenic> | I'll fix |
| 07:51 | <Domenic> | https://github.com/whatwg/html/pull/10130 |
| 08:27 | <annevk> | Domenic: keithamus: https://github.com/whatwg/html/issues/9799#issuecomment-1935512376 |
| 08:27 | <annevk> | keithamus: happy to chat further if you think that'd be useful. I have time today. |
| 08:47 | <keithamus> | annevk Domenic name the time and I’ll do my best. I’d love to figure out the path forward for both. |
| 08:48 | <keithamus> | I’m free in about 15 mins |
| 09:06 | <Domenic> | It's 6pm Friday for me :) |
| 09:06 | <Domenic> | I don't think I'm that necessary though |
| 10:24 | <smaug> | annevk: removeAttribute doesn't return the removed attribute, removeNamedItem does |
| 10:27 | <annevk> | smaug: is the weirdness that you get an attribute back that might still be attached? |
| 10:29 | <smaug> | the weirdness is that when you get the attribute back, scrips may have already run and added another attribute there |
| 10:29 | <smaug> | or basically anything may have happened |
| 10:29 | <smaug> | well, that anything may have happened is of course an issue with removeAttribute too |
| 10:30 | <smaug> | But the issue is more obvious with removeNamedItem |
| 10:32 | <annevk> | I see, I guess that's fair. But this does not rise to the level of mutation event issues, I think. |
| 10:32 | <smaug> | right, because it is after attribute removal |
| 10:32 | <annevk> | Note that Trusted Types also allows for this. |
| 10:33 | <annevk> | Hmm, I think Trusted Types is before removal? |
| 10:33 | <annevk> | smaug: review https://github.com/whatwg/dom/pull/1247 please? |
| 10:38 | <smaug> | Though, DOMAttrModified isn't the particularly bad mutation event. The bad one is DOMNodeRemoved |
| 10:38 | <smaug> | But looking at that TT PR |
| 18:19 | <annevk> | https://portal.gitnation.org/contents/yous-the-platform talk about adding the submitter argument to the FormData constructor |