2026-11-01 [01:25:02.0817] I could have sworn I checked that before filing an issue. Turns out to be the test issue as I found out. Will update the test and confirm it works in other browsers, thanks! [12:15:34.0471] Hello, no idea if this is the correct chat to ask this question in: I'm looking for the commit history of the `https://html.spec.whatwg.org/robots.txt` file. I'm currently trying to figure out how some files denied by the current one made it into my search index. [12:16:01.0541] * Hello, no idea if this is the correct chat to ask this question in: I'm looking for the commit history of the `https://html.spec.whatwg.org/robots.txt` file. I'm currently trying to figure out how some files denied by the current one made it into my search index. Any pointer to where the correct place to ask it are appreciated. 2026-11-02 [22:17:17.0943] It's generated: https://github.com/whatwg/whatwg.org/blob/main/resources.whatwg.org/build/deploy.sh#L144-L148 [23:00:45.0518] Thank you! [05:55:04.0660] smaug: can I land https://github.com/whatwg/dom/pull/1470 now? Not sure where we left that. I'd like to do another PR on top that will make it possible for us to use "live range" for both Range and OpaqueRange. Mainly by switching some "live range" usage to use Range instead. [05:55:47.0578] let me check in 1h [06:34:08.0742] Stephanie Zhang: for the OpaqueRange HTML PR I posted AI-generated feedback which looked accurate to me. I also left some suggestions on the DOM PR. I think we probably want to refactor a bit more so we don't need "live range and opaque range" changes everywhere; I can work on that. It also seems like the CSSOM and Highlights API changes are not yet up-to-date? They still talk about associated elements and such... [08:57:00.0688] smaug: I replied to your comment. [13:33:48.0799] Thanks for the reviews and I appreciate you taking on the live range changes! CSSOM and Highlights API changes are out of date (wanted to get the HTML and DOM specs in a more finalized state before doing another overhaul). Will update back when they've been revised and gone through the AI spec skill [14:33:18.0786] * Thanks for the reviews and I appreciate you taking on the live range changes! CSSOM and Highlights API changes are out of date (wanted to get the HTML and DOM specs in a more finalized state before doing another overhaul). Will update back when all specs been revised and gone through the AI spec skill 2026-11-04 [19:54:30.0672] TabAtkins + all: I’ve added a CI cron job in the HTML checker repo that runs twice day, building Bikeshed output with https://www.w3.org/publications/spec-generator/ and then running against the checker to make sure it has no errors. [19:56:50.0448] That way, I can hopefully get alerted to checker breakage before any spec editors do — or at least at around the same time any editors might start running into it — and start right away on fixing the checker before more editors are affected. [19:57:56.0904] Context is that yesterday, both the WebExtensions and WebDriver spec builds broke because the Bikeshed output had some CSS stuff that I hadn’t yet taught to the checker. [19:59:02.0247] …And I only found out about it because of getting Cc‘ed on issues from those spec repos. [19:59:39.0173] * Context is that yesterday, both the WebExtensions and WebDriver spec builds broke because the Bikeshed output gained some CSS stuff that I hadn’t yet taught to the checker. [00:23:00.0588] smaug: ping on the OpaqueRange cleanup PR. Also, I briefly looked at menu elements yesterday and it seems that at least `menuitem` also looks at its parent for behavior branching. In particular for `submenu` it will do act more like a button. Was curious what you made of that. [01:16:26.0721] yeah, I'm still thinking if that is the right model for custom element case [01:16:46.0745] where boundary points should be all internal [01:17:13.0076] and exposed offsets could be anything [01:27:17.0663] oh, I guess the pr is fine with that [01:31:12.0578] Yes the PR allows for that [01:32:22.0285] I'm not sure why Stephanie Zhang didn't spec the custom element variant immediately, but I did check `OpaqueRangeController` can be done on top of her (and my) work and afaict it fits. [01:33:36.0444] zcorpan: very exciting to see progress on ORB again. AI found a couple of things. Would be nice to finally get it merged. [05:59:18.0500] annevk: yep! farre and I are working through it. Will continue tomorrow. Thanks for the ai review [06:01:09.0737] Looks like I'll need to open a new PR for the Participation check, but I'll do that later [06:26:10.0518] Done, comments are editorial [06:31:24.0484] Very nice. I need to link to this in my book [06:32:54.0901] The illustration in https://htmlparser.info/parser/ looks almost the same :) [06:34:08.0355] As a community member who contributes to web standards because of the community feeling: it makes me sad to see human interaction fade away with more and more of my PRs to web standards reviewed only by AI. It removes the human aspect of the "web community" for me and makes it less enjoyable to contribute and more of a chore. I don't get paid to do this, so my own motivation keeps me going. AI reviews don't help with that. No need to start a whole debate about this. Only wanted to share my current feeling and needed to write it in a place where I know humans read the actual stuff. Thanks for reading humans, would love to continue reading your not-so-perfect sentences. Please continue your day as you were planning to. [06:40:35.0003] Does it work for the tree builder? [06:44:41.0315] asuth: we need to reimplement the spec PR preview thing to have something like the searchfox view. Could support stacked PRs maybe! And ability to leave review comments from that view [06:51:19.0475] Tim van der Lippe: I wish there was a way that would both catch the various nuances and still make it feel like a collaboration. [06:52:19.0039] (Your contributions haven't gone unnoticed to me, FWIW. They're very valuable.) [06:55:53.0037] Aye. Perhaps it's wishful thinking but I hope that this is a transition period that is going to converge on machines catching more nuances and humans spending a larger percentage of the time discussing design choices [08:45:39.0282] I don't know exactly what Tim van der Lippe is experiencing in terms of AI reviews... but maybe one approach that might make it AI reviews feel less awkward is if the infrastructure for them is automated and shared so that they're more like a lint that runs automatically on people's PRs at a stage that's separate from human review? [08:52:21.0719] This was discussed at TPAC and we are actively investigating how to fund/orchestrate something like this. [09:05:43.0644] Tim van der Lippe: thanks for raising it. For https://github.com/whatwg/html/pull/13057 the remaining feedback is editorial; I can push fixes for those. I'll think about this and see if I can adjust to avoid the dry AI review friction [12:02:44.0291] Maybe we can make the review skill first focus on behavior and normative changes, and present options for fixes (if appropriate), and just note editorial review and nits is for later. We can then discuss those issues and the merits of each option. When there are no more design decisions or normative issues, it switches to an editorial only review and fix loop, with verification that it didn't change the normative behavior. (Editorial cleanup first could be on-demand.) If the editorial fixup finds new non-editorial issues, it raises them as new open questions. I think this could work both locally (for contributors and editors) and on shared infra. [12:27:22.0704] ship it [13:22:57.0626] I wrote a long prompt [13:24:15.0704] wpt review should probably live in the wpt repo [14:22:25.0197] https://github.com/whatwg/spec-ai/issues/8 [15:52:39.0519] https://github.com/whatwg/spec-ai/pull/9 , with the skill used to review itself. Many found defects/questions means a wall of text, but contributors can run it locally and address defects before opening the PR. And yes I realize this is still AI review, but I think this flow allows for better collaboration. 2026-11-05 [16:18:07.0544] My experience in other open source projects is that it's easier and nicer for contributors if I just have my AI fix the review issues, instead of having my AI talk to them (or often to their AI) and do a round of iteration. Probably the right balance here would be to have the reviewer auto-push any AI-generated editorial fixes, and leave substantive reviews as comments. [16:18:54.0814] Oh I didn't know about this repo, I would have self-run it on my recent PRs if I had known. [16:19:41.0020] It's pretty new [16:24:05.0151] https://github.com/whatwg/spec-ai/blob/main/skills/html-spec-review/html-style-guide.md is so cool [16:25:41.0400] Domenic: agreed on editorial fixes. Substantive comments can still be many issues. Unclear if it's better to let the AI push fixes for those too (unless something clearly needs a design decision), or have a strict editorial/substantive split where the latter is posted as a comment (with proposed fix or fixes). [16:58:42.0651] After testing the flow in #9 I think defects with 1 clear fix should be fixed directly, and a comment summarizing what changed and why (with short shas). At least for local, where the reviewer can edit locally before pushing and posting. Questions with options can have fixes on other branches. [17:35:16.0299] zcorpan: I'm definitely interested in improving what searchfox is doing there and it's great if it can be helpful. I can definitely crank up searchfox proactively importing pull requests/etc. and could support a web hook or other mechanism if whatever robot is already doing stuff wanted to be able to confidently generate searchfox links that definitely exist and are already populated (or will be imminently populated if it doesn't want to wait for the async ingestion). Searchfox actually is already doing some patch stack-aware stuff under the hood, but it's not really materialized in the rendered view, although at least overlapping PRs will have the redunant bits suppressed. (That is, https://github.com/whatwg/fetch/pull/1941 contains a push from https://github.com/whatwg/fetch/pull/1940 in it and searchfox then tries to supress showing the duplicated content that's in 1941.) [17:37:32.0984] The review comments situation looks like it is a little tricky in the sense that it sounds like searchfox or any other tool on a different origin can't just generate a POST at github with a pre-computed "please have the user confirm they want to make the following review comments", but instead need something like: - Have the user paste in a token that has the right access rights (which might be tricky) and the server claims it won't retain. - Have the server be a GitHub app/do an OAuth thing. (searchfox currently doesn't do this, but I guess it could). - Have there be a helper web-extension so that the searchfox server or third-party server doesn't have to be trusted, although then the web extension does have to be trusted. [17:39:44.0148] I'm definitely interested in your thoughts on the review aspect in terms of what you'd be comfortable with or you think people would be comfortable with. Also, I'm not saying any infra needs to directly involve searchfox. Or it could involve searchfox but searchfox wouldn't necessarily need to be the front-end. It would be fine if searchfox could help some other tooling leverage searchfox's token-centric blame history (which is the main potentially non-trivial source of pre-computed data searchfox has that might be expensive to run elsewhere and needn't run elsewhere). [01:09:29.0638] I think this looks really good. Is it ready to land? [02:03:25.0198] sfarre: I've been looking at the Reporting API mess and what the fallout might be of not supporting toJSON() and just using proper dictionaries and it seems like the fallout is small to non-existent enough to just ship it. I'll leave a reply on https://github.com/w3c/reporting/issues/216 once I have an actual WebKit patch. I also plan to update the WPTs at the same time which would make Chromium and Firefox fail. [02:06:37.0256] I would be fine with that, and having something to follow would also make it easier for me implementing it in firefox. I can't recall what the tests actually does, but how would we and chrome fail? asserts on the types of the reports or something maybe? [02:09:16.0984] I think some worker tests will fail because the object would not be structured cloneable. And I will add historical tests to ensure these are not interfaces and don't have toJSON(). [02:11:54.0506] ok, cool! yeah cleaning this stuff up is overdue [04:49:12.0437] zcorpan: will you ping me when I should take another look at the ORB thing? The updates look okay, but at least the comment in the HLS issue made it sound like there's still some work remaining. [05:27:53.0690] annevk: Right, OP now has an updated todo list. I'll need to continue tomorrow, no need to review yet. Thanks [05:28:32.0665] I think the important bits are done tho [14:12:22.0315] asuth: thinking about it again, probably *not* paste a token or OAuth because the content is untrusted (the PR can self-XSS the pr preview). It could maybe integrate somehow with spec-pr-review skill (wip) by giving you text to copy or save to a file that the skill can use for sending the feedback or continue to iterate on fixes before leaving comments. [14:14:26.0970] Thanks. Not yet [14:58:03.0324] zcorpan: Yeah, if there's something running locally on the machine or co-operating somewhere quasi-publically on the web, there's a variety of options there. * Download a JSON that can later be posted back to the preview site to iterate. * Let the user configure some iframe that can be loaded and speak a limited postMessage API back out again where the skill is providing the contents of that iframe and using websockets or something to talk to itself. (I guess this would be an inside-out WebMCP that could also just be WebMCP if that ends up being a thing.) [15:58:14.0939] I just hit https://github.com/whatwg/webidl/issues/895. This is kind of bonkers to me. I'd like to solicit implementation interest in fixing it; I can volunteer to do the work of spec text and WPT and bugs and everything. [15:59:13.0077] Everything in JS is very careful to call IteratorClose when finishing with an iterable; not doing so means you don't run cleanup that users are going to expect to always run (especially with the new `using` syntax). 2026-11-06 [16:35:22.0650] Given browsers already disagree here it seems like a good thing to fix. I agree WebKit's behaviour does seem much better here. [21:21:30.0963] ok, starting with a PR; if anyone can speak for Chromium or FF and is willing to commit interest I'd appreciate it and will then go write tests https://github.com/whatwg/webidl/pull/1662 [23:42:05.0376] Seems sensible [01:07:50.0824] cc Tobie Langel since you made and maintain(ed?) PR preview :) PR preview is already very useful as-is (people notice when it stops working lol), but this is just brainstorming possible improvements [01:15:29.0477] Anyone interested in background-fetch have opinions for https://github.com/WICG/background-fetch/issues/183 ? [01:20:20.0570] (It's not blocking ORB) [02:16:44.0296] I let Youenn know about it. I kinda think that as long as it's well-defined it's probably fine. [04:10:03.0900] Not done yet. Will continue next week [04:25:40.0869] annevk: foolip : see https://github.com/whatwg/fetch/pull/1755#:~:text=Needs%20input%20from%20Chromium%20or%20WebKit [05:51:56.0525] Thanks for taking my concerns seriously, I appreciate that. [06:03:46.0290] I replied to some of these. For media formats I’m still not quite sure what to do. Obviously we need to add those user agents ship today, but adding new formats seems dumb as it just increases the number of bytes that leak. Drawing a line in the sand and requiring explicit opt-in seems better, even if it means new formats have to be even better therefore. [06:04:34.0516] That might also be a benefit as it would slow down adding new formats except when it really counts.