2024-11-01 [07:52:48.0378] Anyone understands what "If these attributes are omitted from an element, then the language of this element is the same as the language of its parent element, if any (except for slot elements in a shadow tree)." in the spec means? slot elements are somehow special cased, but it doesn't explain how? 2024-11-03 [23:57:48.0609] That language is not for implementers. Maybe it got out of sync with the implementer requirements? [23:58:10.0042] As for `moveBefore()` and focus, I thought we decided not to do that? Did something change? [02:21:13.0457] > <@annevk:matrix.org> As for `moveBefore()` and focus, I thought we decided not to do that? Did something change? Ryosuke brought this up originally and it was left open, I suggested an additional alternative here that I think satisfies all the cases. 2024-11-04 [00:42:24.0190] Domenic: FYI: https://github.com/whatwg/dom/issues/1321 [00:43:46.0096] Noam Rosenthal: I don't get the impression he feels strongly about it. One point that was raised is that `moveBefore()` won't be state-preserving for accessibility as layout will be impacted. [00:48:02.0681] > <@annevk:matrix.org> Noam Rosenthal: I don't get the impression he feels strongly about it. One point that was raised is that `moveBefore()` won't be state-preserving for accessibility as layout will be impacted. I don’t exactly understand the a11y thing. Changing style can affect layout regardless of DOM structure changes [00:48:53.0136] Re firing the events - sounds good, let’s start without like we said at WHATNOT and we can revise based on community feedback. [04:40:15.0563] Anyone with HTML parsing know-how able to tell me if I'm missing something here or if this template/foreignObject interaction indeed leads to bugs? :) https://github.com/whatwg/html/issues/10739 [04:51:39.0438] Question about fetch metadata. It appears that all of the cases where page1.example is a) redirecting to page2.example, b) opening page2.example in a popup, c) navigating to page2.example - They are all done with Fetch Metadata of {sec-fetch-dest: document, sec-fetch-mode: navigate, sec-fetch-site: cross-site}. I wonder if it would be useful to have different or additional metadata for popups as they will include an opener reference (which the other cases don't). -- I am already fully aware that COOP exists which can control the popup case (but not make the browser tell beforehand) [04:58:58.0011] Noam Rosenthal: well, in that we preserve state in the DOM tree, but for the a11y tree it'll be the same as remove/insert. [05:00:39.0169] freddy: there's a popup proposal in the Fetch Metadata repo, been there since forever [05:00:54.0139] Andreas Kling: I'll have a look, but your best bet would be hsivonen or zcorpan I suspect [05:01:57.0471] annevk: great minds think alike, huh [05:04:55.0086] Andreas Kling: Likely a spec bug [05:05:26.0991] > <@annevk:matrix.org> Noam Rosenthal: well, in that we preserve state in the DOM tree, but for the a11y tree it'll be the same as remove/insert. Right. [05:09:15.0841] Andreas Kling: given that it checks for a template element on the stack of open elements, I'm inclined to think that's inclusive of a namespace and therefore it wouldn't find any element [05:09:52.0982] Andreas Kling: as whenever the HTML specification talks about elements that's about a particular identity derived from local name and namespace [05:10:13.0476] hsivonen: ^^ [05:11:16.0882] annevk: I recall there having been a bug on this theme previously. (Part of how the combination of the introduction of SVG on one hand and template on the other resulted in a bunch of bugs.) [05:11:46.0413] annevk: But it's indeed possible that the spec language is defined in a way that implies the HTML namespace on the stack. [05:34:18.0630] Ohhh, interesting! We've indeed implemented stack checks as "is this tag name present on the stack", but we're ignoring the namespace [05:56:52.0356] I wonder if one could put something on the stack with a namespace prefix. I suspect not as the stack is controlled by the HTML parser. [05:58:49.0446] > <@annevk:matrix.org> I wonder if one could put something on the stack with a namespace prefix. I suspect not as the stack is controlled by the HTML parser. No. Though some attributes can have a namespace prefix [06:02:05.0989] Hmm, the inconsistency in the spec with when namespaces are explicit isn't ideal. See https://html.spec.whatwg.org/#has-an-element-in-scope (and the next few "in foo scope" definitions) [06:03:47.0804] Andreas Kling: https://html.spec.whatwg.org/#xml > Except where otherwise stated, all elements defined or mentioned in this specification are in the HTML namespace ("http://www.w3.org/1999/xhtml"), and all attributes defined or mentioned in this specification have no namespace. 2024-11-05 [23:16:25.0790] what in the HTML spec defines that `setTimeout(function(x){ alert(1) }, 10000); window.location = "about:blank"` won't actually create that alert after 10s? is this just step 1 of the in parallel section of https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#run-steps-after-a-timeout? [23:17:24.0403] Sam Sneddon [:gsnedders]: I think the task will be associated with a document that's not fully active and thus will be skipped in the event loop processing model [23:19:00.0712] Perhaps "cannot show simple dialogs" should also have a fully active check though. Not sure what happens if you run `alert()` on a window of a removed nested document. [23:20:33.0149] https://software.hixie.ch/utilities/js/live-dom-viewer/saved/13247 suggests we should probably add that check. [23:24:32.0219] Filed https://github.com/whatwg/html/issues/10742 [23:24:48.0775] My actual context here, FWIW, is figuring out what should happen if you do WebDriver's `session.execute_async_script("setTimeout(arguments[0], 10000); window.location = 'about:blank'")`, and whether that is actually well-defined. [23:25:23.0302] Where most of my question is about whether it's well-defined whether setTimeout actually calls its handler. [23:25:39.0722] * Thus my question here is mostly where it's defined where the handler is called. [23:28:00.0215] Which handler? [23:37:24.0770] the TimerHandler (the first argument to `setTimeout`) [23:39:05.0924] I think that's well-defined along the lines I said above, yes. [01:20:40.0251] annevk: is the iteration order of the inclusive ancestors undefined in https://dom.spec.whatwg.org/#ref-for-concept-tree-inclusive-ancestor%E2%91%A1 ? [08:48:04.0577] Correct, there's no predefined order for inclusive ancestors, the spec needs to specify whether it's top-down or bottom-up [10:02:21.0293] Yeah, that should say something about order. 2024-11-06 [04:56:12.0477] I filed an issue [06:05:13.0949] Nice, anyone want to fix it? Good exercise if you're new to standards. 2024-11-07 [00:50:20.0343] Anyone here signed up for bsky.app? I'm @annevk.nl. [01:29:48.0990] :target and text fragments only work for the first page load if the element or text is available before onload. If the content is created from a `fetch()` + script, that can happen after onload. Should we have an explicit API to delay the load event, or to go "try again now to hash-navigate" ? [01:46:53.0758] Hmm, `fetch()` normally delays the `load` event as well I think, but of course not if you use it after it. Perhaps what you suggest is okay within some timeout, but it doesn't seem generally okay. [02:19:00.0155] zcorpan: Given the following WPT test case: ```html ``` …and given the spec requirements at https://w3c.github.io/html-aam/#img-element-accessible-name-computation — specifically this requirement: > *Otherwise use `alt` attribute, even if its value is the empty string.* …then it seems that the expectation for that test should be the empty string. But as you case, instead the expectation is `title` (from the `title` attribute value). And https://wpt.fyi/results/accname/name/comp_tooltip.html shows that all engines pass that test. So it seems like they’re all violating that _“use `alt` attribute, even if its value is the empty string”_ spec requirement. [02:19:22.0610] * zcorpan: Given the following WPT test case: ```html ``` …and given the spec requirements at https://w3c.github.io/html-aam/#img-element-accessible-name-computation — specifically this requirement: > _Otherwise use `alt` attribute, even if its value is the empty string._ …then it seems that the expectation for that test should be the empty string. But as you case, instead the expectation is `title` (from the `title` attribute value). And https://wpt.fyi/results/accname/name/comp\_tooltip.html shows that all engines pass that test. So it seems like they’re all violating that _“use `alt` attribute, even if its value is the empty string”_ spec requirement. [02:19:56.0103] Or else, is there something I’m misunderstanding? [02:20:31.0924] * zcorpan: Given the following WPT test case: ```html ``` …and given the spec requirements at https://w3c.github.io/html-aam/#img-element-accessible-name-computation — specifically this requirement: > _Otherwise use `alt` attribute, even if its value is the empty string._ …then it seems that the expectation for that test should be the empty string. But as you can ses, instead the expectation is `title` (from the `title` attribute value). And https://wpt.fyi/results/accname/name/comp\_tooltip.html shows that all engines pass that test. So it seems like they’re all violating that _“use `alt` attribute, even if its value is the empty string”_ spec requirement. [02:20:39.0946] * zcorpan: Given the following WPT test case: ```html ``` …and given the spec requirements at https://w3c.github.io/html-aam/#img-element-accessible-name-computation — specifically this requirement: > _Otherwise use `alt` attribute, even if its value is the empty string._ …then it seems that the expectation for that test should be the empty string. But as you can see, instead the expectation is `title` (from the `title` attribute value). And https://wpt.fyi/results/accname/name/comp\_tooltip.html shows that all engines pass that test. So it seems like they’re all violating that _“use `alt` attribute, even if its value is the empty string”_ spec requirement. [02:31:04.0588] > <@zcorpan:mozilla.org> :target and text fragments only work for the first page load if the element or text is available before onload. If the content is created from a `fetch()` + script, that can happen after onload. Should we have an explicit API to delay the load event, or to go "try again now to hash-navigate" ? Wouldn't this allow delaying the load event indefinitely and various similar footguns? [02:57:51.0179] I think that's possible in theory already as the specification doesn't have network timeouts. But yeah, I'm not entirely convinced the load event is the correct primitive to build more upon. [03:03:20.0892] Noam Rosenthal: yes [03:03:37.0051] though the "try now" API doesn't [03:04:07.0844] annevk: await res.json() doesn't delay [03:05:10.0938] zcorpan: Ah wait I see: https://w3c.github.io/accname/#step2E says: > E. Host Language Label: Otherwise, if the current node's native markup provides an attribute (e.g. alt) or element (e.g. HTML label or SVG title) that defines a text alternative, return that alternative in the form of a flat string as defined by the host language, **unless the element is marked as presentational (role="presentation" or role="none").** …`` is `role="presentation"` [03:08:02.0323] sideshowbarker: somewhat action at a distance [03:09:17.0679] annevk: actually where does the spec say to delay the load event for `fetch()`? [04:54:46.0592] zcorpan: it's prolly an open issue? At least I was under the impression that most fetches initiated before `load` fires end up delaying the `load` event, but maybe `fetch()` is somehow exempted? [05:31:52.0110] annevk: I think https://searchfox.org/mozilla-central/search?q=symbol:_ZN7mozilla3dom8Document13UnblockOnloadEb&redirect=false is relevant for gecko. Includes e.g. fonts but not `fetch()` afaict [05:49:49.0799] > <@annevk:matrix.org> zcorpan: it's prolly an open issue? At least I was under the impression that most fetches initiated before `load` fires end up delaying the `load` event, but maybe `fetch()` is somehow exempted? In HTML this is explicitly specified for each operation that delays the load event, there's nothing general for fetches [05:59:09.0736] Noam Rosenthal: I know, but I'm pretty sure we discovered holes in that model [05:59:51.0900] > <@annevk:matrix.org> Noam Rosenthal: I know, but I'm pretty sure we discovered holes in that model OK gotcha [12:19:10.0246] jarhar: just looking at the patches... which one defines what select::picker(select) maps to? [13:13:46.0804] are you talking about the chromium implementation? if so, this is it: https://chromium-review.googlesource.com/c/chromium/src/+/5817433 [13:26:26.0795] annevk smaug: We didn't get to it on the WHATNOT agenda today, but we were hoping to discuss graduating `moveBefore()` to stage 3 — what do you think? I've marked the DOM PR as ready to review. [13:27:28.0286] spec prs [13:28:05.0990] Well, I look at the diff views, and the many prs are split to quite a few diffs [13:28:37.0002] From implementation point of view I need to still check session history handling, that is the most worrisome to me [13:31:22.0920] Like if you have iframes, and you navigate all them multiple times. Now you reorder the iframe elements and load some more pages to them. Then load a new top level page in a way which doesn't put the first top level page to bfcache. Then go back to the first top level page. What gets loaded to which iframe? [13:45:08.0757] Somewhat related to my ancient testcase http://mozilla.pettay.fi/moztests/history2/Start.html Chrome's behavior there is quite surprising, but at least it doesn't load the url to a wrong iframe anymore [14:31:35.0807] Dominic Farolino: hmm, I thought removing mutation events would still block moveBefore. Though that shouldn't block moving to stage 3, only shipping. [14:58:16.0771] here is the css part https://github.com/w3c/csswg-drafts/pull/10865 [14:58:28.0515] and here is the html part https://github.com/whatwg/html/pull/10629 2024-11-08 [16:26:40.0372] smaug: I think mutation events were already removed: https://github.com/whatwg/html/pull/10573. But yes I agree, shouldn't block stage 3. [16:27:34.0109] (Implementations haven't removed mutation events) [16:28:49.0168] * (Implementations haven't removed mutation events, https://github.com/whatwg/dom/issues/305#issuecomment-2306411923) [18:58:57.0817] (for those who care about the document-conformance/authoring parts of the requirements in the spec) https://github.com/whatwg/html/pull/10752 [23:15:46.0286] push-api apparently allows (and enforces in certain cases) wrapping after an equals sign of an attribute. That's a new one. [00:07:19.0684] 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 :) [00:36:54.0430] 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 [00:38:07.0035] keithamus: I also see some minor issues such as wrapping before a closing tag (``) and indentation beyond the start tag on the preceding line that you might want to tackle while doing that? [00:40:38.0508] WPT PR is also out-of-date it seems [00:40:51.0683] annevk: sure, I’m just about to get on the road but in about an hour I’ll update both spec and wpt pr [03:04:25.0020] keithamus: oh I see that in August 27 I also expressed confusion as to how this event could work. That comment was never addressed. [03:05:39.0168] 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... [03:12:46.0535] Found it: https://github.com/whatwg/html/issues/10441 [03:13:41.0337] keithamus: so what I think I'm missing is changes to the `button` element `type` attribute reflection that take that into account [03:14:24.0571] keithamus: in that we want the `type` getter to return `button` when the `button` element has `command` and `commandfor` attributes [03:18:28.0443] It's a bit subtle as the `type` getter can mismatch with the actual state, but that seems okay-ish. [03:23:23.0909] 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. [03:25:20.0653] 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. [03:25:46.0940] So I think behavior-wise it's pretty much what you have, except that it doesn't account for the `type` getter. [03:26:55.0806] so i could have a type submit that isn't a submit button? O.o that seems bad [03:27:05.0427] * so i could have an explicit type submit that isn't a submit button? O.o that seems bad [03:27:06.0777] 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. [03:27:33.0567] * 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) [03:27:53.0302] ljharb: the problem is that `