| 00:26 | <Dominic Farolino> | smaug: I think mutation events were already removed: https://github.com/whatwg/html/pull/10573. But yes I agree, shouldn't block stage 3. |
| 00:27 | <smaug> | (Implementations haven't removed mutation events, https://github.com/whatwg/dom/issues/305#issuecomment-2306411923) |
| 02:58 | <sideshowbarker> | (for those who care about the document-conformance/authoring parts of the requirements in the spec) https://github.com/whatwg/html/pull/10752 |
| 07:15 | <annevk> | push-api apparently allows (and enforces in certain cases) wrapping after an equals sign of an attribute. That's a new one. |
| 08:07 | <Sacha Greif> | hi all! I'm the main guy who runs the State of JS/CSS/etc. surveys. Always happy to get feedback to help make them more helpful for the community :) |
| 08:36 | <annevk> | keithamus: heya, I could make time today for https://github.com/whatwg/html/pull/9841, but I was wondering if you could squash all the commits and rebase on top of main as there are conflicts at the moment |
| 08:38 | <annevk> | keithamus: I also see some minor issues such as wrapping before a closing tag (</code></dfn>) and indentation beyond the start tag on the preceding line that you might want to tackle while doing that? |
| 08:40 | <annevk> | WPT PR is also out-of-date it seems |
| 08:40 | <keithamus> | annevk: sure, I’m just about to get on the road but in about an hour I’ll update both spec and wpt pr |
| 11:04 | <annevk> | keithamus: oh I see that in August 27 I also expressed confusion as to how this event could work. That comment was never addressed. |
| 11:05 | <annevk> | I'm also once again confused at the compatibility story we ended up with around potentially changing the default of button type. Trying to find the relevant minutes... |
| 11:12 | <annevk> | Found it: https://github.com/whatwg/html/issues/10441 |
| 11:13 | <annevk> | keithamus: so what I think I'm missing is changes to the button element type attribute reflection that take that into account |
| 11:14 | <annevk> | keithamus: in that we want the type getter to return button when the button element has command and commandfor attributes |
| 11:18 | <annevk> | It's a bit subtle as the type getter can mismatch with the actual state, but that seems okay-ish. |
| 11:23 | <keithamus> | Okay, apologies I thought we resolved the other way around. So we want the button to not be a submit button if it has command or commandfor? It should be in the button state. |
| 11:25 | <annevk> | keithamus: I suspect the easiest way to do this is to introduce a Maybe Button state. The type getter would return "button" in that state. When associated with a form the button wouldn't work and when outside a form it would act like a button. |
| 11:25 | <annevk> | So I think behavior-wise it's pretty much what you have, except that it doesn't account for the type getter. |
| 11:26 | <ljharb> | so i could have an explicit type submit that isn't a submit button? O.o that seems bad (when no type is provided, anything that lets it default to button is an improvement, defaulting to submit is painful) |
| 11:27 | <annevk> | And then I think there's the separate question of what should happen when type is set to submit or reset and you have these command/commandfor attributes. Perhaps in that case the command/commandfor attributes are to be ignored? Luke Warlow was looking at this for popover at some point. |
| 11:27 | <annevk> | ljharb: the problem is that <button> defaults to being a submit button, which is not necessarily great for new use cases. |
| 11:28 | <ljharb> | right - it's a very bad default, and when type is omitted, i think it's totally fine to quietly make it button when it has a new attribute |
| 11:28 | <ljharb> | but if i explicitly put type="submit" then violating that seems bad to me |
| 11:28 | <annevk> | Yeah agreed. |
| 11:29 | <ljharb> | (i just learned about command/commandFor recently, btw, and it seems very cool - is there a polyfill anywhere for its behavior?) |
| 11:30 | <annevk> | (The main reason why we're not defaulting to button inside a form immediately is because of backwards compatibility with browsers where it would submit the form. But five years from now or so we can change that as well.) |
| 11:30 | <keithamus> | (i just learned about command/commandFor recently, btw, and it seems very cool - is there a polyfill anywhere for its behavior?) |
| 11:34 | <keithamus> | And then I think there's the separate question of what should happen when type is set to submit or reset and you have these command/commandfor attributes. Perhaps in that case the command/commandfor attributes are to be ignored? Luke Warlow was looking at this for popover at some point. |
| 11:35 | <keithamus> | The other choice is to not do either behaviour (submit nor command/commandfor) |
| 11:37 | <annevk> | Agreed, I just wrote that down in https://github.com/whatwg/html/issues/9625#issuecomment-2464496320 |
| 11:45 | <keithamus> | annevk: how would I type the command attribute state? (Trying to address https://github.com/whatwg/html/pull/9841/files#r1834138912). It's not a string, I presume (it's an enum in the impls). |
| 11:46 | <annevk> | keithamus: in HTML it's a string, unless you introduced a concept that only contains the relevant string values, in which case you could use that concept, but I don't think that exists |
| 11:46 | <keithamus> | okay great I'll use a string |
| 11:47 | <annevk> | Oh wait, the state hmm |
| 11:47 | <annevk> | I was thinking the actual value |
| 11:48 | <annevk> | keithamus: hmm maybe it's easier to just pass in the element that has the attribute or some such |
| 11:48 | <keithamus> | oh yeah okay |
| 11:49 | <keithamus> | hmm... but an event is dispatched before the steps are called so referencing the element might be bad, it could change during the event phase... |
| 11:52 | <annevk> | keithamus: maybe just do state state for now then. And don't talk about it being in a state, but being a state. "If command is the Close or Show Modal state, then return true." |
| 13:48 | <Noam Rosenthal> | Why would reordering them change anything spec-wise? |
| 13:49 | <Noam Rosenthal> | This seems like an implementation concern. I couldn't find anything in the spec that would be problematic because of this, and we've added pretty good test coverage for this type of scenario (though there could always be more) |
| 13:49 | <Noam Rosenthal> | Dominic Farolino did the iframe work though so perhaps I'm missing something. |
| 15:28 | <annevk> | Ms2ger: one thing that needs to be done for https://github.com/whatwg/html/pull/9893 is filling out OP. Having a clear proposed commit message there, ideally outlining some of the design, test strategy, impl bugs, MDN coverage, etc. goes a long way to making reviewing easier. |
| 15:29 | <Ms2ger> | Will do, thanks for the reminder |
| 15:34 | <annevk> | That also makes it scary, but I'll have another look anyway as it's been a long time. |
| 15:36 | <annevk> | Hmm, I remember we had a discussion before about renaming all the "concepts" to "principal concepts" not being great. |
| 15:52 | <annevk> | Ms2ger: hopefully I gave you a few things to look into. Overall this still looks good and I guess impl/TC39-wise it's more accepted now so maybe this can be done soonish modulo the massive number of needed PRs that it appears you all have signed up for... |
| 15:59 | <Noam Rosenthal> | (Implementations haven't removed mutation events) |
| 16:09 | <annevk> | (Oh and it seems that Shannon Booth from Ladybird also has some good ShadowRealm feedback.) |
| 16:14 | <Ms2ger> | Thanks again, I think :) |
| 19:30 | <Dominic Farolino> | There's nothing in the spec that's problematic regarding to this simply because the spec doesn't handle (at all) what we've referred to colloquially as the session history re-parenting issue — i.e., the case where upon going back to a non-bfcached page, the browser tries to reconcile the structure of the DOM with the structure of the nested session history, and load the latest nested session history items into the corresponding iframes. |
| 19:34 | <Dominic Farolino> | So first, that's bad in general. But I don't think it intersects too much with moveBefore(). moveBefore() doesn't change the order of the iframes from the perspective of the browser process, session history, or other iframes that can reach the moved iframes via proxies. That is, it doesn't re-order window.frames: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/dom/nodes/moveBefore/tentative/iframe-document-preserve.window.js;l=110-116;drc=0ba2bf02d3c2d6bf52c53012cdb5993b50ba82ed |
| 19:36 | <Dominic Farolino> | So I think navigating backwards to the non-bfcached top-level page should behave the same as it would be if said page did not use moveBefore() before it was navigated away. |
| 19:38 | <Dominic Farolino> | (Implementations haven't removed mutation events, https://github.com/whatwg/dom/issues/305#issuecomment-2306411923) |
| 19:45 | <Dominic Farolino> | Domenic: I've looked but I can't find a bug tracking the iframe session history reparent/restoration problem. Do you know if one exists? This is the case where you navigate backwards to a top-level non-bfcached page with iframes, and try and reconcile the page's iframe structure with the nested iframe history structure, to load the latest iframe history entries in the page's iframes.. |
| 19:45 | <smaug> | have you tested session history? |
| 19:46 | <smaug> | (you have 🙂 , or at least have thought about it) |
| 20:49 | <Noam Rosenthal> | smaug: both session history reparenting and mutation events are important/interesting things to consider for implementation but they're both also not in the HTML standard... given that I'm a bit confused about the level of expectations here in terms of spec/interop, apart from each implementation having internal tests to make sure things stay sane |
| 20:50 | <smaug> | session history is in HTML spec, and seems like moveBefore may change its behavior |
| 20:52 | <Noam Rosenthal> | It doesn't though. As I said earlier, there are no places in the HTML spec around session history that moveBefore changes. We have looked at it in pretty deeply... if you find a place where it does please be specific |
| 20:52 | <smaug> | Well, it may break the behavior, let's say so. |
| 20:54 | <Noam Rosenthal> | Well, it may break the behavior, let's say so. |
| 20:55 | <smaug> | Well, there hasn't been any need for "reparenting" before |
| 20:55 | <Noam Rosenthal> | We've tested that moveBefore doesn't reorder window.frames, and some of the places in the spec collect navigables in tree order |
| 20:55 | <smaug> | This is a new thing caused by moveBefore |
| 20:56 | <smaug> | Ok, and if you go back to a page which had iframes reordered, what gets restored to iframes? |
| 20:57 | <Noam Rosenthal> | No change from before I guess? |
| 20:58 | <Noam Rosenthal> | For this kind of bug to occur you need to save the tree order of navigables somehow separate from the tree order of frames and have them out of sync due to moveBefore. I can see how a bug like that might occur in implementation but not in the spec |
| 20:59 | <Noam Rosenthal> | (Again, this goes back to auto iframe-restore, which is a non-standard part of session history) |
| 21:01 | <Noam Rosenthal> | Ok, and if you go back to a page which had iframes reordered, what gets restored to iframes? |
| 21:01 | <smaug> | ok, I guess if window.frames doesn't change, this might not be as big issue |
| 21:02 | <smaug> | oh, Element had hidden those messages well from me |
| 21:36 | <Dominic Farolino> | haha no worries. Yeah I understand the concern here, but I think from the perspective of things outside of the local DOM inside of the Document that experienced the moveBefore, nothing changes regarding child frame order, including in session history. |
| 23:02 | <sideshowbarker> | PSA: If your environment is macOS and you’re working on an HTML spec PR and when you try to run the …or else just export those |