2023-09-01 [21:49:01.0737] how to fix Insecure CORS Configuration? [00:45:17.0288] Domenic: mind if I reach out to Mike and Artur for that module worker issue? Or perhaps you already have? [00:45:29.0144] annevk: go for it [04:09:58.0042] Luca Casonato: https://github.com/whatwg/html/pull/9668 does Deno need an issue for this? [04:10:25.0657] smaug: I've tried to make the commit title clearer, will use that when landing [04:11:19.0483] thanks. Initially when I just saw the bugmail I thought it was about some script bundling and workers 🙂 2023-09-02 [20:53:09.0810] > <@annevk:matrix.org> Luca Casonato: https://github.com/whatwg/html/pull/9668 does Deno need an issue for this? Nope [22:56:36.0948] > <@annevk:matrix.org> Hey Christine Belzie, I'm not aware of any docs-related issue, but you could scan through https://github.com/search?q=org%3Awhatwg+label%3A%22good+first+issue%22+is%3Aopen&type=issues to see if any of those seems doable; happy to help Hey annevkI’ll do this one: [22:57:34.0695] > <@annevk:matrix.org> Hey Christine Belzie, I'm not aware of any docs-related issue, but you could scan through https://github.com/search?q=org%3Awhatwg+label%3A%22good+first+issue%22+is%3Aopen&type=issues to see if any of those seems doable; happy to help * Hey annevkI’ll do issue 7374. It’s in the HTML repo [23:52:12.0529] Christine Belzie: sounds good, but https://github.com/whatwg/html/issues/7374 appears closed? [04:59:44.0681] HTML tables have a defined schema, table -> tbody -> tr -> td Is there a way for the row to behave like an element, in a way that the row's link can be copied, or opened in a new tab with ctrl+click. [05:00:44.0920] Or is this just a bad UX, and a table row should have a column where the link is in? [05:01:07.0419] * ----------- Or would this just be a bad UX, and a table row should just have a column where the link is in? [07:11:04.0720] vrafaeli: with scripting you can accomplish some if not all of that, but there's no way with just markup. Might be an interesting feature request for CSS to let a row act as the link of one of its columns 2023-09-04 [13:27:50.0156] I have been designing web sites since 1993. I started out with NCSA Mosaic and websites implemented on NCSA httpd. I am tired of being forced to use JavaScript as the only way to implement dynamic functionality on web pages. IMHO Brendan Eich only invented it as a temporary measure. His exploitation of the Java trademark suggests to me that he expected the compiled Java language to eventually replace it, once the appropriate libraries were constructed. Back in the 90s I wrote Java Applets and even taught a course on them. But Java has been removed from all browsers "Because of the removal of older NPAPI plugins on which Java is built on." But that was only one implementation of the Java VM. [13:47:57.0589] > <@vrafaeli:matrix.org> HTML tables have a defined schema, table -> tbody -> tr -> td > Is there a way for the row to behave like an element, in a way that the row's link can be copied, or opened in a new tab with ctrl+click. You can write a script to go to another URL based upon information in the row: trow.addEventListener('click', eventhandler); Remember to set role="link" and to use styles to notify users that it is a link. See https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/link_role for caveats. [16:06:06.0742] > <@annevk:matrix.org> Hey Christine Belzie, I'm not aware of any docs-related issue, but you could scan through https://github.com/search?q=org%3Awhatwg+label%3A%22good+first+issue%22+is%3Aopen&type=issues to see if any of those seems doable; happy to help Hey annevk! :) I want to do this one: https://github.com/whatwg/html/issues/3296 2023-09-05 [02:21:31.0789] Christine Belzie: sounds good, https://github.com/whatwg/html/issues/3296#issuecomment-353047461 still seems relevant there [04:52:49.0186] > <@domenicdenicola:matrix.org> Alexander Kalenik: Did you have a chance to look at https://github.com/whatwg/html/issues/9148#issuecomment-1610989949 ? I would love to get your implementer experience-informed opinion, before I go making changes. uh, sorry it takes so long for me to respond. I have returned to working on navigables implementation for LibWeb and seems like I found another bug https://github.com/whatwg/html/issues/9686. [04:55:05.0062] I will let you know once I've tried to actually implement your suggestion to solve destroy/abort bug. [06:44:50.0215] annevk: there hasn't been any progress on https://github.com/whatwg/html/issues/9469, can you please take a look? [07:21:09.0511] vhilla: thanks for the ping, I'll relay it internally [07:22:21.0193] vhilla: I guess it's not just up to WebKit though, if Chromium and Gecko want to have this specific divide there's nothing really stopping you from working on specifying it, unless Yusuke comes up with a strong reason not to, but I kinda doubt it [09:05:31.0497] So since Ian Hickson worked on HTML, is it correct we added only these new elements: 1. Custom elements 2. slot 3. search ? [09:36:17.0475] zcorpan: posted a while back https://twitter.com/zcorpan/status/1469344438627573761 [09:37:21.0396] but element wise, yes.. tho I guess we completed dialog and had important additions to details and some other good stuff too [09:37:29.0215] * but element wise, yes.. I think so... tho I guess we completed dialog and had important additions to details and some other good stuff too [09:37:47.0351] * annevk: --- zcorpan: posted a while back https://twitter.com/zcorpan/status/1469344438627573761 [10:58:41.0503] /me > <@annevk:matrix.org> So since Ian Hickson worked on HTML, is it correct we added only these new elements: > > 1. Custom elements > 2. slot > 3. search > > ? is curious why you asked? [12:33:22.0021] > <@annevk:matrix.org> Christine Belzie: sounds good, https://github.com/whatwg/html/issues/3296#issuecomment-353047461 still seems relevant there Great! Can you assign the issue to me? It'll let other contributors know that it's been solved. [12:33:42.0802] > <@annevk:matrix.org> Christine Belzie: sounds good, https://github.com/whatwg/html/issues/3296#issuecomment-353047461 still seems relevant there * Great annevk! Can you assign the issue to me? It'll let other contributors know that it's been solved. [15:06:24.0178] > <@bkardell:igalia.com> annevk: --- zcorpan: posted a while back https://twitter.com/zcorpan/status/1469344438627573761 There’s https://platform.html5.org/history/ — but it seems I stopped adding to that at roughly around the same time Hixie moved on 2023-09-06 [18:14:20.0795] > <@chrissycodes:matrix.org> Great annevk! Can you assign the issue to me? It'll let other contributors know that it's been solved. We don't assign issues. Other contributors will know it's been solved when the issue is closed :) [22:23:50.0036] bkardell: came up when talking about `search` and I realized I had no idea [03:59:24.0319] Domenic: https://bugs.chromium.org/p/chromium/issues/detail?id=1475907#c4 - is this right? The navigation event deliberately doesn't fire when traversing to a bfcache'd page? [04:00:59.0283] * Domenic: https://bugs.chromium.org/p/chromium/issues/detail?id=1475907#c4 - is this right? The `navigate` event deliberately doesn't fire when traversing to a bfcache'd page? [04:01:51.0358] No, seems like a bug. There's nothing in the spec that looks at the destination's bfcache status. [04:02:36.0193] That was my reading/hunch too. [04:02:49.0795] It should work, same-origin [15:43:59.0194] Hi folks. [WebDriver BiDi would like to hook in to "run the animation frame callbacks."](https://w3c.github.io/webdriver-bidi/#issue-b2b83ca0) I'm thinking HTML could define a general-purpose extension point for that situation (maybe with a queue of tasks into which a spec like BiDi could push), it it could explicitly invoke an algorithm provided by BiDi. Is there a preference between these two? Or a more appropriate approach that I haven't considered? [15:52:41.0380] [Looks like "Update the rendering" has already been extended with steps to inform other specs of this event](https://html.spec.whatwg.org/multipage/webappapis.html#update-the-rendering) 2023-09-07 [19:10:19.0942] jugglinmike: we prefer explicit callbacks these days, like we've done for all other WebDriver BiDi hooks. [19:10:26.0457] In particular, this helps get the ordering clear. [19:10:55.0245] Not sure what hooks you're referring to that already exist, although it's a long section so maybe I just missed them [19:11:34.0583] Oh you mean the many specific ones, not a generic one. [02:06:10.0160] Hello All, [02:09:02.0795] I am almost done implementing the latest URL Spec in Java and was wondering if the various URL's setters should throw Exceptions when something goes wrong ? I read the specification and didn't find anything on this ? Can anyone shed some light ? Thx a lot [03:24:58.0636] sbastiandev: judging by this note: https://url.spec.whatwg.org/#validation-error whether validation errors throw is left to the user agent [03:28:47.0946] as in, the web platform doesn't throw on validation errors (based on the note, for backwards compatibility), but conformance checkers probably should. Makes sense to me that this is a library/platform decision rather than spec decision. probably some people here with more context though [05:36:54.0153] > <@noamr:matrix.org> sbastiandev: judging by this note: https://url.spec.whatwg.org/#validation-error whether validation errors throw is left to the user agent Thanks for your reply. The main concern though is that you've got cases where the behavior of setting parts versus parsing a url is not consistent in term of reporting failures. For instance parsing a url with a wrong port would fail. However calling url.port = "bad-port-number" would not. But as you said it's probably a library/platform decision. Thank you [05:46:41.0435] sbastiandev: if you see the setter algorithm, those do something and then call the parsing algorithm and some parsing leads to validation errors, which leads back to this note [05:46:54.0317] (setter algorithms) [05:48:00.0107] e.g. "The protocol setter steps are to *basic URL parse* the given value, followed by U+003A (:), with this’s URL as url and scheme start state as state override." [07:57:38.0707] Thanks Domenic ! [08:03:36.0835] Can you define a custom conversion from arbitrary ES types to your specific IDL type? Like, if I have an interface, and I want methods that accept objects of that interface type to also accept a handful of other types that my native interface type can be constructed from, how can I do this? Do those methods have to accept `any`, and then I just write their dfn as delegating to an internal conversion algorithm that I provide? Or can I just accept `MyInterface` types, and specify some some conversion algorithm that gets invoked whenever anything is passed in as a `MyInterface`? [08:04:22.0617] I think I'm interested in simulating something like the WebIDL Promise type, which accepts all thenables but also native Promises, IIUC [08:05:18.0292] (Context is for https://github.com/domfarolino/observable, where it'd be nice for methods that accept an Observable to also accept Async Iterables, that Observables can be constructed around to wrap) [08:07:30.0329] Dominic Farolino: define ObservableInit as a union of Observable and whatever syntax we have for async iterables (maybe needs to be added?) and make people use that? [08:07:56.0931] Dominic Farolino: Promise is an ES type and therefore gets its own to-and-from ES conversion, but you don't have that if you define an interface [08:11:16.0577] Yeah it's the latter part of "and whatever syntax we have for async iterables" that I'm stuck on. We of course have syntax to make an interface async iterable, but I'm not sure that's usable from within a union... perhaps it does need to be added though idk [08:11:43.0499] (Same goes for normal iterable I think) [08:16:03.0313] (Or no, I guess maybe sequence can be used for iterable) [08:41:35.0033] Dominic Farolino: yeah, you want `async sequence` or some such [16:08:06.0080] Dominic Farolino: I think you need `object` or `any` with manual steps. In particular, overloading on promises is basically impossible in Web IDL by design. And this would be the second method on the platform to consume async iterators, so you'd need to add something to Web IDL to support that, which I'm not sure is worth it. [16:08:29.0176] Oh, but, if this is just for `Observable` + async iterable overloads, then maybe that's worth doing [16:08:36.0563] I thought this was just for `Observable.from` which is very special. 2023-09-08 [22:32:38.0489] Or maybe it would be cleaner if we made `Observable` a special type in Web IDL, so you wouldn't be able to return async iterables, but had to instead return an Observable or Stream, which I think is what we would (always?) want. [01:59:57.0862] Yeah I came around to that conclusion actually [02:00:05.0861] Well or something like it [02:00:20.0917] https://github.com/domfarolino/observable/pull/60#issuecomment-1710883833 [15:02:54.0067] I am working on implementing navigation, and I'm struggling to determine if the specification explicitly defines that the population of history entries initiated for nested navigables should be aborted after parent navigable navigates to another page. For example, the following scenario currently fails with an assertion: 1. Both the nested navigable and the parent navigable navigate to a new URL. 2. The population of SHE for the parent navigable finishes first. 3. "finalize a cross-document navigation" for the parent navigable replaces the SHE (assuming historyHandling is set to "replace"). 4. The population of SHE for the nested navigable navigation concludes. 5. "finalize a cross-document navigation" for nested navigable fails to locate the SHE to be replaced (assuming historyHandling is "replace") because it was located in the nested history of the parent navigable SHE that was replaced earlier. Does that sound like a specification bug or I am missing something? 2023-09-09 [17:35:21.0749] Coincidentally, I also plan to implement the navigation soon Though it's really dense (the intro paragraph literally calls it "the dragon's maw") so I'm 🌈 procrastinating 🌈 [06:16:26.0635] Off the top of my head on a weekend, I thought there was a step early in navigation/traversal that would abort any current loads in the top-level traversable and its descendants? [09:12:06.0165] Domenic: I think so, there was a concept of maturing and a new navigation would abort immature navigations or some such [09:27:43.0932] > <@domenicdenicola:matrix.org> Off the top of my head on a weekend, I thought there was a step early in navigation/traversal that would abort any current loads in the top-level traversable and its descendants? As I understand it, if the navigation that is currently loading needs to be canceled, we need to set its "ongoing navigation" to something other than the navigation ID. I would expect this to happen during the "apply the history step" process, but from what I've seen, it only takes care of "changing navigables". [09:31:38.0868] > <@annevk:matrix.org> Domenic: I think so, there was a concept of maturing and a new navigation would abort immature navigations or some such yes, I would expect something like that to happen but haven't yet found this in the spec [09:32:12.0196] Hmm, did that get removed in the navigation refactor? [09:33:26.0687] Step 11 of https://html.spec.whatwg.org/review-drafts/2022-07/#navigate has it. So if it's not there now it's a regression. Pretty bad one. [09:36:18.0707] It's still there. Step 17. https://html.spec.whatwg.org/#navigate [09:39:02.0479] right, changing "ongoing navigation" means canceling any navigation that hasn't been finished. but should we also do that for all child navigables of a navigable that navigates? [09:41:18.0334] * right, changing "ongoing navigation" means canceling any navigation that hasn't been finished. but shouldn't we also do that for all child navigables of a navigable that navigates? [09:42:31.0965] I guess descendants might never have been covered. I guess that can happen with bfcache? [09:43:07.0662] Oh wait. I think I see now. Yeah hmm, not sure. [09:44:29.0378] Recalling stuff from long ago now... I think that ought to be covered by canceling all the fetches for the fetch group, but we never got around to specifying that well. [09:56:28.0463] Step 20.3 should take care of descendants [09:59:27.0016] https://html.spec.whatwg.org/#abort-a-document #2 is a bit lacking in terms of what it means to "cancel any instances of fetch", I'd be happy to fix this as part of `fetchLater`, didn't it use to call "terminate a fetch group" before? [10:02:12.0838] I think there was also disagreement about the point in time that got invoked where Fx might have been more aggressive? Would benefit from tests [10:02:39.0527] Fx? [10:02:52.0222] Ah Firefox [10:07:20.0029] > <@domenicdenicola:matrix.org> Step 20.3 should take care of descendants Oh, right. Now I see, thank you! [10:08:10.0246] Not sure we have the right thing for traversals though, to be honest. (E.g. if your entrypoint is "traverse the history by a delta".) [10:08:36.0817] Hmm maybe step 8.3? https://html.spec.whatwg.org/#apply-the-history-step [10:09:21.0781] Anyone already in Sevilla? I'm flying in from Madrid shortly. [10:20:47.0489] I'm here, and I sat next to Olli on the plane :D [11:05:46.0085] > <@domenicdenicola:matrix.org> Step 20.3 should take care of descendants hmm, I am looking at step 3 in https://html.spec.whatwg.org/#abort-a-document: "Set document's navigation id to null.". shouldn't it be "ongoing navigation" of a navigable instead? [11:07:10.0705] Oh what happened there... I think I tried to unify those concepts, and maybe failed? [11:08:31.0266] Please file an issue... eek 2023-09-10 [17:16:36.0243] Hi everyone! I made my first PR: https://github.com/whatwg/html/pull/9714 Can someone review it for me? [05:46:50.0094] Domenic: just came across https://github.com/python/cpython/issues/102153. Seems like URL security research is still going strong. [05:48:36.0703] Eh, ecosystems which aren't using the URL Standard seem hopeless anyway [05:50:17.0991] That's pretty close to one of the comments there from a long term maintainer. That they probably should have added a WHATWG-compliant package to std. [05:50:42.0770] I hope they do it now, not sure they have. No time like the present. [05:52:02.0841] Yeah seems like there's some fun drama in the hidden comments [05:54:49.0029] Ah but the RFC partisans come out later in the thread, sigh [05:57:36.0369] The curl author unfortunately seemed very dismissive of the URL standard as well in a related blog post [05:58:38.0956] I still find that so hilarious... his whole thing is that he thinks `http://` is pure, `http:///` is necessary for compat, but how dare the WHATWG accept **more than three** slashes, that's just craziness. [05:59:19.0106] Yeah, whenever curl encounters some kind of compatibility problem it turns out that following the URL standard would have helped, but following the URL standard doesn't compute for him so the URL standard is at fault. [05:59:38.0286] I tried to understand it for a while, but gave up. [06:09:21.0649] He's part of a larger group of people on social media that have the ability and experience to influence and improve web standards for everyone, but they rather complain about the status quo. Even when they know and could reach out to the people involved. [06:10:09.0780] (And yeah, they bother me a little bit. 😅) [07:13:36.0609] Domenic: "HTML-parse a URL", "encoding-parse a URL", something else? [07:14:18.0482] If it's only for use with `Document` objects, or maybe even `Node`s, I like "HTML-parse". [07:14:19.0847] Domenic: the idea would be that the current algorithm becomes a sibling to a "parse a URL" that doesn't take encoding into account that we'd promote people to use that need some kind of document/environment base URL [07:14:47.0313] Domenic: XMLHttpRequest and xml-stylesheet will use the legacy algorithm [07:14:59.0264] Maybe encoding-parse is best then 2023-09-11 [03:41:11.0736] "activated" isn't a bad name for `fetchLater()` [07:38:27.0604] https://github.com/nodejs/node-v0.x-archive/pull/1580 via https://tantek.com/2011/238/b1/many-ways-slice-url-name-pieces [07:38:40.0266] That thread is the inspiration for the URL Standard logo 2023-09-13 [11:43:47.0968] I'm looking into StructuredSerializeInternal for Ladybird, and steps 22 and 23 are tripping me up. From looking into blink, it seems like they defer to v8 for the serialization steps, in v8::ValueSerializer. And v8 seems to encode all the data about whether an object (a "receiver") is a well known ES object or ES prototype in a tag field. But LibJS doesn't do that, we just have a bunch of classical c++ inheritance. Like there's no "IsExotic()" function I can call. Do all the other engines do this type of tagging of JS objects so that those two catch-all steps are trivial and/or fall out of handling the known object types? [11:45:42.0432] There's certainly no ECMAScript abstract operation I can call to say "is this a plain old object" (I think?) [12:05:39.0319] the prose "is an ordinary object" is how 262 does it. [12:06:14.0792] * the prose "is an ordinary object" is how 262 does it (in a condition, or assertion, or parameter/return type) [12:10:40.0901] Aha, there's like 40 or so objects in the spec that say "such and such object: - is an ordinary object" [12:13:46.0857] But I can't clone all of those. Like, no promise, no weakmap, no Finalization registry, no Arguments, ... [12:21:33.0418] Oh lovely. If I create a new RegExp(".", "") and try to structuredClone its __proto__ property, Firefox says "can't clone RegExp.prototype", and Chromium says "here's your object" [12:24:11.0578] Safari refuses to clone it too [12:34:24.0984] Step 22 excludes the ones you're worried about [12:35:29.0891] Right.. the best idea I've got for that step at the moment is checking whether my JS::Value is an object and it's class name is "Object" 😅 [12:35:32.0042] I do suspect the other two engines also do object type tagging, as it seems helpful for various optimizations [12:36:52.0696] Yeah, Andreas was brainstorming a radical idea where we create custom vtables to check whether properties/methods are overridden and optimize based on that. But it seems overkill if I just want to get message serialization up and running to implement Workers properly [12:38:15.0453] Eh. I'm sure some WPT tests for this and I can clean it up later 2023-09-14 [00:29:08.0804] Meeting minutes: https://docs.google.com/document/d/1V6_s_VsaWcI9J-ZATbIKKijn59JbVmRMsHXYyH29sho/edit [00:34:32.0360] If folks are interested in attending, the meeting information can be found at https://www.w3.org/events/meetings/efdf2435-c675-41ea-9af2-9fa6443e504c/ [00:34:58.0317] Are any break times known in advance? [00:35:09.0161] Sevilla lunch time perhaps? [00:36:07.0375] hsivonen: https://github.com/whatwg/meta/issues/284 has the agenda, breaks are between the items [00:36:16.0398] Thanks [00:36:28.0503] So the first break would be at 11. We haven't started yet though. [00:36:41.0542] * So the first break would be at 11AM in ~ 1.5h. We haven't started yet though. [00:39:17.0821] Can remote folks hear us ok? [00:40:52.0409] Yup [00:40:58.0747] I can hear folks in the meeting room [00:41:16.0757] https://whatwg.org/code-of-conduct [02:39:58.0532] https://docs.google.com/document/d/1V6_s_VsaWcI9J-ZATbIKKijn59JbVmRMsHXYyH29sho/edit minutes for those who want the link [02:55:51.0140] https://w3c.github.io/aria/ still has 1.3 [03:05:09.0602] issue about this topic: https://github.com/openui/open-ui/issues/571#issuecomment-1696637459 [03:12:38.0239] https://github.com/openui/open-ui/issues/787 [03:12:44.0137] https://github.com/openui/open-ui/issues/552 [03:13:05.0585] https://github.com/w3c/csswg-drafts/issues/9284 [03:15:01.0938] we've had this in css for a long time, but irrc there were concerns around it https://drafts.csswg.org/css-images-4/#funcdef-element [03:19:13.0926] current issue: https://github.com/whatwg/html/issues/9373 [03:30:29.0961] mfreed: one minor suggestion, maybe `lightclose` so we don't introduce a second term for closing [03:36:24.0416] fwiw I've been calling the opposite of 'light dismiss' 'explicit dismiss' , might be another word we could opt for as the opposite of light close / dismiss [03:53:08.0302] "Everything is a lot." — annevk [03:58:40.0573] Hidde de Vries: I would not mind `implicitclose`, I don't think we want "dismiss" as a novel term as it won't be immediately recognizable as "close" to all people [03:59:05.0807] Hidde de Vries: although `lightclose` and `softclose` seem easier to spell, which is another consideration [05:28:28.0151] Is there a joint meeting currently ongoing with CSS? In the CSS Zoom, I don't see the meeting room on the call and I can't hear any sound. [05:28:48.0700] we haven't started yet [05:28:59.0382] Yeah, people are walking into the room nowish [05:29:06.0502] OK [05:32:20.0537] Zoom link for the joint session with CSSWG: https://w3c.zoom.us/j/7729314923?pwd=YVhPRzNvQmdNVDF2RjFYMzdyMXB4UT09 [05:32:58.0516] The camera is still off, correct? [05:37:42.0090] Guess the answer was no, and that I needed to restart Zoom. [05:38:24.0419] So we are using IRC now? Can someone give me the link? [05:39:59.0578] Thanks [05:41:58.0831] https://irc.w3.org/ [05:42:01.0679] #css on irc.w3.org [05:52:43.0305] Hmmmm, if we want to have an attribute that always outputs a particular interface type from the getter, but wants to *accept* a dictionary type for the setter, is that at all possible? [05:53:31.0179] It looks like the answer is no, dictionary types aren't allowed in an attribute type, since the implication is that the attribute type is both the getter output and the setter input (and you can't use dictionaries in output types) [05:54:05.0056] (I suspect the answer is that, right now, it's required to type the attribute as `any` and handle the conversions by hand.) [05:56:04.0368] TabAtkins: IDL has an open issue to split getters and setters (plus maybe have convenient syntax for when they're the same); we should still do that [05:56:21.0634] ah, cool. so "no, but later yes" [05:56:28.0883] hai [06:49:35.0542] zcorpan: https://github.com/w3c/csswg-drafts/issues/9301#issuecomment-1719284356 [08:29:03.0934] TIL `document.open(); document.close()` is a "turn off mutation events" flag in Chrome/Safari. [08:42:53.0044] That is interesting. I wonder what is the historical reason for that. [08:55:41.0291] The specification requires flipping it on and then off. And maybe they just forgot to turn it on again? [09:05:00.0452] I think the specification is more recent though [09:06:31.0438] Ah, no, that part was untouched in the rewrite https://html.spec.whatwg.org/commit-snapshots/c9e804f04d03a0658bfa689cb0f368a4d2e37936/?C=M&O=A#dom-document-open [09:07:21.0238] Firefox doesn't quite follow the spec either, it turns them off until `document.close()` turns them back on, instead of the spec which requires turning them off just for the removal step. [09:07:59.0147] (or in the new spec, the "replace all" step) [13:55:09.0500] how did you test that? Note, all the events listeners are supposed to be removed [15:21:46.0549] ah, it is a bit different. Listeners added after document.open() are called, if one modifies the DOM using normal methods, but .write() itself doesn't seem to notify DOM side, so no events are fired with .write(). 2023-09-15 [20:54:21.0178] Ah that is correct, because the parser doesn't call mutation events. [23:20:29.0110] thank you to all the note takers of yesterday's WHATWG sessions. was very easy to catch up on the stuff I missed 🙏 [02:36:57.0902] Joint session with a11y is starting. Minutes are still at https://docs.google.com/document/d/1V6_s_VsaWcI9J-ZATbIKKijn59JbVmRMsHXYyH29sho/edit [02:39:27.0558] Slides are here: https://github.com/whatwg/meta/issues/284#issuecomment-1720877381 [02:52:45.0764] do we have a generic term for the combination of a storage partition, network cache partition, etc.? as seen in ephemeral sessions in most implementations, for example. [02:54:19.0401] Sam Sneddon [:gsnedders]: we have a URL: https://privacycg.github.io/storage-partitioning/ [02:54:35.0328] I personally prefer "state partitioning", but I didn't actually rename all the things [03:01:11.0739] a quick skim makes it sound like a "storage partition" is more than just that, it's more like (isPrivate, profile, site, origin) etc.? [03:05:11.0889] like I guess I want something that covers (isPrivate, browserProfile), and then within that storage area you have further partitions (per site, etc.)? [03:11:56.0876] Sam Sneddon [:gsnedders]: I see, https://infra.spec.whatwg.org/#user-agent made an attempt at that particular distinction [03:12:19.0394] Sam Sneddon [:gsnedders]: not sure it has everything you need, Jeffrey Yasskin might be able to help [03:12:45.0293] Sam Sneddon [:gsnedders]: Yeah, I was trying to say that different profiles are entirely different user agents. [03:12:57.0354] And then the user agent has various storage partitions. [03:13:17.0265] Even if they co-exist in a single browser UI process? [03:13:32.0410] Because that gives you multiple UAs in a single browser process, which seems… wild, terminology wise. [03:14:27.0418] Yes, because the policies that control them could be very different, and no web-side information should flow between them. [03:15:13.0398] It's a spec construct, kinda like we abstract process boundaries into "agent clusters". So look at the observable implications, rather than assuming things about process boundaries. [03:16:26.0402] It's also totally possible that I overlooked a bigger problem with that arrangement, so feel free to point that out. :) [03:17:11.0788] (The context here is wanting to be able to have some control of, uh, user agents within an implementation under WebDriver BiDi. Which probably means refactoring a lot of the terminology in that spec.) [03:17:58.0641] I think for WebDriver BiDi we're going to have to clarify when we're talking about the local end implementation, the remote end implementation, any intermediary node implementations, and the implementation [infra]. [03:18:14.0329] Cool, yeah, I wasn't thinking about the WebDriver implications when I wrote that. [03:19:45.0856] Does WebDriver want to make a single connection that covers multiple profiles? I would have expected that you'd make a WebDriver connection to a single profile, and so its spec could talk about connecting to an Infra user agent. [03:20:04.0888] That is what the current WG discussion is about. 🙃 [03:20:21.0618] Do you want me to come over? [03:20:41.0349] [vaguely threatening] [03:20:46.0041] lol [03:20:50.0138] You're a bit too late. And probably mostly this is just a spec text question, rather than worthwhile having in the WG? [03:21:39.0905] SG. Yeah, I hope the Infra term helps the WebDriver spec make all the relevant distinctions, and that any necessary spec changes actually make useful clarifications. [03:21:44.0418] (CDP has this ability, and Puppeteer would like this to be possible with WebDriver BiDi, because it provides a decent performance win to avoid having to create a many new browsers while being able to run tests in parallel largely isolated.) [03:42:51.0448] From the in-person meeting: https://arasaac.org/ and https://www.blissymbolics.org/ [03:45:15.0624] Oh, and https://www.w3.org/WAI/adapt/ [03:49:16.0370] https://github.com/w3c/adapt/issues/240 [03:57:23.0744] sorry where is the queue maintained? [03:58:32.0226] In the google doc. [03:58:49.0034] I put you on it. [04:08:35.0273] Captured the steps for SFNSP APIs, hopefully this address some of the concerns raised: https://github.com/whatwg/html/issues/5326#issuecomment-1721091809 [04:09:02.0551] AFAICT, the gap analysis does not compare with IPA directly, so it's an exercise to the reader to see what requirements IPA covers. [04:09:09.0416] Or am I missing something? [05:47:32.0161] https://github.com/whatwg/meta/pull/295 If you want to be on the perf team, please say so [05:48:01.0309] * https://github.com/whatwg/meta/pull/295 If you want to be on the perf team, please say so (and share your GitHub ID) [07:15:22.0554] https://github.com/WICG/scheduling-apis/issues/67 [07:32:28.0977] https://github.com/whatwg/html/labels/agenda%2B [08:24:34.0471] https://github.com/whatwg/html/issues/4500 [12:10:48.0055] annevk: I forgot to ask you about this at TPAC - do you know whether Safari provides some opt-in/opt-out mechanism for Reporting API? 2023-09-16 [07:44:02.0228] sefeng: I don't know [09:16:15.0374] Hey guys! I've question... Do you know if Html 6 exists? 2023-09-18 [23:18:11.0707] Nope. HTML has moved towards a so-called "living standard" model. Implementors are supposed to continuously watch and keep up the HTML standard as is it evolves. The barrier is that pull requests to the HTML standard are gated by a rule that at least 2 of 3 major web engines (gecko, blink, webkit) need to agree and implement. [23:18:41.0640] apropos, now that I visit html.spec.whatwg.org again, I also have a question -- what's special about the "Version for Web Devs" linked at the topo f the spec? [23:19:14.0288] * apropos, now that I visit html.spec.whatwg.org again, I also have a question -- what's special about the "Version for Web Devs" linked at the top of the spec?.... Nevermind there's an "about" section 🤦‍♂️ [01:04:41.0012] Adam Rice: rs for https://github.com/whatwg/websockets/pull/51? [01:06:15.0951] (Or zcorpan / foolip / sideshowbarker.) [01:06:48.0443] annevk: approved but not merged [01:07:01.0767] Well now it is :D [01:08:12.0315] Thanks! [02:33:43.0351] Panos Astithas: the next HTML spec triage meeting won't be on Thursday, right, but in 3 weeks? [03:12:53.0451] Dominic Farolino: let me know if you want https://github.com/w3c/csswg-drafts/pull/8759 merged [04:49:50.0807] sideshowbarker: if you have tryjob access aka permission to do CQ+1, then i can request goma access for you. do you have tryjob access? https://chromium.googlesource.com/infra/goma/client/+/HEAD/doc/early-access-guide.md#Please-wait-for-invitation-from-Google [04:52:44.0518] jarhar: making progress on https://github.com/whatwg/html/pull/8467#issuecomment-1693607442 would be great, it'd unblock WebKit working on it [04:55:09.0120] sure thing, ill try to work on this hopefully today or this week [05:12:41.0842] littledan: not sure if you're still interested in doing more with text and canvas, but perhaps helping with ensuring existing issues such as https://github.com/whatwg/html/pull/5826 get resolved would help pave the way there; if we can't even get what little text support we have today to work well I'd be rather worried about anything more complex than that [07:41:27.0607] Thanks, sounds like a good starting project. I will see if we can get started on this in January 2023-09-19 [19:17:29.0580] jarhar: The http://wpt.live/html/semantics/forms/the-button-element/button-submit-remove-children.html times out in WebKit because (as far as I can see) the `load` event never fires at the iframe that’s the target of the form action in that test. Any clue as to why the event never fires? [19:17:38.0428] * jarhar: The http://wpt.live/html/semantics/forms/the-button-element/button-submit-remove-children.html test times out in WebKit because (as far as I can see) the `load` event never fires at the iframe that’s the target of the form action in that test. Any clue as to why the event never fires? [19:24:31.0328] hmm, the fact that im not seeing a 404 page in the iframe makes me wonder if webkit legitimately fails this test [19:25:21.0106] i wrote this test in response to one of many regression bugs that were filed when i did a refactor to form submission [19:26:17.0700] i wrote it here: https://chromium-review.googlesource.com/c/chromium/src/+/1983547 [19:26:31.0581] I see [19:27:52.0067] lol this was really complicated, but i suppose you could try implementing this patch in webkit to see if it makes the test pass [19:29:10.0587] Yeah I'll try it I guess [19:32:09.0980] This is the only complete fail in WebKit in https://wpt.fyi/results/html/semantics/forms/the-button-element — so, would be nice to make it all go green [19:33:06.0712] that said, there is also https://wpt.fyi/results/html/semantics/forms/the-button-element/button-click-submits.html, which has a test that fails both in Blink and WebKit (but not in Gecko) [20:29:39.0868] OK, ported that patch but in WebKit, still timing out anyway. [20:30:11.0881] so I guess for now I’ll put this test on the back burner and look at it more again some time later [23:53:10.0455] Domenic: can you review the encoding-parse a URL refactor? [23:53:26.0420] Would be nice to unblock some of the follow-up work [00:35:24.0687] zcorpan: regarding the media/supports thing, I felt it was a bit inconsistent that in CSS those are separate @ rules and in the link element they are both folded into the `media` attribute. perhaps there's a more elegant solution? [00:36:56.0169] Noam Rosenthal: perhaps. We want it to fail closed, so that the stylesheet isn't applied in legacy browsers. (But maybe the importance of this property is debatable, since it's temporary and we have faster update cycles now compared to, say, a decade ago) [00:37:34.0820] ... I would expect it to be in a separate cssSupports attribute, and deal with legacy in a way that's a bit more consistent with the meaning of the attributes [00:39:25.0425] Ways to fail closed other than stuffing it in `media` (and still work in `head`): change `rel` to something else (seems not so elegant long term), use `type` attribute (should ideally be possible to not have to write `text/css` since we made that optional) [00:41:37.0425] Maybe we can use a new attribute and in the transition period people can use `media="not all"` and change that with script (or use other rel/type to avoid the download) [00:41:42.0851] For now there is a convenient way to do this: ``` ``` I wonder if making the media attribute inconsistent is worth it [00:42:01.0915] good point [00:42:06.0442] I didn't quite get if adding this as a link provides anything material [00:42:47.0456] It might be loaded earlier by the speculative parser. Not sure if all browsers speculatively load `@import`s [00:43:03.0905] they don't in chrome AFAIK [00:45:12.0923] I think adding a `rel=css` or `rel=style` which can take `layer` and `cssSupports` attributes is not that bad, and when everyone supports layers we can make them aliases of each other [00:46:56.0364] I mean it's not that pretty but it's at least straightforward in a way [00:47:40.0905] I don't like adding alias `rel`s, but I'm warming up to just adding `supports` attribute and let it fail open in legacy. Use `style` element or script hack if you need to fail closed [00:48:29.0212] The linked stylesheet can repeat the `@supports` too if you can control what it contains [00:49:18.0371] yea that's probably safer, you use the supports attribute as an optimization to avoid loading the link at all rather than as a way to not apply the CSS [00:55:29.0145] At https://html.spec.whatwg.org/multipage/semantics.html#standard-metadata-names:meta-color-scheme, the spec normatively states this: > _There must not be more than one `meta` element with its `name` attribute value set to an ASCII case-insensitive match for `color-scheme` per document._ But then later has this non-normative note that says this: > _Because these rules check successive elements until they find a match, an author can provide multiple such values to handle fallback for legacy user agents. Opposite to how CSS fallback works for properties, the multiple meta elements needs to be arranged with the legacy values after the newer values._ So, that note seems to conflict with the normative requirements — by implying that using multiple elements is OK (or even sort of a best practice). [00:55:45.0705] * At https://html.spec.whatwg.org/multipage/semantics.html#standard-metadata-names:meta-color-scheme, the spec normatively states this: > _There must not be more than one `meta` element with its `name` attribute value set to an ASCII case-insensitive match for `color-scheme` per document._ But then later has this non-normative note that says this: > _Because these rules check successive elements until they find a match, an author can provide multiple such values to handle fallback for legacy user agents. Opposite to how CSS fallback works for properties, the multiple meta elements needs to be arranged with the legacy values after the newer values._ So, that note seems to conflict with the normative requirements — by implying that using multiple elements is OK (or even sort of a best practice). [00:56:26.0186] * At https://html.spec.whatwg.org/multipage/semantics.html#standard-metadata-names:meta-color-scheme, the spec normatively states this: > _There must not be more than one `meta` element with its `name` attribute value set to an ASCII case-insensitive match for `color-scheme` per document._ But then later has this non-normative note that says this: > _Because these rules check successive elements until they find a match, an author can provide multiple such values to handle fallback for legacy user agents. Opposite to how CSS fallback works for properties, the multiple meta elements needs to be arranged with the legacy values after the newer values._ So, that note seems to conflict with the normative requirements — by implying that using multiple elements is OK (or even sort of a best practice). (There’s also a grammar error in the note.) [01:01:23.0166] The HTML spec text doesn’t explicitly state that the `color-scheme` value can be an ordered list of keywords — instead it just says, “The value must be a string that matches the syntax for the CSS '[`color-scheme`](https://drafts.csswg.org/css-color-adjust/#color-scheme-prop)' property value” — where `color-scheme` is a link/reference to the normative CSS definition for the property value (which says the value is _“the keyword `normal`, or an ordered list of specified color scheme keywords”_ [01:02:23.0706] So, maybe that note about using using multiple elements was written without an understanding that the value could be a _list_ of keywords rather than a single keyword? Regardless, the note seems wrong. [01:09:30.0082] Noam Rosenthal: commented in https://github.com/whatwg/html/issues/7540#issuecomment-1725024079 [01:10:25.0571] sideshowbarker: if you use a list and you use an unsupported keyword, isn't the whole list ignored? [01:10:28.0584] * At https://html.spec.whatwg.org/multipage/semantics.html#standard-metadata-names:meta-color-scheme, the spec normatively states this: > _There must not be more than one `meta` element with its `name` attribute value set to an ASCII case-insensitive match for `color-scheme` per document._ But then later has this non-normative note that says this: > _Because these rules check successive elements until they find a match, an author can provide multiple such values to handle fallback for legacy user agents. Opposite to how CSS fallback works for properties, the multiple meta elements needs to be arranged with the legacy values after the newer values._ So, that note seems to conflict with the normative requirements — by implying that using multiple `` elements is OK (or even sort of a best practice). (There’s also a grammar error in the note.) [01:11:00.0491] * The HTML spec text doesn’t explicitly state that the `color-scheme` value can be an ordered list of keywords — instead it just says, “The value must be a string that matches the syntax for the CSS '[`color-scheme`](https://drafts.csswg.org/css-color-adjust/#color-scheme-prop)' property value” — where `color-scheme` is a link/reference to the normative CSS definition for the property value (which says the value is _“the keyword `normal`, or an ordered list of specified color scheme keywords”_) [01:12:14.0353] > <@zcorpan:mozilla.org> sideshowbarker: if you use a list and you use an unsupported keyword, isn't the whole list ignored? Not sure. I think it depends on what the CSS parser does and what the CSS spec requires UAs to do [01:12:24.0560] oh no, the grammar allows custom-ident [01:17:15.0777] so parsing would only fail if you use e.g. a function. which seems unlikely to be added, so I think we can just remove the note [01:18:47.0656] > <@zcorpan:mozilla.org> so parsing would only fail if you use e.g. a function. which seems unlikely to be added, so I think we can just remove the note OK, I reckon I’ll open a PR [01:19:23.0849] maybe even the processing could stop after the first meta element even if it fails, but also, if the current processing is implemented already, not worth it to shake [01:23:49.0225] yeah [01:43:07.0824] zcorpan: another option for backwards compat if we really want the link element, is to have a new attribute like `cssConditions` or so that can accept a `@media ... @supports` style syntax and overrides `media`. So you use `media="not all"` like you suggested before, and in browsers that supports this attribute you'd get the media+supports check (plus whatever check we allow in the future) [01:46:09.0885] Noam Rosenthal: interesting idea. personally I prefer the html attribute syntax [01:47:35.0032] also would be surprising that `media` is ignored here: ```html ``` [01:47:57.0636] we can ignore it only if `cssconditions` contains media [01:48:05.0184] * we can choose ignore it only if `cssconditions` contains media [01:48:59.0240] seems more convoluted to explain than `supports=""` [01:49:27.0680] + more typing [01:49:50.0041] * plus more typing [01:50:07.0002] (didn't know starting a line with + made a bullet list) [01:50:20.0320] sure, but also has some pros as it lets us use the link element earlier [01:50:39.0558] not sure if it's worth it but thought I'd try to bring an alternative [01:52:58.0813] Maybe we can solve that socially. have a comment in the spec for import conditions to also change the link element [01:56:13.0824] I don't follow :) [02:10:28.0888] Noam Rosenthal: you said " it lets us use the link element earlier", but that's only true if `@import` gains a new feature first, instead of the `link` element gaining that feature first, or they gain it at the same time [02:11:45.0949] zcorpan: gotcha, yes [03:05:38.0790] > <@annevk:matrix.org> Domenic: can you review the encoding-parse a URL refactor? I'm on vacation through 2023-09-26 [04:33:45.0353] Domenic: ah, thanks for letting me know, I'll ask another editor as I addressed all your feedback [04:34:07.0100] Domenic: and I guess you already let me know, hope the cities are enjoyable :-) [04:36:17.0802] zcorpan: foolip: interested in reviewing https://github.com/whatwg/html/pull/9719? [04:40:42.0026] annevk: I can [05:04:38.0593] miketaylr: curious rename [05:19:39.0845] after porting the patch, did the iframe show anything at all like a 404 page? [06:05:31.0679] I did not [06:06:15.0152] It’s possible that I didn’t fully port it correctly — but it’s a relatively simple change, so I feel like I got it right [06:06:48.0353] if I had muffed it in some, I’d expect that it’d probably cause a crash [06:06:56.0382] well, or not compile at all [06:07:03.0490] * well, or not compile at all to begin with [06:08:25.0288] lol yeah, TIL that `/nick changes are global, but there's a `/myroomnick` for per-name shenanigans 🙈 [06:08:36.0352] * lol yeah, TIL that `/nick` changes are global, but there's a `/myroomnick\` for per-name shenanigans 🙈 [06:08:41.0571] * lol yeah, TIL that `/nick` changes are global, but there's a `/myroomnick` for per-name shenanigans 🙈 [06:49:29.0713] I'm pretty sure he was impersonating the visual effects technician, Mitchell Baker from Kraken: Tentacles of the Deep from 2006. [14:16:33.0976] When ORB blocks a response, you can't even reach for the _internal response_ and get at it, right? Is the response blocked from even reaching _that_ stage annevk ? 2023-09-20 [23:33:10.0538] Dominic Farolino: right, it results in a network error [04:19:49.0209] In the WPT test at https://github.com/web-platform-tests/wpt/blob/db6e5032915eb0dcb1d8b8b249488055378245fd/html/webappapis/dynamic-markup-insertion/opening-the-input-stream/url.window.js#L28, what exactly about `childDoc` causes it to be not fully active? [04:20:09.0719] * In the WPT test at https://github.com/web-platform-tests/wpt/blob/db6e5032915eb0dcb1d8b8b249488055378245fd/html/webappapis/dynamic-markup-insertion/opening-the-input-stream/url.window.js#L28, what exactly about `childDoc` causes it to be not fully active at that point? [04:21:26.0711] I mean in terms of the spec requirements at https://html.spec.whatwg.org/multipage/document-sequences.html#fully-active: > A [Document](https://html.spec.whatwg.org/multipage/dom.html#document) d is said to be fully active when d is the [active document](https://html.spec.whatwg.org/multipage/document-sequences.html#nav-document) of a [navigable](https://html.spec.whatwg.org/multipage/document-sequences.html#navigable) navigable, and either navigable is a [top-level traversable](https://html.spec.whatwg.org/multipage/document-sequences.html#top-level-traversable) or navigable's [container document](https://html.spec.whatwg.org/multipage/document-sequences.html#nav-container-document) is [fully active](https://html.spec.whatwg.org/multipage/document-sequences.html#fully-active). [04:23:36.0273] …so `childDoc` must either (a) not be the active document of a navigable, or (b) the navigable is not a top-level traversable, or (c) the navigable’s container document is not fully active. [04:45:39.0366] sideshowbarker: it's a reference to _frameURL_'s document but at that point the nested document is `/common/blank.html`'s document [05:10:43.0255] thanks [08:45:34.0769] > <@noamr:matrix.org> Dominic Farolino: right, it results in a network error Thanks, and is this only for cross-origin no-cors requests? That is, if you sent a same-origin no-cors request to a JSON resource, would it get ORB blocked? [08:45:56.0971] My understanding is "no, it wouldn't be blocked" but I'm not 100% confident. [08:46:03.0576] * My intuiting is "no, it wouldn't be blocked" but I'm not 100% confident. [08:46:06.0547] * My intuition is "no, it wouldn't be blocked" but I'm not 100% confident. [08:54:13.0762] yea CO in CORB stands for cross-origin, but trying to follow how this is done in the fetch spec. [09:17:00.0339] ORB matches that, it should be in the ORB PR. [11:37:30.0296] The team working on HTTPS auto-upgrades would like to get https://github.com/whatwg/fetch/pull/1655 into Fetch. What's their next step toward merging it? [12:51:35.0637] Are SVG elements with an id attribute supposed to be exposed as named properties on the window? The section on named properties for the window object says that that should be "HTML Elements" with an id content attribute, which points to a definition that says "elements in the xhtml namespace" [13:28:26.0599] All three major browsers seem to just cache any DOM element with an id attribute, which includes things that aren't what I would think of as HTML elements 🤔 [13:50:17.0295] > <@noamr:matrix.org> yea CO in CORB stands for cross-origin, but trying to follow how this is done in the fetch spec. Hah yeah I knew that much, I just didn't know if there was anything interesting going on with dropping the "C", in just normal ORB [14:23:42.0250] a friend of mine is asking about how to make use of native context menus on the web, and told me that there was an old now removed thing in firefox which included the element. are yall aware of any current work or plans to make this kind of thing possible? [14:23:57.0766] * a friend of mine is asking about how to make use of native context menus on the web, and told me that there was an old now removed thing in firefox which included the menuitem element. are yall aware of any current work or plans to make this kind of thing possible? [15:50:31.0584] What even is a native context menu? https://www.askvg.com/too-much-inconsistency-in-windows-10-context-menus/ 🤔 2023-09-21 [17:31:31.0948] > <@jarhar:matrix.org> a friend of mine is asking about how to make use of native context menus on the web, and told me that there was an old now removed thing in firefox which included the menuitem element. are yall aware of any current work or plans to make this kind of thing possible? See https://platform.html5.org/history/webapps/r4636.html#context-menus — not as far as current work, but just as far as what the spec once had before it was eventually removed (due to lack of implementor interest). [17:33:10.0532] was there any issues that implementors brought up? [17:34:29.0323] At this point I don’t recall. Would need to do some archaeology. Anne or Domenic might remember more [17:37:45.0830] I just now looked through the commit history, but can’t even find the commit that removed it… [17:38:28.0764] found https://github.com/whatwg/html/commit/e7e8c88e [17:38:46.0964] * I just now looked through the commit history, but can’t even find the commit that removed it… [17:39:11.0138] …which links to https://bugs.chromium.org/p/chromium/issues/detail?id=87553&desc=2#c64 [17:40:02.0756] > - There is doubt whether the API is well designed. > - This may not be a high enough priority right now. Part of the team is responsible for implementing new "capabilities". Reaching outside the content area and contributing items to the browser's context menu is a new capability. yuzus, tkent and I are not on the capabilities part of the team; they are busy bringing web developers other new capabilities. They should be heavily involved in the decision to implement this but they can't right now. > - It is hard to prioritize for other reasons. For example, this feature only exists in Firefox, so we're not making interoperability better by implementing this. [17:41:31.0344] …for which one way of reading it is, _“because WebKit hasn’t implemented it, we don’t think it’s enough of a priority”_ [17:46:04.0284] thank you for finding this! [17:46:28.0601] cheers [23:39:12.0501] akaster: oh wow, file an issue? I guess we should just update the spec then. [23:41:12.0621] Sure thing! I was wondering if maybe my interpretation of "HTML Element" was wrong given how they all agreed 😅 [23:55:48.0196] I made issue 9766 for this [00:08:26.0471] Thanks! (HTML element definitely means HTML namespace.) [00:33:26.0183] > <@jyasskin:matrix.org> The team working on HTTPS auto-upgrades would like to get https://github.com/whatwg/fetch/pull/1655 into Fetch. What's their next step toward merging it? I'd be happy to help with some editorial reviews if annevk gives a green light for the general direction of the feature etc [01:16:56.0829] about the _“document.open() does not change document's URL (active but not fully active document”_ test case at https://github.com/web-platform-tests/wpt/blob/db6e5032915eb0dcb1d8b8b249488055378245fd/html/webappapis/dynamic-markup-insertion/opening-the-input-stream/url.window.js#L28 : in light of https://github.com/whatwg/html/pull/4076 — and specifically the requirement _“A [Location](https://html.spec.whatwg.org/multipage/nav-history-apis.html#location) object has an associated url, which is this [Location](https://html.spec.whatwg.org/multipage/nav-history-apis.html#location) object's [relevant Document](https://html.spec.whatwg.org/multipage/nav-history-apis.html#relevant-document)'s [URL](https://dom.spec.whatwg.org/#concept-document-url), if this [Location](https://html.spec.whatwg.org/multipage/nav-history-apis.html#location) object's [relevant Document](https://html.spec.whatwg.org/multipage/nav-history-apis.html#relevant-document) is non-null, and [about:blank](https://html.spec.whatwg.org/multipage/infrastructure.html#about:blank) otherwise”_ — shouldn’t that test be updated to change the assert there to `assert_equals(childWin.location.href, "about:blank")`? [01:17:04.0450] * annevk: about the _“document.open() does not change document's URL (active but not fully active document”_ test case at https://github.com/web-platform-tests/wpt/blob/db6e5032915eb0dcb1d8b8b249488055378245fd/html/webappapis/dynamic-markup-insertion/opening-the-input-stream/url.window.js#L28 : in light of https://github.com/whatwg/html/pull/4076 — and specifically the requirement _“A [Location](https://html.spec.whatwg.org/multipage/nav-history-apis.html#location) object has an associated url, which is this [Location](https://html.spec.whatwg.org/multipage/nav-history-apis.html#location) object's [relevant Document](https://html.spec.whatwg.org/multipage/nav-history-apis.html#relevant-document)'s [URL](https://dom.spec.whatwg.org/#concept-document-url), if this [Location](https://html.spec.whatwg.org/multipage/nav-history-apis.html#location) object's [relevant Document](https://html.spec.whatwg.org/multipage/nav-history-apis.html#relevant-document) is non-null, and [about:blank](https://html.spec.whatwg.org/multipage/infrastructure.html#about:blank) otherwise”_ — shouldn’t that test be updated to change the assert there to `assert_equals(childWin.location.href, "about:blank")`? [01:25:57.0742] * annevk: about the _“document.open() does not change document's URL (active but not fully active document”_ test case at https://github.com/web-platform-tests/wpt/blob/db6e5032915eb0dcb1d8b8b249488055378245fd/html/webappapis/dynamic-markup-insertion/opening-the-input-stream/url.window.js#L28 : in light of https://github.com/whatwg/html/pull/4076 — and specifically the requirement _“A [`Location`](https://html.spec.whatwg.org/multipage/nav-history-apis.html#location) object has an associated url, which is this [`Location`](https://html.spec.whatwg.org/multipage/nav-history-apis.html#location) object's [relevant Document](https://html.spec.whatwg.org/multipage/nav-history-apis.html#relevant-document)'s [`URL`](https://dom.spec.whatwg.org/#concept-document-url), if this [`Location`](https://html.spec.whatwg.org/multipage/nav-history-apis.html#location) object's [relevant Document](https://html.spec.whatwg.org/multipage/nav-history-apis.html#relevant-document) is non-null, and [**`about:blank`**](https://html.spec.whatwg.org/multipage/infrastructure.html#about:blank) otherwise”_ — shouldn’t that test be updated to change the assert there to `assert_equals(childWin.location.href, "about:blank")`? [01:26:41.0569] * annevk: about the _“document.open() does not change document's URL (active but not fully active document”_ test case at https://github.com/web-platform-tests/wpt/blob/db6e5032915eb0dcb1d8b8b249488055378245fd/html/webappapis/dynamic-markup-insertion/opening-the-input-stream/url.window.js#L28 : in light of https://github.com/whatwg/html/pull/4076 — and specifically the requirement _“A [`Location`](https://html.spec.whatwg.org/multipage/nav-history-apis.html#location) object has an associated url, which is this [`Location`](https://html.spec.whatwg.org/multipage/nav-history-apis.html#location) object's [relevant Document](https://html.spec.whatwg.org/multipage/nav-history-apis.html#relevant-document)'s [`URL`](https://dom.spec.whatwg.org/#concept-document-url), if this [`Location`](https://html.spec.whatwg.org/multipage/nav-history-apis.html#location) object's [relevant Document](https://html.spec.whatwg.org/multipage/nav-history-apis.html#relevant-document) is non-null, and [**`about:blank`**](https://html.spec.whatwg.org/multipage/infrastructure.html#about:blank) otherwise”_ — shouldn’t that test be updated to change the assert there to `assert_equals(childWin.location.href, "**about:blank**")`? [01:27:19.0737] * annevk: about the _“document.open() does not change document's URL (active but not fully active document”_ test case at https://github.com/web-platform-tests/wpt/blob/db6e5032915eb0dcb1d8b8b249488055378245fd/html/webappapis/dynamic-markup-insertion/opening-the-input-stream/url.window.js#L28 : in light of https://github.com/whatwg/html/pull/4076 — and specifically the requirement _“A [`Location`](https://html.spec.whatwg.org/multipage/nav-history-apis.html#location) object has an associated url, which is this [`Location`](https://html.spec.whatwg.org/multipage/nav-history-apis.html#location) object's [relevant Document](https://html.spec.whatwg.org/multipage/nav-history-apis.html#relevant-document)'s [`URL`](https://dom.spec.whatwg.org/#concept-document-url), if this [`Location`](https://html.spec.whatwg.org/multipage/nav-history-apis.html#location) object's [relevant Document](https://html.spec.whatwg.org/multipage/nav-history-apis.html#relevant-document) is non-null, and [**`about:blank`**](https://html.spec.whatwg.org/multipage/infrastructure.html#about:blank) otherwise”_ — shouldn’t that test be updated to change the assert there to `assert_equals(childWin.location.href, "`**`about:blank`**`")`? [01:29:29.0798] * annevk: about the _“document.open() does not change document's URL (active but not fully active document)”_ test case at https://github.com/web-platform-tests/wpt/blob/db6e5032915eb0dcb1d8b8b249488055378245fd/html/webappapis/dynamic-markup-insertion/opening-the-input-stream/url.window.js#L28 : in light of https://github.com/whatwg/html/pull/4076 — and specifically the requirement _“A [`Location`](https://html.spec.whatwg.org/multipage/nav-history-apis.html#location) object has an associated url, which is this [`Location`](https://html.spec.whatwg.org/multipage/nav-history-apis.html#location) object's [relevant Document](https://html.spec.whatwg.org/multipage/nav-history-apis.html#relevant-document)'s [`URL`](https://dom.spec.whatwg.org/#concept-document-url), if this [`Location`](https://html.spec.whatwg.org/multipage/nav-history-apis.html#location) object's [relevant Document](https://html.spec.whatwg.org/multipage/nav-history-apis.html#relevant-document) is non-null, and [**`about:blank`**](https://html.spec.whatwg.org/multipage/infrastructure.html#about:blank) otherwise”_ — shouldn’t that test be updated to change the assert there to `assert_equals(childWin.location.href, "`**`about:blank`**`")`? [02:12:40.0827] sideshowbarker: I'm not sure that's accurate, relevant Document is childFrame.contentDocument, which is non-null, right? [02:29:27.0034] Jeffrey Yasskin: Noam Rosenthal: I gave it another pass; things that could help in the future: ensure Build is passing, commit message is clear, checklist in OP is filled out, there's a PR somewhere for renaming tentative tests to non-tentative tests; if either of you wants to review it as well that'd be appreciated [02:52:43.0723] > <@annevk:matrix.org> Jeffrey Yasskin: Noam Rosenthal: I gave it another pass; things that could help in the future: ensure Build is passing, commit message is clear, checklist in OP is filled out, there's a PR somewhere for renaming tentative tests to non-tentative tests; if either of you wants to review it as well that'd be appreciated Sure I will give it a pass. Wanted to see that it's not outright rejected or so. Thanks 🙏 [02:56:26.0548] Euh, XML doesn't define what to do with `data:text/xml,`? Five editions! [03:01:10.0527] (Tracked in https://bugs.webkit.org/show_bug.cgi?id=18110 for now.) [03:01:29.0298] > <@annevk:matrix.org> sideshowbarker: I'm not sure that's accurate, relevant Document is childFrame.contentDocument, which is non-null, right? Yeah, seems so — and that’s also what I had thought, but WebKit is the only UA to have implemented that spec change, and WebKit returns `about:blank` there. So it appears to be a bug in WebKit, caused by the Location code not having the Frame object that it should have. Take a look at https://searchfox.org/wubkat/source/Source/WebCore/page/Location.cpp#53-54. That entire code assumes there’s a single `frame()` Frame object that it gets the location from. But for that test case, it’s null. So I guess changing the `src` value of that iframe either causes the `childDoc` to be prematurely completely disassociated from `childFrame`, or else that `childFrame` gets prematurely destroyed. [03:13:01.0952] Does anyone know how you find out if indexing a spec got stuck? XHR still doesn't pick up terms we introduced in HTML two days ago. [03:13:09.0307] TabAtkins maybe? [03:14:29.0456] sideshowbarker: are you saying `Frame` is 1:1 with `Document`? I'm not familiar with how this stuff is implemented in browsers unfortunately. [03:45:53.0567] > <@annevk:matrix.org> sideshowbarker: are you saying `Frame` is 1:1 with `Document`? I'm not familiar with how this stuff is implemented in browsers unfortunately. I don’t know — I need to trace through the rest of the code more. But code-wise, I see that Location code has access to a LocalDOMWindow window, along with access to that frame() Frame, and naĂŻvely I wonder if it should be getting the document from that LocalDOMWindow object rather the Frame. Anyway, if I can’t get it figured out, I’ll raise a bugs.webkit.org bug. The failing test case is at https://wpt.fyi/results/html/webappapis/dynamic-markup-insertion/opening-the-input-stream/url.window.html [03:47:17.0707] > <@annevk:matrix.org> sideshowbarker: are you saying `Frame` is 1:1 with `Document`? I'm not familiar with how this stuff is implemented in browsers unfortunately. * I don’t know — I need to trace through the rest of the code more. But code-wise, I see that Location code has access to a LocalDOMWindow window, along with access to that frame() Frame, and naĂŻvely I wonder if it should be getting the document from that LocalDOMWindow object rather than from the Frame. Anyway, if I can’t get it figured out, I’ll raise a bugs.webkit.org bug. The failing test case is at https://wpt.fyi/results/html/webappapis/dynamic-markup-insertion/opening-the-input-stream/url.window.html [04:25:28.0085] Huh, I see that I was mentioned but can't find the message with it [04:30:13.0860] Oh I skipped right past it, nm. I'll check in a bit, annevk: [04:30:53.0418] (it's 4am right now, my sleep is disordered due to COVID) [05:06:25.0513] Sorry to hear that. I guess the number of people impacted by TPAC is still rising. 🙃 [05:17:25.0614] (Although if you're in California again I wonder if it's not jetlag as that's my usual visiting-California-wake-up time.) [05:25:45.0310] I got home on Saturday night, my jetlag doesn't last that long. 😅 [05:27:24.0332] at least you're not still stuck at DFW [05:31:49.0085] Lord, yeah. Actually got home *faster* than planned, the Atlantic flight got in early and I got myself bumped to an earlier flight for my last leg. [05:42:59.0038] annevk: If I make a change to the Location-handling code in WebKit (specifically, to the `Location::url()` code), what WPT tests should I check for regressions? I just locally ran all 926 tests in the `html/webappapis` and `html/browsers` subtrees. Are there WPT subtrees in addition to those that I should also run and look at results for? [05:50:44.0923] annevk: sorry for the [massive comment](https://github.com/whatwg/html/pull/9546#issuecomment-1729500041) in the switch issue :/ [05:51:06.0049] annevk: but I think it's important we get these details right to avoid the kind of mess we're in with some of the other form controls [06:51:41.0410] sideshowbarker: that seems about right [06:54:38.0747] emilio: that's very useful, thanks! [06:59:01.0570] emilio: I'll do some more investigation. Might take a while. If zcorpan has some notes somewhere from when he investigated all this for `` that might be useful too. Ideally I'd like to tackle this in stages, but there should be sufficient information for each stage and earlier design decisions shouldn't cause us to run into issues later on. [07:01:48.0482] IIRC I didn't investigate checkboxes so much [07:03:57.0590] zcorpan: it's not too late 😅 [07:05:17.0946] annevk: it never is :) [09:54:20.0537] annevk: implementer interest or opposition for webkit? https://github.com/whatwg/html/pull/9538 [10:06:56.0054] zcorpan: support, made me remember to actually label https://github.com/WebKit/standards-positions/issues/86 properly [10:34:44.0686] annevk: will see what Chris says about https://github.com/WebKit/WebKit/pull/18026. I don’t yet understand exactly that the `Frame` abstraction maps to in the spec — but whatever its purpose, it seems like the code can and should just be using the available Window instead. And the test results also seem to indicate that’s what should be happening. [12:42:38.0169] > <@annevk:matrix.org> Jeffrey Yasskin: Noam Rosenthal: I gave it another pass; things that could help in the future: ensure Build is passing, commit message is clear, checklist in OP is filled out, there's a PR somewhere for renaming tentative tests to non-tentative tests; if either of you wants to review it as well that'd be appreciated Thanks annevk and Noam Rosenthal! I've sent https://github.com/whatwg/spec-factory/pull/48 to try to reduce the chance that we miss those things again in the future. 2023-09-22 [00:11:59.0913] I wrote down a couple thoughts for new issue templates, I'd very much appreciate input from anyone in this channel: https://github.com/whatwg/meta/issues/296#issuecomment-1730915857 cc muan keithamus [00:20:45.0824] Jeffrey Yasskin: nice! 2023-09-23 [08:53:52.0976] hi, I am trying to find out where Window's associated document needs to be set/updated. So far I found that specification defines "11. Set window's associated Document to document." in https://html.spec.whatwg.org/multipage/document-lifecycle.html#initialise-the-document-object is that actually the only place where associated document should be set? shouldn't it also be set for document created alongside the browsing context here https://html.spec.whatwg.org/multipage/document-sequences.html#creating-a-new-browsing-context ? 2023-09-24 [20:16:10.0295] Hmm, maybe a bug. I think https://html.spec.whatwg.org/multipage/browsing-the-web.html#make-active used to set the associated Document, but doesn't anymore? [00:06:11.0419] I don't know what is going on when you have nested forms https://codesandbox.io/s/nested-forms-9zgg4x?file=/src/App.js:717-722 [00:08:01.0597] Try submitting the inner form and observe what happens. I know that having nested forms is not really according to specs (I don't know why) but something strange happens. I also tried e.stopPropagation() and the same happens. [01:15:00.0276] > <@domenicdenicola:matrix.org> Hmm, maybe a bug. I think https://html.spec.whatwg.org/multipage/browsing-the-web.html#make-active used to set the associated Document, but doesn't anymore? Yea also seems like a bug to me, trying to follow the links... [01:37:11.0111] vrafaeli: nested forms are not spec-compilant and have all kind of incompatible behavior across browsers. Unexpected behavior sounds like something you should be expecting. [02:27:23.0702] Ok. What is the reason for nested forms not being allowed by the spec? [05:29:38.0527] vrafaeli: I wasn't there but AFAIK it's a very old thing (HTML3?)... like many things in the web platform, trying to change the behavior at this point would make an even bigger mess. The `form` attribute on input elements provides an alternative that should be sufficient. [06:58:15.0618] > <@vrafaeli:matrix.org> Ok. What is the reason for nested forms not being allowed by the spec? FWIW the HTML checker does catch that and attempt to provide a helpful message: > _Saw a form start tag, but there was already an active form element. Nested forms are not allowed. Ignoring the tag._ I also don’t know why nested forms aren’t allowed. But if we can find an explanation and write it up somewhere, I could make the _“Nested forms are not allowed”_ text in that message into a hyperlink to the explanation. And I guess the best place for the explanation would be as a non-normative Note in the HTML spec itself. [11:57:46.0483] sideshowbarker: FWIW the HTML checker does catch that and attempt to provide a helpful message: Yea I noticed that 2023-09-25 [04:29:47.0875] If folks have thoughts on what our READMEs for standards should look like, I'd welcome them here: https://github.com/whatwg/spec-factory/pull/49 2023-09-26 [20:40:13.0898] The HTML spec currently [contains the following sentence](https://html.spec.whatwg.org/multipage/parsing.html#insert-an-html-element): > When the steps below require the user agent to **insert an HTML element** for a token, the user agent must **insert a foreign element** for the token, in the HTML namespace. (emphasis mine) I think it's rather confusing for the "insert a foreign element" procedure to be called that when it is also used for non-foreign elements. I think it would make more sense for it to just be called "insert an element". What do you think about this? [22:28:17.0242] martin: I think that's a reasonable rename. mfreed is touching that step in the declarative shadow tree PR so maybe we don't want to rename it until after that lands. [23:27:51.0491] zcorpan, annevk I want to proceed on the reveal/readytorender event we discussed at TPAC for view-transitions (https://github.com/whatwg/html/issues/9315). seems like there was rough consensus about the direction, I want to see we're ok with the details [00:37:23.0907] annevk: About ``, can you point me to the specific step in https://drafts.csswg.org/cssom/ that requires setting the owner node to null? I’m not questioning it — I just want to add a spec link to the commit message for https://github.com/WebKit/WebKit/pull/17001 And I’m specifically looking at the part of the test case at https://github.com/web-platform-tests/wpt/blob/master/css/cssom/HTMLLinkElement-disabled-002.html#L26 [01:02:49.0884] Domenic: I was hoping you could have a look at https://github.com/whatwg/spec-factory/pull/34 too; it's old but still relevant [01:03:45.0815] sideshowbarker: I don't see it in https://drafts.csswg.org/cssom/#the-stylesheet-interface and I think emilio wrote those tests, so maybe he can elaborate [01:10:22.0069] sideshowbarker: annevk: Seems like a bug in the CSSOM spec. The ownerNode is mutable, and goes away when the node -> sheet link goes away. E.g., this interoperably logs ` ``` [01:17:10.0402] emilio: I think that specific scenario is covered by https://drafts.csswg.org/cssom/#remove-a-css-style-sheet [01:18:40.0384] I think the problem is that there's no equivalent logic around disabling [02:11:23.0455] Sketch for the new feature/issue templates: https://github.com/annevk/temp-whatwg-new-issue/issues/new/choose cc Domenic keithamus muan zcorpan sideshowbarker [02:12:12.0273] (That link will 404 at some point because GitHub doesn't 410 I think. You should be able to find it in spec-factory then.) [02:13:09.0214] annevk: very nice! [02:13:54.0366] Oh this looks great! [02:28:23.0045] oh wow I didn’t know you could put in a outside link like that (the chat link) [02:28:53.0844] Yeah maybe I should put some more links there now I know how that looks [02:30:26.0054] The inline chat link in the new issue template is great too [02:30:53.0847] And the required _“What problem are you trying to solve?”_ field (in the new-feature template) [02:34:33.0432] "What would you say you do here?" [03:44:37.0168] So 20 years ago this month is when Hixie published the first version of what would eventually lead to “HTML5” and the modern HTML spec http://www.hixie.ch/specs/html/forms/hfp.html (titled _“XHTML Module: Extensions to Form Controls”_) [03:47:18.0431] I vaguely recall a declarative version of http://www.hixie.ch/specs/html/forms/hfp.html#TOC51 [03:48:20.0739] Maybe that came later? somewhere in https://platform.html5.org/history/ [03:59:32.0479] > <@annevk:matrix.org> I think the problem is that there's no equivalent logic around disabling emilio: You able to make time to update the CSSOM spec to add a _“disable a CSS stylesheet”_ algorithm? (Assuming you’re still the current editor.) Also I guess the HTML spec would need to be updated too, to add a call site to that new algorithm — at https://html.spec.whatwg.org/multipage/semantics.html#the-link-element:attr-link-disabled-2 I suppose? Or else I can try to write up a patch for it myself. Lemme know [04:00:52.0558] I don't see it in the history, but https://whatwg.org/specs/web-forms/current-work/#repeatingFormControls has it. I think Opera supported something like it at one point. [04:03:00.0755] > <@annevk:matrix.org> I don't see it in the history, but https://whatwg.org/specs/web-forms/current-work/#repeatingFormControls has it. I think Opera supported something like it at one point. ah yeah I remember that now [04:07:23.0000] sideshowbarker: there is a "disabled flag" on `StyleSheet` [04:07:34.0772] https://drafts.csswg.org/cssom/#concept-css-style-sheet-disabled-flag [04:13:24.0320] zcorpan: the problem is that owner node isn't updated, see upthread [04:19:55.0936] annevk: I see. Seems like the behavior is https://drafts.csswg.org/cssom/#remove-a-css-style-sheet ? [04:20:22.0932] annevk: does the spec say what to do when removing a `link` or `style` element from the document? I couldn't find anything [04:30:11.0629] hi i have a problem with a site that i've made. it works great on chrome but it doesnt work on firefox. i have a html form and the data is stored in a json file. when the user has paid the file goes to a php file and the data is taken from the json file. but when i try this in firefox it doesnt work i get this TypeError: NetworkError when attempting to fetch resource [05:00:05.0977] zcorpan: that's defined, yes, remove a style sheet is called; but there's nothing like that for enabling/disabling [05:00:32.0745] annevk: what's the difference? [05:00:43.0976] anouk s: that's prolly better suited for Stack Overflow (and you'll need to provide more details there) [05:01:29.0182] Maybe enabling again doesn't create a new stylesheet [05:04:47.0556] Ian Hickson: saving in live dom viewer seems to give an internal error [05:05:30.0176] annevk: different behavior for re-enabling in safari vs chrome/firefox: ``` ``` [05:08:35.0375] thank you i'm going over there. hopefully they can help me [06:43:14.0548] keithamus: if there's some secret syntax by which you can omit the label from the output let me know, https://github.com/annevk/temp-whatwg-new-issue/issues/2 is a little ugly given there's only one input field in the end but workable [06:43:47.0761] As in, I'd prefer "What is the issue?" not to be there [06:50:30.0445] I'm not sure that's possible without abusing the format by adding another field or stuffing the heading into the description. [07:00:33.0650] keithamus: thanks [07:00:42.0854] I wrote https://github.com/orgs/community/discussions/63402#discussioncomment-7113247. Maybe it'll help [07:05:33.0147] I’ll put it in front of the feature engineers for that feature and see if they can prioritise it. [11:26:21.0688] Jeffrey Yasskin: if you have thoughts on https://github.com/annevk/temp-whatwg-new-issue/issues/new/choose or https://github.com/whatwg/spec-factory/pull/49 I'd appreciate them [11:27:39.0089] One thing I realized with the `new/choose` URL is that we probably want to link there directly rather than link to `new`. It would also break zcorpan's script, though we might be able to make that work still. [11:33:43.0493] > <@annevk:matrix.org> Jeffrey Yasskin: if you have thoughts on https://github.com/annevk/temp-whatwg-new-issue/issues/new/choose or https://github.com/whatwg/spec-factory/pull/49 I'd appreciate them I love both of them. I'm sure I will eventually find things I want to change, but I don't see any right now, and I can send PRs whenever I notice something. 😍 [15:28:57.0415] i just filed an issue for selectlist and id like to use the new stages process for it, what should i do?: https://github.com/whatwg/html/issues/9799 [15:29:36.0087] i see that yall are working on new issue templates, would those prompt for the usage of the new stages? [15:29:44.0446] i could re-file the issue later if thats the case [15:38:18.0148] Domenic: it looks like fireNavigateEventOnCommit is unused in `apply the history step`. Is this refactoring leftovers or some missing functionality? [15:40:11.0694] > <@jarhar:matrix.org> i just filed an issue for selectlist and id like to use the new stages process for it, what should i do?: https://github.com/whatwg/html/issues/9799 I believe cwilso is on the hook to finish up the details of the stages system. [16:26:26.0524] Is a null "origin or null" same origin with another null "origin or null"? [16:28:30.0086] > <@akaster:serenityos.org> Domenic: it looks like fireNavigateEventOnCommit is unused in `apply the history step`. Is this refactoring leftovers or some missing functionality? Can you please file a bug so I can investigate? Chat messages are too easily lost. [16:34:56.0925] Sure thing, I filled issue #9800 for this 2023-09-27 [17:50:17.0246] Dominic Farolino: Isn't https://github.com/whatwg/fetch/issues/1706 likely to break some percentage of sites that are currently relying on browsers not doing a preflight? [17:56:50.0223] > <@akaster:serenityos.org> Is a null "origin or null" same origin with another null "origin or null"? I think a null origin is by definition a unique origin that doesn't match any other origin — including any other null origin. HTML uses “opaque origin” to help make that more clear (no pun intended) [18:00:24.0113] sounds more like a NaN origin (half-serious) [21:26:18.0286] > <@annevk:matrix.org> Sketch for the new feature/issue templates: https://github.com/annevk/temp-whatwg-new-issue/issues/new/choose cc Domenic keithamus muan zcorpan sideshowbarker I made some edits, PTAL. I'm OK omitting the StackOverflow link I added, not sure it's worth it. [21:36:33.0549] Domenic: For some reason, the order is different on mobile: [21:37:01.0431] Oh dear... [21:37:08.0724] Maybe having Chat and StackOverflow first that way is actually better, I dunno [21:37:09.0347] Is that a result of my renames? [21:37:15.0325] Or is it an existing bug? [21:37:45.0031] I don’t think it was the result of your renames — but I also don’t remember what the order was previously [21:39:42.0785] anyway, I think we should keep the Stack Overflow link — because it’s helpful but also because we’d still be using up only ~2/3rds of the vertical space on a mobile screen, so users wouldn’t need to scroll to see anything. And it’d leave us plenty of room to add more links later, if/when we think of other stuff [21:41:01.0891] nit: I think Stack Overflow is two words rather than one camelcased [21:45:08.0629] Fixed, thanks [21:51:12.0853] and for the Stack Overflow text maybe something more like: > _If you're having a problem with your frontend code, this is probably not the right place to get help. Consider asking on Stack Overflow instead. This issue tracker is for bugs and questions about the Foo standard itself, and feature requests._ [22:10:54.0999] Domenic: for the _New issue_ template, maybe we should also have: - Add a new required **Spec section URL** as the first input field, with the guidance text being something like: > _Which specific section of the Foo spec are you reporting this issue against?_ - In place of the “What is the issue?” label, instead something like: > _What information in the spec was incorrect, incomplete, or otherwise in need of being updated?_ [22:12:02.0235] …with part of the purpose being to preempt people filing issues that aren’t directly related to the content of the spec itself, but instead should be asked in Stack Overflow or somewhere. [22:13:48.0137] …because if someone is unable to provide a URL for a spec section, and unable to identify a particular section of the spec that has a problem, and to describe what the specific problem is in the spec, then it’s likely not a spec issue [22:17:29.0412] and a bonus would be that the spec URL could be used to automatically label the issue based on what spec section it’s about — for example, in the case of the HTML spec, the appropriate `topic:` label from https://github.com/whatwg/html/labels?q=topic%3A [22:18:43.0166] Oh, I like that idea. annevk , thoughts? [22:23:20.0768] I worry a bit about making filing an issue overly laborious. Rephrasing the question seems reasonable, but I'm not sure about requiring a URL. Although having an optional URL field might be okay and could be used when we refactor zcorpan's script. (Of course, at that point my feature request to GitHub becomes moot too.) [22:27:33.0872] Domenic: I guess you should do the newline thing on the New issue template too [22:28:50.0580] (Opaque origin can sometimes be reused and it is same origin with itself so it's not quite like NaN I think.) [22:30:32.0491] > <@annevk:matrix.org> Domenic: I guess you should do the newline thing on the New issue template too There's only one paragraph there so it's not needed. [23:27:26.0349] Domenic: it has the same newline separating the Chat line [23:30:25.0196] Ah I see, it just linebreaked at exactly the right place. [23:31:45.0491] Done [00:18:03.0299] Is it a problem that people are filing issues that aren't spec issues? [00:22:23.0863] zcorpan: kinda [00:23:45.0773] zcorpan: I think especially for HTML there's quite a bit of noise and at the same time not enough information for people who want to help fix things [00:30:29.0210] annevk: ok yeah then maybe the template can ask for more details [01:29:34.0305] Domenic: https://github.com/whatwg/url/pull/794 \o/ [01:29:53.0168] Nice! [01:32:14.0592] I guess I'll create the remainder of PRs automatically and then if any need additional work I'll find out through self-review [01:32:38.0662] Domenic: what happens to NavigationHistoryEntry on location.replace()? I am afraid that if we use history entries directly for the activation info we might lose some info [01:33:18.0365] I'll land this URL one first and give it until after lunch at least before doing the remainder, just in case [01:33:39.0249] They get replaced with a new NavigationHistoryEntry [01:34:03.0240] This API would actually be the first time you could see a replaced entry [01:34:24.0572] Which we have for some time noted as a vaguely good idea to solve [01:34:52.0430] https://github.com/WICG/navigation-api/issues/41 [01:38:35.0610] Okay, so currently "file issue about the selected text" bypasses the template. But it still works. We can look into fixing that, but given how seldom it's used I'm motivated enough to do it myself. [01:38:49.0915] * Okay, so currently "file issue about the selected text" bypasses the template. But it still works. We can look into fixing that, but given how seldom it's used I'm not motivated enough to do it myself. [02:27:07.0823] Folks here might enjoy hober's https://tess.oconnor.cx/2023/09/polyglots-and-interoperability (if you make the time, maybe also budget some time for the cross-references, I especially enjoyed Ian Hickson's email referenced in the footnote about namespace prefixes) [02:35:46.0962] "something too terrible to actually use can be fixed by adding a level of indirection", I like that [02:40:29.0904] Domenic: re https://github.com/whatwg/html/issues/9760, coming to think that the whole thing about activation info is a almost an entirely different use case from "initial load". I wonder if "initial load" has use-cases other than manipulating the spinner? [02:43:11.0404] Hah, the most popular "whatwg" repo is node-fetch: https://github.com/topics/whatwg. That is kinda funny. [02:44:25.0912] And Observable is more popular than Web IDL. Good times. [03:50:38.0871] I guess we need to buy some more github stars [08:18:30.0508] time to make deprecate WebIDL and describe all APIs in terms of Observable [08:18:53.0748] If you want to know what the width of your canvas is, just subscribe to it once :) [08:24:31.0801] dbaron: I think you should now have sufficient access for labels and reviewers and such; if it's still not working I can give you write access on some repositories if you want (still won't give you direct access to main, but would allow you to meddle with other people's PRs; up to you whether you want such power) [08:27:08.0204] If everyone observed it, but nobody subscribed, did it really happen? [08:54:24.0794] miketaylr: you get the honor of deploying the last set of issue templates (and fixing a Build error): https://github.com/whatwg/compat/pull/247 🎉 [09:01:34.0892] annevk: I'm looking at potential interop isues where I know that Chrome is using an internal redirect but Firefox is replacing the request's URL scheme (s/HTTP/HTTPS), but I'm still not fully sure what an internal redirect is and how that is web-exposed. As the person who field https://github.com/whatwg/fetch/issues/1426, - Can you help me come up with a test case or a specific scenario where that would be web-observable? [09:02:46.0186] I a test that redirects 14 times + internal redirect would get you to 15 redirects (is that still the max?) and return a NetworkError, where a scheme-replacement wouldnt. But surely that isn't in the categories of interesting scenarios? :) [09:03:11.0779] freddy: that's actually a scenario we have an issue on [09:03:56.0735] freddy: limit is 20 per https://fetch.spec.whatwg.org/#concept-http-redirect-fetch [09:05:08.0196] freddy: actually replacing it would also update a Request object I think, which doesn't make any sense [09:06:24.0875] freddy: an internal redirect is essentially where you go to the network layer and the network layer gives you a new location and then you do policy checks against that (hopefully correctly, but often we've had bugs) and tell the network layer to go fetch it [09:07:34.0285] freddy: https://github.com/whatwg/fetch/issues/576 [09:09:14.0841] Ah, so the "fetch" abstraction should treats it as a redirect that needs to be subject to additional security checks? [09:09:42.0814] I suppose in a "switch the target to HTTPS" you wouldn't want to check the CSP (and cause violations for a request that was browser-modified and not issued by the page)? [09:10:11.0329] I'll need to think about that some more. Unfortunately, I have to end my work for today. [09:11:03.0164] freddy: or bypass certain checks such as CSP and CORS [09:12:18.0951] freddy: I guess the main reason why it's done is because you can't always make these decisions synchronously and the network layer has access to the relevant information; Fetch doesn't really have the same limitation/interface, but we do kinda want the initial request URL not to be mutated, but we could solve that in other ways too [09:13:18.0019] (Clearly, I should also take a break.) 2023-09-28 [20:23:54.0319] Ian Hickson: please fix live DOM viewer :). Or open source it somewhere so we can host our own. [20:23:59.0873] (Save button is broken.) [00:07:08.0474] In the meantime, I like https://livedom.bentkowski.info/ a lot. It's got a "share URL" feature but that just throws the whole input into a URL parameter which might be a bit long and unwieldy [00:16:52.0892] keithamus: I'm not sure I understand https://github.com/whatwg/fullscreen/issues/124#issuecomment-1738125683, but it also seems like something that is better raised with the CSS WG? [00:18:17.0650] Sure, I can raise it there. I was mostly +1ing and adding what I thought would be useful context. [00:42:54.0715] johannhof: Noam Rosenthal: should Set-Cookie be honored on 101 (current answer is yes), 103 (current answer is no), and other 1xx responses (current answer is no)? I'll open an issue against Fetch for this because I don't think we have fully considered it. [00:46:38.0717] https://github.com/whatwg/fetch/issues/1710 [01:00:43.0656] annevk: I wonder how this is used in 101 for Websockets or whatnot... my immediate intuition would be that 1xx responses setting cookies would be a violation of them being "informational" [01:01:27.0573] Noam Rosenthal: I see you are not familiar with our topic :p [01:02:21.0410] More seriously, I'm not sure. I know there's at least a WebKit test for this. [01:02:51.0082] annevk: you mean "leave your sense of logic out the door"? yes, familiar with it... hence "I wonder". I don't have a concrete input into this, let me do some research. [01:04:29.0362] Noam Rosenthal: I also wonder what happens in practice for 103 today. Perhaps browsers match Fetch, but maybe only half of them do or some such. [01:07:47.0198] Domenic: I thought we had resolved on https://github.com/whatwg/html/pull/9797 at some point. But maybe I'm missing something. smaug could you confirm/deny my assertions in that issue? [01:24:56.0976] annevk: given that for 3xx response with no Location header but with a response body, the Fetch spec doesn’t explicitly prohibit UAs from processing the response body, and given that there’s also nothing in HTML that prohibits it either, I guess that means UAs can choose to do whichever they want with it (process it or not)? …and lacking any spec requirements around it, it’s not something that can be expected to necessarily behave interoperably? [01:26:24.0556] sideshowbarker: no, then something would have to be explicitly indicated as implementation-defined [01:26:58.0578] sideshowbarker: in this case the response would be returned to the caller as-is, so if you emit a 309 on the server, that's what the caller would see [01:27:28.0852] sideshowbarker: that even holds when there is a Location header, as that's only defined to have meaning for a redirect response, which 309 is not [01:27:40.0033] OK [01:28:33.0063] well the specific context is https://bugs.webkit.org/show_bug.cgi?id=262030 and trying to decide how to resolve that [01:30:03.0732] sideshowbarker: https://html.spec.whatwg.org/#default-fetch-and-process-the-linked-resource suggests that most link elements require an ok status, which means those would end up being rejected [01:30:58.0689] sideshowbarker: stylesheet uses those default steps it seems [01:33:28.0252] ah OK [01:33:58.0268] thanks much [01:37:35.0929] no existing tests for non-OK status in https://wpt.fyi/results/html/semantics/document-metadata/the-link-element, as far as I can see [01:37:52.0461] …but there should be [01:46:27.0679] annevk: I'm not sure that microtask issue has been discussed. Queuing a microtask without an event loop should be fine, since the one can find an event loop anyhow, but when queuing a microtasks, one needs to ensure there is a task in the loop (currently running task counts). [01:47:51.0955] ...which is basically what you say in the initial comment 🙂 [01:50:23.0289] I guess we need a concept of a current task? [01:50:27.0847] smaug: Domenic seems to be saying that it's fine to add a microtask to an arbitrary event loop's microtask queue; I'm not quite able to articulate why that is wrong, but it seems quite wrong as you'd expect microtask order to be consistent within a single task and not have the outside world interfere [01:50:51.0172] smaug: I guess it would violate run-to-completion in some way [01:50:51.0259] > <@annevk:matrix.org> Noam Rosenthal: I also wonder what happens in practice for 103 today. Perhaps browsers match Fetch, but maybe only half of them do or some such. When we designed early hints we explicitly stated that only `Content-Security-Policy` is read and respected, and only for the purpose of the early hint itself. But I'm pretty sure we don't test that all the rest are not respected. For `Set-Cookie`, I would expect it to be not respected at all or respected only for the early hint fetches themselves, but we never spec'ed the latter bashi [01:50:56.0097] nothing would run the microtask [01:51:17.0888] at least given how mictotasks should run [01:51:34.0401] smaug: well in the spec the microtask queue is on the event loop so it would run in the next task or as part of some current task [01:51:36.0938] or does something in the spec somehow trigger the event loop to run [01:51:44.0126] exactly [01:51:49.0893] the next task might never happen [01:52:04.0346] there might not be such [01:52:30.0313] Yeah that's a problem, but it also seems like a problem if it just executes as part of the current task (that might still be scheduling its own microtasks) [01:53:10.0538] annevk: you mean in case of workers? [01:53:27.0481] smaug: for instance, or a cross-site document [01:53:43.0978] scheduling microtasks from outside just doesn't make sense [01:54:11.0704] I mean apparently to some people it does, so we might need more than "just" :-) [01:54:51.0489] well, one can't run microtasks without a task. Isn't that quite clear [01:55:34.0370] so scheduling a microtask which might or might not run, depending on whether there are some other tasks around would be odd [01:58:27.0722] smaug: aah, we have a currently running task on event loop, I can assert that's non-null [01:58:41.0488] that sounds good [01:59:55.0478] I wonder if web animations spec has a bug somewhere, if it doesn't guarantee that there is a task [02:02:48.0649] smaug: I think there are quite a few specs that do this wrong, in part because of the promises guide which also did it wrong [02:03:10.0587] smaug: they just resolve a promise from "in parallel" or some such and hope things work out [02:03:11.0796] ah yes, easy to just resolve a promise at random point [02:03:40.0906] Domenic: ^^ [02:05:49.0367] Noam Rosenthal: makes sense. Thanks! I would expect Set-Cookie to work for the early hint preload fetches as those go through the 2xx and above pipeline. [02:07:23.0073] annevk: I meant that I *might* expect the cookie from the 103's `Set-Cookie` to be sent to the early-hint fetch requests [02:07:25.0463] I wonder if there should be some implicit task created, if there is no task around? Though, I guess that should be created always when resolving a promise in parallel. [02:07:29.0295] ... but we didn't spec that [02:10:56.0395] Noam Rosenthal: ooh I see [02:13:02.0691] smaug: I think especially with in parallel you want to create a task as otherwise the microtask can end up in a random task; like if you do setTimeout and do some promise thingies in there, there shouldn't be microtasks in there from things that happened in other event loops [02:13:50.0771] smaug: making it easier to resolve promises from in parallel though is something we could work on, although it's not that much work to queue a task [02:14:40.0206] yeah, perhaps it is better to just require one to queue a task. That forces the spec author and also reader to think what actually happens. [02:22:43.0165] And also to pick a task queue and such. [03:46:11.0844] Domenic: when the navigation algorithm invokes "prepare to run script" the "currently running task" is non-null? [03:46:39.0480] Domenic: I'll write a small PR for "prepare to run script" to illustrate [05:18:08.0682] smaug: if you're around, has anyone from Gecko looked at `fetchLater()`? [05:19:08.0996] I could use some help getting https://github.com/whatwg/fetch/pull/1647 reviewed, don't think I'll get to it this week. [05:20:46.0857] I was looking at it at some point, when it was still very unclear what was proposed [05:20:55.0169] beacon or fetch later [05:23:41.0247] hmm, I'm probably not super happy with "trigger when document is destroyed" [05:30:07.0731] or perhaps that doesn't mean all the cases? [05:30:38.0405] Like when OS kills a content process to reduce memory usage [05:31:24.0954] smaug: the idea is to hint to the UA to perform this fetch as late as possible, or after a timeout [05:32:11.0081] ... where the timeout is not a DOMTimer (it stays alive regardless of active/visible etc) [05:33:14.0725] it's purposefully left a bit open how this is interpreted in terms of OS integration and situations like "kill due to low memory". [05:37:10.0747] I have a Stack-Overflow-like question. What's a way to rewrite the following whereby "example.unlikely" as input doesn't result in a false-negative? I guess one could hash the input somehow, but that seems really gross? ``` function parseHost(input) { dummy = new URL("http://example.unlikely"); dummy.host = input; if (dummy.host !== "example.unlikely") return dummy.host; return null; } ``` [05:40:29.0142] ``` function parseHost(input) { const false_host = `${uuid()}.unlikely`; dummy = new URL("http://${false_host}"); dummy.host = input; if (dummy.host !== false_host) return dummy.host; return null; } ``` ? [05:41:08.0978] * ``` function parseHost(input) { const false_host = `${uuid()}.unguessable`; dummy = new URL("http://${false_host}"); dummy.host = input; if (dummy.host !== false_host) return dummy.host; return null; } ``` ? [05:42:53.0124] Noam Rosenthal: yeah, I think this is another good reason for adding `URLHost` :-) cc Adam Rice [05:50:56.0848] I wonder how different fetchLater then is vs pagehide + fetch/beacon. [05:52:23.0747] smaug: it's a replacement for beacon. You can't fetch in pagehide because it would be aborted [05:53:12.0889] and we need replacement for beacon because? [05:54:44.0005] smaug: https://github.com/w3c/page-visibility/issues/59 [05:54:52.0293] if pagehide has issues on mobile, doesn't this new thing have too [05:55:19.0862] it doesn't! because you're not relying on JS running at a particular very late moment. [05:56:16.0428] instead, you're saying at an earlier moment "please fetch as late as possible", instead of hoping that at that late moment you'll have JS execution [05:56:30.0977] but you just said that OS killing the process in on purpose left a bit vague [05:56:43.0309] so it is still unreliable [05:57:32.0846] The idea is that that timeout is executed on the network process. however, the whole issue of "killing processes" is not entirely specified [05:57:37.0494] (I'm not saying no to the API, just wondering if we're replacing some old unreliable APIs with a new unreliable API) [05:58:51.0347] it leaves reliability to the browser rather than to the web developer. Of course that doesn't *guarantee* reliability if the implementation drops those fetches [05:59:23.0826] if the OS kills the whole browser, for example, of course some of these will be dropped [05:59:33.0501] right now the reliability of pagehide is also on the browser, not on the web developer [06:03:08.0808] smaug: sure. this came as a shared design discussion between chromium & webkit folks, that making something declarative like this reliable is more feasible than reliably firing `pagehide` [06:03:22.0222] I know [06:03:38.0540] but it is still replacing one unreliable thing with another reliable thing [06:04:14.0979] which just feels a bit silly 🙂 even though it might be in practice good, since the new thing might less unreliable [06:04:25.0668] Reliability is on a sliding scale I guess. [06:04:57.0233] If we treated everything as 100% reliable or 100% unreliable we wouldn't get far. [06:05:27.0156] we tried to design an API that gives the browsers a better opportunity at making these fetches reliable [06:07:44.0071] * but it is still replacing one unreliable thing with another unreliable thing [10:00:52.0193] I find it a bit odd that when parsing HTML null characters are reported twice as errors. Once during tokenization and then again during tree construction. I'd consider the latter to be redundant. Does anybody have some insight/thoughts? [10:22:24.0278] > <@martin:push-f.com> I find it a bit odd that when parsing HTML null characters are reported twice as errors. Once during tokenization and then again during tree construction. I'd consider the latter to be redundant. Does anybody have some insight/thoughts? isn't that because `�` wouldn't be caught during tokenization? [10:26:00.0602] Good idea ... I also thought that ... but no, that is also caught during tokenization: it's a [null-character-reference](https://html.spec.whatwg.org/multipage/parsing.html#numeric-character-reference-end-state:parse-error-null-character-reference) tokenizer error [10:46:18.0758] martin: https://lists.w3.org/Archives/Public/public-whatwg-archive/2013Sep/0063.html suggests it used to be different, might be worth looking at blame [11:21:56.0206] does anyone know what part spec (webidl?) mentions if functions should be async/sync? ie: ```js const asyncFn = (async function() {}).constructor fetch instanceof asyncFn // false ``` thanks! [11:23:27.0768] martin: hmm actually that part is still the same, so blame isn't needed [11:39:35.0560] > <@khafra:matrix.org> does anyone know what part spec (webidl?) mentions if functions should be async/sync? ie: > > ```js > const asyncFn = (async function() {}).constructor > > fetch instanceof asyncFn // false > ``` > > thanks! Look at whether the function returns a `Promise`. Functions can also be async by taking a callback, but that's less common in newer APIs. [11:45:20.0195] @khafra:matrix.org: not every function that returns a promise is an `AsyncFunction`. See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function [11:50:31.0401] ... Not every async[hronous] function is an `async function`. [11:53:42.0062] I could be wrong but I don't think there are WebIDL interfaces that have an `AsyncFunction`, mostly it's regular functions that return promises, like `fetch`. The `AsyncFunction` interface is usually for user code that's written in javascript and uses `async/await` internally rather than a web platform function. Note that a "special" thing about `AsyncFunction` is that it can't throw, only reject promises, and it always returns a unique promise. I guess some web APIs (perhaps even `fetch()`) coincidentally has that guarantee without explicitly being an `AsyncFunction`. [11:54:18.0379] all web APIs that return promises have that guarantee [11:54:25.0558] WebIDL translates exceptions to promise rejections [11:54:54.0617] do they have the other guarantee of always returning a unique promise reference? [11:55:06.0187] I think so, but I'm not sure [11:55:41.0274] well I guess that makes them implicitly an `AsyncFunction`, I don't recall if that interface has other special traits [11:56:39.0480] It's provided by WebIDL, in https://webidl.spec.whatwg.org/#dfn-create-operation-function by "If op has a return type that is a promise type", and I guess by https://webidl.spec.whatwg.org/#es-promise. [11:58:47.0599] from what I'm reading, it seems like as far as WebIDL is concerned, an API function could return an existing promise [11:59:13.0871] I vaguely remember some discussion about that, wrt `[SameObject]` [12:01:51.0774] You'll always get a new Promise from the platform function because even if the method steps return an existing one, it'll get [converted to an ECMAScript value](https://webidl.spec.whatwg.org/#es-promise), which passes it through NewPromiseCapability(%Promise%).Resolve(). [12:02:17.0281] that's when converting an ECMAScript value to a WebIDL Promise [12:02:23.0667] not the other way around [12:02:38.0343] Oops, thanks. [12:03:03.0387] * ~You'll always get a new Promise from the platform function because even if the method steps return an existing one, it'll get [converted to an ECMAScript value](https://webidl.spec.whatwg.org/#es-promise), which passes it through NewPromiseCapability(%Promise%).Resolve().~ <-This was wrong. [12:03:18.0604] * [Edit: This statement is incorrect.] You'll always get a new Promise from the platform function because even if the method steps return an existing one, it'll get [converted to an ECMAScript value](https://webidl.spec.whatwg.org/#es-promise), which passes it through NewPromiseCapability(%Promise%).Resolve(). [12:03:29.0244] * \[Edit: This statement is incorrect.\] You'll always get a new Promise from the platform function because even if the method steps return an existing one, it'll get [converted to an ECMAScript value](https://webidl.spec.whatwg.org/#es-promise), which passes it through NewPromiseCapability(%Promise%).Resolve(). [13:38:22.0654] annevk: in terms of the thing you reviewed with my heading-start -- was it from the other 2018 thread where you had build a pollyfill/proposal? aka https://github.com/whatwg/html/issues/83#issuecomment-369437548 ? [13:42:54.0236] I had a modified version of that polyfill that for the same reason, but yeah I guess that was a different base proposal anyway so I guess I should add an explanation. I hate polluting that issue with more tho, should I open a linked one as like "once we do the other one, then we should do this?" 2023-09-29 [22:28:54.0725] bkardell: yeah a new issue for the follow-up stuff would be great [22:33:52.0746] How high is the barrier to removing redundant parse errors from the HTML spec? I'd assume this should be coordinated with another PR to remove the respective errors from html5lib-tests? [23:43:46.0565] Domenic: so when "prepare to run script" is called the currently running task is always non-null? So it's never called from a microtask? I.e., you cannot get there through calling navigate() from a promise callback or some such? [23:48:29.0462] What's up with the Wattsi builds failing for HTML PRs? [23:48:47.0946] * What's up with the Wattsi server errors for HTML PRs? [23:49:58.0869] martin: what kind of server error? [23:53:30.0174] > <@annevk:matrix.org> martin: what kind of server error? e.g. https://github.com/whatwg/html/pull/9797 or https://github.com/whatwg/html/pull/9809 [23:54:11.0265] > <@annevk:matrix.org> martin: what kind of server error? * e.g. https://github.com/whatwg/html/pull/9797 or https://github.com/whatwg/html/pull/9809 The PR description says: > 💥 Error: Wattsi server error 💥 instead of linking the previews [00:00:15.0826] dbaron: could you please stop at-mentioning folks in commit messages? Unfortunately it's rather spammy. [00:01:06.0682] martin: ooh that's weird, Build is succeeding so I guess there's a PR Preview outage [00:01:56.0866] I wonder if we could run PR Preview through GitHub instead, saving Tobie some resources. [00:03:08.0112] * martin: ooh that's weird, Build is succeeding. Domenic can prolly take a look in a bit. [00:15:51.0540] (for what it's worth I just force pushed the same commit without any content changes and the preview now worked 🤷) [00:17:35.0454] Oh okay, sometimes our hosting provider is a bit flaky. [00:17:52.0884] Neat, https://github.com/whatwg/fetch/issues/new/choose already has an option to report a security vulnerability. [00:24:11.0785] > <@annevk:matrix.org> Neat, https://github.com/whatwg/fetch/issues/new/choose already has an option to report a security vulnerability. I see it in the web UI but not in the GitHub mobile app [00:25:34.0567] And the mobile app still shows the choices in a different order (with the Chat choice first) [00:27:15.0431] File an issue against the app? [00:27:22.0949] (I use the mobile app because I can swipe to mark as done in the Notifications UI) [00:27:35.0650] keithamus might be able to forward it internally \o/ [00:28:26.0290] Oh interesting. I’ll forward to the mobile team [00:28:41.0689] If I did GitHub on mobile my work-life balance would worsen. [00:28:50.0324] I just wish the web-app UI let me swipe. If it did then I'd not have any other use for the mobile app… [00:29:54.0207] But also a lot of what I do is review which even on a laptop sucks due to screen width limitations [00:31:01.0423] Yeah [00:37:57.0249] > <@annevk:matrix.org> Domenic: so when "prepare to run script" is called the currently running task is always non-null? So it's never called from a microtask? I.e., you cannot get there through calling navigate() from a promise callback or some such? The currently running task may be null. The surrounding agent cannot be null. [00:38:20.0874] Hmm I see the problem [00:39:55.0628] Note that this is not navigation API specific. Every Web IDL callback call ends up in "prepare to run script" [00:40:38.0151] I think the spec is not very prepared for the currently running task to be null. We should probably let it be a microtask. [00:41:19.0951] Oh, it's not null during microtasks after all, I was just wrong yesterday: https://html.spec.whatwg.org/#perform-a-microtask-checkpoint [00:41:24.0199] It is null during update the rendering though [00:41:46.0929] Which is maybe why "long animation frames" is a helpful thing to add, even though we are already tracking long tasks? [00:48:37.0288] yea the relationship between tasks and rendering in the HTML spec is science fiction atm [01:16:35.0347] Domenic: someone was suggesting the other day that update the rendering should be a task of its own [01:16:48.0644] Domenic: I guess that would solve this [01:17:06.0164] Domenic: we should also assert currently running task in queue a microtask then [01:17:40.0566] I get kind of upset when people talk about it this way, because the spec is observably equivalent to what browsers do today, and people are just complaining that the spec doesn't match their particular browser engine code. [01:18:35.0357] Like we shouldn't always reflect browser code directly in specs, and I don't like calling specs fiction if they are observably equivalent but don't match specific implementation choices. [01:19:09.0052] But ultimately, fine, if someone else wants to refactor the rendering steps to match how Chrome or Firefox or Safari works, go for it, I guess. [01:21:48.0130] Yeah I'm not sure it's science fiction either, but it does seem problematic that currently running task can be null. [01:32:29.0991] > <@domenicdenicola:matrix.org> Like we shouldn't always reflect browser code directly in specs, and I don't like calling specs fiction if they are observably equivalent but don't match specific implementation choices. Apologies for saying this as a general statement. Was frustrated with this before, we seriously need to address it [01:34:12.0028] The update the rendering steps are different from implementations in two key ways: one is that it's outside a task and the other is that it's unclear where ui events are handled [01:35:31.0202] I mean UI events have been only moderately specified since 1994... if someone wants to fix that I'm definitely rooting for them, but not holding my breath :) [01:39:04.0539] Yeah, we've been frustrated with them for a while. I outlined a plan for fixing them and Gary at one point was going to tackle it, but it hasn't happened. Perhaps you want to give it a go Noam? [01:39:29.0209] I might have to as part of speccing long animation frames [01:44:46.0785] I can't find the issue for this in the uievents repository [01:45:02.0774] There should be one somewhere about defining a proper processing model [01:45:58.0512] this is what I meant when I said science-fiction: UI events are tightly integrated into rendering cycle in implementation, and there is always a task, probably a "rendering task". those two things ARE web-observable (e.g. in longtasks). Wrong choice of words, but I'd happy to try to tackle it. [01:47:23.0019] I think it's https://github.com/w3c/uievents/issues/238#issuecomment-510106422 [01:48:07.0359] We need the abstract algorithms of "user moves mouse", "user presses key", etc. and then bind those to the event loop somehow. [01:58:51.0260] Hmm someone seems to have totally ignored our new issue template https://github.com/whatwg/html/issues/9812 [02:18:00.0167] > <@domenicdenicola:matrix.org> Hmm someone seems to have totally ignored our new issue template https://github.com/whatwg/html/issues/9812 Well the first option is labeled "New issue" ... and the description just says: > File a new issue against the HTML Standard. if you stop reading there you haven't really knowingly ignored anything. The description should probably say something that this shouldn't be used for feature requests. Perhaps "New issues" should be changed to "Report problem" or something like that. [03:00:12.0851] How about "Propose a new feature" and "Report an issue" in that order? [03:09:09.0437] Domenic, annevk: regarding event loop spec vs implementation, according to Ryosuke (at TPAC) webkit doesn't run everything through the event loop so there might be quite a few issues there that would arise if we try to make things more observably interoperable, especially around microtasks [04:20:34.0334] Noam Rosenthal: hmm I thought when I spoke with rniwa he said "update the rendering" was essentially its own task [04:21:11.0622] Noam Rosenthal: scheduling might be different, but everything has to run within the context of the event loop [04:22:40.0724] annevk: "not everything is hooked up to go through that execute loop. We're in the process of adopting that but it's nowhere near complete." [04:23:33.0547] (quoting our chat, as a follow up to the TPAC discussion about long animation frames) [04:24:04.0792] would be amazing if webkit actually had everything in an event loop and could support long animation frames/tasks etc. I was surprised to hear that this is a problem. [04:24:06.0454] Anyway, I don't really see a problem with surfacing more interop issues, they're already out there anyway [04:27:24.0023] Absolutely agree about the value of surfacing, my concern spec-wise is that if we tried to move the event-loop + ui event spec into something more rigorous we'd get webkit pushback because of this kind of issues, so I wanted to surface this with you early. [04:45:24.0911] Noam Rosenthal: it'd be interesting to see a more concrete example of a problem I suppose [04:46:05.0440] Noam Rosenthal: if we need some ambiguity around which events end up in the same task that doesn't seem out of the realm of options per se, but at the moment we don't even have a framework to talk about that kind of stuff [04:47:12.0180] annevk: agreed. [04:47:52.0514] (I don't have concrete examples myself, less familiar of this part of webkit in its current form) [07:07:16.0389] Sigh, the HTML declarative shadow tree PR reached the unicorn level [07:08:58.0735] We should develop these things as monkeypatch specs and only write a PR after there's consensus. ;) [07:16:36.0386] Heh, surely there's a middle ground here somewhere. But it's hard to know upfront sometimes. [08:10:48.0579] TabAtkins: I can't tell if you and I are saying the same thing, close to the same thing, or totally opposite things on that heading levels start thing - would you be interested in figuring it out together and creating a reply/plan (or just new follow up issue as suggested above) that we agree on? [08:15:25.0705] bkardell: as far as I can tell all TabAtkins is asking for recursion when determining `headingstart`; I think it'd be good if someone could determine the perf cost of that is indeed about the same and it doesn't create any problems when you try to optimize things [08:17:01.0359] Yes, that's correct. Given that every heading will have to search to the root anyway to determine its actual level, the only thing you're gaining from avoiding recursion is that *sometimes* you can stop earlier than the root. That's effectively nil perf benefit. [08:17:31.0702] someone™ [08:18:01.0483] in other words the *existence* of this feature already has some (fairly minimal) perf hit. [08:18:08.0497] TabAtkins: well, that's only the first pass, there's also dynamic manipulation and such [08:22:44.0403] feels like we do this with css already, but maybe there is something real tricky there idk [08:25:48.0010] Yeah, I think that still applies. The existence of the feature imposes a (small) cost on maintaining correct heading levels on mutation for *all* pages, regardless of whether they use it. Absolute vs recursive just, at best, avoids ah extra walk to root. [08:27:08.0046] Any perf implications are *worst* for existing pages that don't use the feature at all. Recursive is the *same* cost. Absolute might let you save a tiny amount of effort in some cases, at the cost of the page structure breaking when you nest. [08:30:06.0991] bkardell: doesn't make it free :-) [08:31:59.0987] annevk: I'm trying to find time for the :dir review asap, but curious, is there some particular hurry with that? [08:32:33.0843] smaug: I don't think so, happy to wait [08:33:08.0990] smaug: I guess I was trying to move a bit faster since it's been overdue, but might as well take a bit longer and get it right [08:33:21.0885] sure, it has taken lots of time [08:33:30.0669] but ok,I'll review during the weekend [08:33:59.0700] smaug: please, take your time and just say when you've done it [08:36:39.0241] > <@annevk:matrix.org> bkardell: doesn't make it free :-) I could be wrong (pronounced "am probably wrong"), but I think we have other things which, implementation-wise, lean on internal css properties to do what is basically similar things. [08:37:54.0515] which would at least make it "seemingly affordable" :) [08:51:00.0811] I mean, I guess it is not exactly like anything in css so maybe that doesn't help [08:51:13.0038] * I guess it is not exactly like anything in css so maybe that doesn't help [09:04:18.0047] annevk: what part of Fetch specifies that the response status for `file:` URLs ends up being 0? [09:12:42.0447] sideshowbarker: "For now, unfortunate as it is, file: URLs are left as an exercise for the reader. When in doubt, return a network error." [09:12:50.0649] sideshowbarker: that's not defined behavior [09:13:17.0336] We should make that more clearly "implementation-defined". 2023-09-30 [22:12:59.0406] Hi. In investigating implementation details for SFNSP I noticed an interop issue. 1. In only Firefox, with existing selection, after clicking on a fragment link, selection is cleared. In Safari and Chrome the selection stays and can be keyboard interacted with. 2. In Firefox and Safari, when focus changes, selection is cleared. In Chrome the selection stays. Does this warrant a WPT or perhaps a clarifying issue in HTML on what should/shouldn't happen? [22:14:36.0352] I think it is known that there is a connection between focus and selection in some browsers but not others, and this is an interop issue but also one that browsers feel is kind of a quality differentiator. [22:15:13.0342] https://github.com/whatwg/html/issues/7657 [22:15:35.0641] https://github.com/whatwg/html/issues/7759 [22:16:19.0035] If Chrome is the odd one out, maybe it's worth asking the relevant people if they want to change. But my impression was that Chrome thought it was better for users to have these concepts be separate, and the spec allows them to be separate. [22:17:18.0052] This is a similar interop issue to how, e.g., Safari chooses to make lots of controls not-focusable by default, and the spec allows that. [22:21:45.0351] I see. Thanks. [00:13:09.0027] Is there a way to style an element differently based on the scroll position in CSS? E.g., once the end user has scrolled down for x pixels, style the element differently? [02:55:56.0617] > <@annevk:matrix.org> Is there a way to style an element differently based on the scroll position in CSS? E.g., once the end user has scrolled down for x pixels, style the element differently? I think that requires some JavaScript. (rightfully so ...) [02:57:33.0618] Is there a name for the HTML elements that were created by the parser because the didn't exist? (only happens for html, head and body) [03:04:59.0783] * Is there a name for the HTML elements that were created by the parser because they didn't exist? (only happens for html, head and body) [03:07:34.0080] * Is there a name for the HTML elements that were created by the parser because they didn't exist? (only happens for html, head and body, p, colgroup, tbody and tr) [03:07:41.0415] * Is there a name for the HTML elements that were created by the parser because they didn't exist? (only happens for html, head, body, p, colgroup, tbody and tr) [03:14:31.0862] > <@martin:push-f.com> Is there a name for the HTML elements that were created by the parser because they didn't exist? (only happens for html, head, body, p, colgroup, tbody and tr) To answer my own question: I guess "implied elements" [05:45:35.0687] does summary count [05:59:15.0439] > <@muan:matrix.org> does summary count I guess not, if the criterion is “created by the parser” — because default `summary` isn’t created by the parser [06:01:01.0245] > <@martin:push-f.com> Is there a name for the HTML elements that were created by the parser because they didn't exist? (only happens for html, head, body, p, colgroup, tbody and tr) in the conceptual model for HTML those elements do exist in the document — it’s just that their start tags and end tags are omitted in the source markup [06:03:07.0483] When is `

