2025-02-01 [19:38:33.0987] Ok [13:40:40.0907] Domenic or annevk: Sometimes, the HTML spec uses where I would have expected (E.g. 'same-origin fallback flag') Is this described somewhere? [14:13:50.0521] There's some overlap with 'a reference from one algorithm to a parameter of another algorithm', but differences either way. 2025-02-02 [17:27:45.0834] We do use for references from one algorithm to a parameter of another algorithm. A modern example of that is all the references to optional named parameters of https://html.spec.whatwg.org/#navigate . [17:28:12.0341] Same-origin fallback flag looks like an old version of that before we had our modern conventions (which include a at the declaration site and an at the call site) [17:30:20.0555] Separately, HTML has lots of random usage from a former editor that I don't really understand, e.g. missing value default/invalid value default, mutable, etc. [22:51:33.0603] `` // 1. Find the button element (assuming it has the ID "myButton") `` `` const myButton = document.getElementById("myButton"); `` `` // 2. Add an event listener for the "mouseover" event `` `` myButton.addEventListener("mouseover", function() { `` `` // 3. Change the background color using CSSOM `` `` myButton.style.backgroundColor = "yellow"; `` `` }); `` `` `` [23:07:19.0123] `` // 1. Find the button element (assuming it has the ID "myButton") `` `` const myButton = document.getElementById("myButton"); `` `` // 2. Get the user agent string `` `` const userAgent = navigator.userAgent; `` `` // 3. Check if the user agent string indicates a desktop browser `` `` if (/Windows|Macintosh|Linux|X11/.test(userAgent)) { `` `` myButton.addEventListener("mouseover", function() { `` `` // 4. Change the background color using CSSOM if the user is on a desktop browser `` `` myButton.style.backgroundColor = "yellow"; `` `` }); `` `` } `` [15:27:05.0332] Is there a particular reason why you can't call .showPopover() an open modal dialog, but on an open non-modal dialog it works? Seems like it should probably throw in both cases? 2025-02-03 [07:43:19.0299] Are the children changed steps and post-connection steps defined for SVG's `` create a shadow root for the div, or simply insert a document fragment? It feels like this should work for DSD to me, but currently in Chromium, Gecko and WebKit it inserts a document fragment. Ladybird however creates a shadow root. So now I'm wondering who's correct? [01:08:22.0897] I wonder if the difference may be due to Ladybird strictly implemented what’s actually spec’ed [01:08:50.0457] Or maybe in different words that’s the same thing you’re asking [01:09:45.0255] Yeah essentially I'm trying to work out if I should raise a bug with ladybird or with the other 3 [01:10:28.0413] * Yeah essentially I'm trying to work out if I should raise a bug with ladybird or with the other 3. It feels to me and to the person who found the current behaviour like Ladybird is correct with what is expected [01:10:53.0375] * Yeah essentially I'm trying to work out if I should raise a bug with ladybird or with the other 3. It feels to me and to the person who found the current behaviour like Ladybird is correct with what is expected. From a quick glance at the spec ladybird seems right too but I'm only familiar with the surface level of the API. [01:11:18.0552] yes it is [03:05:26.0258] Luke Warlow: doesn't that create a Document with an html root node and parses template into that? Why would that create a shadow tree for the div? [03:07:47.0775] parseHTMLUnsafe creates a new document. I don't think setHTMLUnsafe does? [03:08:36.0781] Luke Warlow: that's step 1 of fragment parsing, afaict [03:09:42.0247] Ah wait yeah just spotted that. Must have skipped over that. I assumed the context element was used more exhaustively than it is. But it looks like it maybe just sets the initial parser state? [03:11:07.0017] Ah but wait then it does append a copy of the context element into the stack. I assume when it later does the replacement that the DSD gets swapped out for a doc fragment because the parent elements don't match? [03:13:02.0464] I don't think the context element gets onto the stack. "the adjusted current node is not the topmost element in the stack of open elements," is why we just insert the template element. [03:15:15.0599] Step 11 here sounds like it does something, but you're right it doesn't seem to actually end up in the stack? https://html.spec.whatwg.org/multipage/parsing.html#html-fragment-parsing-algorithm [03:15:43.0892] Either way thanks! I'll raise an issue with Ladybird and just keep in mind that it needs the container element for context in the source string to parse [03:15:51.0549] Yeah, modernizing the HTML parser would be nice. Lots of implicit nonsense. [03:17:14.0100] * Either way thanks! I'll raise an issue with Ladybird (and WPT) and just keep in mind that it needs the container element for context in the source string to parse [03:18:12.0562] Luke Warlow: attachHTMLShadow() or some such could be interesting, maybe. Would be quite a bit of work though. [08:59:18.0705] keithamus: can you review https://github.com/whatwg/html/pull/11053 please? [10:03:03.0453] > <@annevk:matrix.org> keithamus: can you review https://github.com/whatwg/html/pull/11053 please? LGTM! 2025-02-26 [18:00:00.0022] annevk: I wonder if https://github.com/whatwg/dom/pull/1307 and https://github.com/whatwg/html/pull/10657 fell off your radar [23:12:45.0678] Domenic: I think the former only got updated to address feedback from smaug literally yesterday? [23:13:06.0524] /me looks again [23:13:24.0172] Oh you're right, the trillions of hidden items and other GitHub references confused me [23:14:21.0811] Yeah, hidden items on GitHub is such an issue. I would honestly prefer a plain text view that doesn't do that if the concern is bandwidth. [23:18:51.0469] I recommend making some time to try out https://github.com/dlvhdr/gh-dash when you have a chance. With that you can browse through and view all comments for a PR/issue without needing to un-hide stuff [23:19:29.0258] …among a lot of other really-useful things you can do with it (e.g., review and merge PRs from within it) [23:20:18.0139] Maybe eventually ween yourself off needing to use the GitHub web UI very much at all [23:21:08.0254] I contributed a couple feature patches to that tool so far — and may contribute some more, as I switch to using it for more things [00:52:43.0070] zcorpan smaug any final thoughts on https://github.com/whatwg/html/pull/11053? If not I'm gonna merge it. [01:33:56.0291] > <@domenicdenicola:matrix.org> Oh you're right, the trillions of hidden items and other GitHub references confused me At the very least I really wish they were all using hidden=until-found or details elements so I could find in page them. 2025-02-27 [20:24:26.0411] Psychpsyo: your archeology at https://github.com/whatwg/html/issues/10296#issuecomment-2681769263 is pretty cool. Kudos for doing that. I hope it leads to resolving this decade-old issue in a good way for all involved :) [00:02:38.0321] Domenic: not sure I'll be ready to reply to your new `getImageData()` question later today. I've asked internally, though I would also want padenot to reply. [00:06:40.0478] No problem, thanks for prioritizing it. [00:56:51.0592] And yet another polyfill appears to have poisoned the standards well. This for scoped custom element registries. People never learn. 🫠 [05:30:03.0782] * And yet another polyfill appears to have poisoned the standards well. This time for scoped custom element registries. People never learn. 🫠 [06:19:43.0117] Thank you! I'm still hoping that we can restrict the elements this applies to and maybe re-frame the spec in terms of margin collapsing once again, since that, to me, makes infinitely more sense than the current, convoluted CSS-to-English translation of Firefox's web-incompatible imitation of that behavior. [06:20:07.0926] * Thank you! I'm still hoping that we can restrict the elements this applies to and maybe re-phrase the spec in terms of margin collapsing once again, since that, to me, makes infinitely more sense than the current, convoluted CSS-to-English translation of Firefox's web-incompatible imitation of that behavior. [06:59:38.0096] * Thank you! I'm still hoping that we can restrict the cases this applies in and maybe re-phrase the spec in terms of margin collapsing once again, since that, to me, makes infinitely more sense than the current, convoluted CSS-to-English translation of Firefox's web-incompatible imitation of that behavior. [07:01:04.0777] * Thank you! I'm still hoping that we can restrict the cases this applies in and maybe re-phrase the spec in terms of margin collapsing once again, since that, to me, makes infinitely more sense than the current, convoluted CSS-to-English translation of Firefox's web-incompatible imitation of the behavior. [07:05:13.0566] For the record, Chrome's implementation doesn't happen at the CSS level at all, but when actually laying out the quirky margins [07:05:52.0033] Yes, and so does the one in IE. This is the sensible way to do it, since this is a special case of regular margin collapsing. [07:06:23.0562] Chrome's style sheet has a special unit used only in the UA stylesheet to mark margins as quirky [07:07:17.0322] that took me a while to figure out when I first saw it [07:07:18.0162] That... I mean, yea... kinda not sure if there is a good way to do this. [07:07:18.0560] https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/html/resources/html.css;l=47-48 [07:08:13.0214] So even the chrome way of doing this can't be written out in standard CSS. Fun. [07:42:53.0658] I think `__qem (for quirky em)` came from WebKit. (It's still in WebKit.) [07:44:02.0198] Oops: ``` // This value is used to handle quirky margins in reflow roots (body, td, and th) like WinIE. // The basic idea is that a stylesheet can use the value __qem (for quirky em) instead of em. // When the quirky value is used, if you're in quirks mode, the margin will collapse away // inside a table cell. This quirk is specified in the HTML spec but our impl is different. CSS_QUIRKY_EM ``` [08:44:53.0507] I'd love to know how IE does this internally, but I assume we might never know. Overall, I am almost 100% sure that the original quirk is "any default UA margin can infinitely collapse into the top/bottom of the page and table cells." (IE does collapse into the bottom of the page, but I don't think this ever matters for web compat) [08:46:54.0307] I don't think what IE does matters at this point. CSS_QUIRKY_EM does and fortunately is a knowable thing. [08:57:25.0629] Yea. IE's way would mostly be a curiosity. quirky EM seems like a sensible way to do this. (Maybe not for a standard definition though) [08:57:40.0069] * Yea. IE's way would mostly be a curiosity. quirky EM seems like a sensible way to do this. (Maybe not for a spec definition though) [14:36:38.0609] feels potentially written by llm https://github.com/whatwg/html/issues/10855#issuecomment-2689176726 [14:37:15.0276] perhaps partially [15:17:15.0155] > <@meghanbun:matrix.org> feels potentially written by llm https://github.com/whatwg/html/issues/10855#issuecomment-2689176726 Nah.. this person writes in that style for years now, from before LLM was the thing it is today. 2025-02-28 [18:21:39.0158] annevk (or anyone else who loves answering questions about the URL spec): Not part of a conforming “absolute-URL string” https://url.spec.whatwg.org/#absolute-url-string can never contain any ASCII whitespace, right? [18:25:49.0718] Context is, I’m working on implementing the constraint-validation requirements for `type=url` `input` elements. And I’m hoping to avoid needing to write an actual lexer for “absolute-URL string” — and instead just actually run the URL parser on the URLs, with some preprocessing and post-processing [18:27:29.0421] And it _seems_ like one pre-processing step that’d work is to return not-valid for any strings that contain ASCII whitespace [18:28:54.0925] * annevk (or anyone else who loves answering questions about the URL spec): No part of a conforming “absolute-URL string” https://url.spec.whatwg.org/#absolute-url-string can never contain any ASCII whitespace, right? [18:29:04.0287] * annevk (or anyone else who loves answering questions about the URL spec): No part of a conforming “absolute-URL string” https://url.spec.whatwg.org/#absolute-url-string can ever contain any ASCII whitespace, right? [20:21:05.0757] hmm, given that in https://html.spec.whatwg.org/multipage/input.html#url-state-(type=url), the spec specifically and normatively references [“absolute-URL string”](https://url.spec.whatwg.org/#syntax-url-absolute) and _not_ [“absolute-URL-*with-fragment* string”](https://url.spec.whatwg.org/#absolute-url-with-fragment-string), then that means: if a URL has any fragment at all, then the requirement is that implementations much handle it as an invalid value for `type=url` `input` element (for the purposes of the constraint-validation API)? [20:21:28.0836] * hmm, given that in https://html.spec.whatwg.org/multipage/input.html#url-state-(type=url), the spec specifically and normatively references [“absolute-URL string”](https://url.spec.whatwg.org/#syntax-url-absolute) and _not_ [“absolute-URL-_with-fragment_ string”](https://url.spec.whatwg.org/#absolute-url-with-fragment-string), then that means: if a URL has any fragment at all, then the requirement is that implementations must handle it as an invalid value for `type=url` `input` element (for the purposes of the constraint-validation API)? [21:20:43.0726] I am 95% sure browsers do not implement that... [21:22:08.0860] well that’s the thing [21:22:16.0393] I am implementing it [21:22:32.0464] Attempting to — per the actual spec requirements [21:23:18.0850] So if the requirements don’t actually match what other implementors are interested in, then I guess we need to update the spec [21:24:06.0687] But yeah you’re right — other engines don’t implement it per-spec [21:25:02.0593] And I have not looked at their code, but I strongly suspect that one big reason is that no existing implementations are actually running a lexer to check that “absolute-URL string” requirement [21:25:57.0474] Instead, they’re probably all just parsing the value into a URL, and only returning invalid if they don’t get any URL value back from that [21:26:50.0224] At least I can see that seems to be the case from the tests I’ve run so far — with some dozens of cases from https://github.com/web-platform-tests/wpt/blob/275544eab54a0d0c7f74ccc2baae9711293d8908/url/urltestdata.txt [21:31:04.0681] I’d be happy to just make my implementation match what other engines are doing, and add a comment in our code saying that. But then, we also rightly should have many more tests in WPT for this. And I have tests I can upstream. But if I make the test results match what other engines are doing, then those tests are not actually going to be conforming to the spec requirements… [21:32:46.0057] The existing test for this in WPT at https://github.com/web-platform-tests/wpt/blob/6618dc6e2a580d6d816f7a5b291c016f7a2c0204/html/semantics/forms/constraints/form-validation-checkValidity.html#L30 has exactly one case: the string `abc` [21:32:59.0066] Yeah, I'm just saying if it were me, I would drop implementation work and instead open a spec issue to get this sorted. [21:33:45.0034] ah OK yeah there’s plenty of other stuff we need that I can work on the meantime [21:34:58.0299] (but when I started out on implementing this, it looked to me (naïvely) like it was going to be relatively low-hanging fruit…)) [21:48:16.0105] Made a WPT PR at https://github.com/web-platform-tests/wpt/pull/51011/files with the added tests [21:49:01.0633] Do we currently have a way of hosting/enabling people to run WPT tests from a PR branch? [21:50:37.0019] I kind of vaguely recall seeing something a while back. Like, with w3c-test.org (predecessor to wpt.live) we used to have a thing that created subdirectories for every pull request [21:56:00.0711] I think there might be an existing issue on type=url. It needs something similar to type=email work. [21:56:25.0257] ah OK, I’ll look now [21:59:38.0794] Well, didn’t find it yet. Not in whatwg/html at least [22:27:09.0747] sideshowbarker: can't find it either, please file one? Non-ASCII input in various parts of the URL would also be good to test. Including what ends up getting submitted. [22:27:25.0646] smaug: is it reasonable to ask you to review moveBefore() by Monday? [22:27:48.0034] * smaug: is it reasonable to ask you to review moveBefore() by Monday? (Somewhat arbitrary deadline.) [00:50:43.0330] Raised https://github.com/whatwg/html/issues/11083 [01:50:37.0540] Clear-Site-Data is desperately in need of maintenance... https://github.com/w3c/webappsec-clear-site-data/issues/87 [02:06:35.0958] annevk: I could review it on Monday. (though it feels a bit odd that reviews need to happen fast, while the pr wasn't updated for quite some time) [02:10:30.0334] We should adopt a policy that anybody who abandons a spec — or neglects/leaves it unmaintained over N number of months/years — is barred for life from ever being able to write another spec [02:17:37.0400] smaug: you're right. I didn't want to punish with incremental backoff, but it doesn't have to be done immediately either. I guess I just kinda want it over with myself. [02:17:59.0099] If it's done somewhere next week that's good enough for me. [02:20:09.0549] I want the pr landed too, such a nice feature. It is just that when there is lots of time between pr updates, I need to basically re-review everything in order to remind myself what all it is changing. [02:20:51.0392] Very much same, which is maybe why I want you to review it quickly, but it would also require Dominic Farolino to then update it quickly again. [02:25:41.0096] > <@sideshowbarker:matrix.org> We should adopt a policy that anybody who abandons a spec — or neglects/leaves it unmaintained over N number of months/years — is barred for life from ever being able to write another spec I'm freeeeeeeeeeeeeee [02:34:17.0728] about Client Hints, I added a comment at https://bugzilla.mozilla.org/show_bug.cgi?id=935216#c73 that I hope isn’t out of line. Just an attempt at a heads-up, out of empathy with whoever might wander into trying to implement it next [02:41:10.0551] sideshowbarker: Client-Hints != Clear-Site-Data though [02:41:35.0485] ah [02:42:25.0463] Now I'm pretty certain Client-Hints also has unresolved issues (including some in Fetch), but they're at different URLs. 😀 [02:47:14.0499] /me makes a note to avoid posting issue/bug comments while trying to cook dinner for 5 at the same time… [10:52:00.0241] yeah, don't threaten us with a good time, sideshowbarker [11:00:28.0606] I agree, but I don't think the webappsec chairs are in this channel. Would you reach out to them directly or the wg mailing list?