` implied? [06:03:32.0172] Also, today I learned you can omit the first ``, though I guess that's non-compliant? [06:04:09.0673] > <@annevk:matrix.org> Also, today I learned you can omit the first ``, though I guess that's non-compliant? yeah, as far are document conformance [06:04:13.0594] > <@annevk:matrix.org> Also, today I learned you can omit the first ``, though I guess that's non-compliant? * yeah, as far as document conformance [08:01:55.0406] > <@sideshowbarker:matrix.org> in the conceptual model for HTML those elements do exist in the document — it’s just that their start tags and end tags are omitted in the source markup right, of course [08:02:22.0275] > <@annevk:matrix.org> When is `

` implied? for `

` in body if it wasn't opened previously [08:02:32.0748] > <@annevk:matrix.org> When is `

` implied? * for `

` in body insertion mode if it wasn't opened previously [08:12:09.0080] > <@annevk:matrix.org> Is there a way to style an element differently based on the scroll position in CSS? E.g., once the end user has scrolled down for x pixels, style the element differently? Yes: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_scroll-driven_animations [09:37:30.0168] hey mi friends [09:37:55.0017] some body is hacking my pc and phone please help me [09:38:25.0858] pleaseee [09:39:25.0676] i access here just because im clicking and cliking [09:40:38.0251] its all ready like 2 monts i trying to block or eraese this people from mi acounts [09:40:51.0140] they ha access to all my info [09:40:55.0881] plaseeeeee [09:41:12.0185] im beging you gus [09:41:16.0443] guys [09:44:02.0274] all ready lost my job for this delincuents [09:48:32.0985] Im desesperate PLEASEEEE [10:05:27.0533] REALLY NOBODY? [10:05:59.0549] they supost to be white hats or something like that [10:08:21.0247] i dont know what is all this [10:41:54.0183] wow so are the same ???