| 10:38 | <Luke Warlow (OoO until 12th)> | https://github.com/whatwg/html/issues/12441 - I've opened an issue to form a proposed agenda for this meeting. I'm happy to help facilitate this on-site but if there's specific process steps people would like to follow just let me know. On the specific date and time we have flexibility so can accomodate WHATWG needs on this. |
| 12:18 | <annevk> | I'm curious if people have thought about how they want AI with standards? Having pointed Claude at some PRs it seems it could greatly assist in self-review before a human has to look at things. Not everyone has the means for that of course and I'm happy to assist where not, but the majority of contributions come from places that should be able to do self-review with the best models at max settings. |
| 12:22 | <bkardell> | Thinking about adding a suggested md with a prompt? Or ...? |
| 12:31 | <annevk> | I could see us setting up a repository or repurposing an existing repository to share some agents/commands/plugins, but also just interested in learning where people are at with this. |
| 12:54 | <bkardell> | But you're saying just as a practice and not as something that runs automatically against a PR with initial feedback? |
| 13:00 | <annevk> | I'm trying to find out what people would like. CI might be tricky without some kind of sponsor. What GitHub has seemed rather underwhelming to me, but maybe that has improved as well? |
| 13:04 | <Luke Warlow> | I'm curious if people have thought about how they want AI with standards? Having pointed Claude at some PRs it seems it could greatly assist in self-review before a human has to look at things. Not everyone has the means for that of course and I'm happy to assist where not, but the majority of contributions come from places that should be able to do self-review with the best models at max settings. |
| 13:16 | <annevk> | Luke Warlow: https://github.com/whatwg/html/pull/11687#pullrequestreview-4259029281 was all from a Claude review that I manually verified before leaving comments. No errors (as far as I could tell). Same for a couple of select-related PRs I was looking at and a bunch of nits it found in the DOM PR for processing instructions. I don't want to be in the business of verifying a Claude review however. I'd rather be in the business of reviewing the actual change once all the issues are out of the way. |
| 13:19 | <annevk> | A year ago AI couldn't even figure out how to look at source without going out-of-memory, but these days it's really quite impressive. |
| 13:20 | <jjaschke> | annevk: shameless plug for webspec-index, which should make this more efficient. Since a few days ago it supports --pr for extra fun |
| 13:22 | <annevk> | Luke Warlow: as another example, I have a command locally now for modernizing IDL member prose. https://github.com/whatwg/html/pull/12432 is the first thing I created with it. I reviewed it, but also needs someone else to take look at it. Which reminds me, we probably also want a (lightweight) AI policy. |
| 13:58 | <jmdyck> |
I've been looking at linting/typechecking the HTML spec (see https://github.com/whatwg/html/issues/10483), though without using AI. Whether linting is feasible depends on what you mean by linting. With type-checking, I think the main problem is that there isn't a uniform syntax for invoking an algorithm, so there's no easy way to find the extent of an invocation, or the arguments to it. I still think it's possible (without lots of syntax on top), but it might be messy/over-specific. |
| 14:00 | <Luke Warlow> | Slightly tangential but I often do wish that all specs just had the same syntax. Just the other day I was looking at HTML, MathML Core and SVG and they're all written so differently. I imagine that would make this kind of formal syntax for better machine checking harder. |
| 14:03 | <Ms2ger> | What, no ecmarkup? :) |
| 14:03 | <jmdyck> | (Oh, also, there isn't a uniform syntax for 'declaring the data structures / data types', but I'm not sure how much of a problem that is yet.) |
| 14:04 | <Luke Warlow> | Off the top of my head there's HTML (its own thing), Bikeshed markup (DOM uses this I think), bikeshed shorthand (e.g. trusted types) respec (e.g mathml) and then I think SVG is its own thing entirely again. ...and then also ecmarkup yes but that feels acceptable as tc39 is its own thing. |
| 14:15 | <Luke Warlow> | FYI: https://github.com/web-platform-tests/wpt/pull/59794 |
| 14:19 | <annevk> | It should be easier than ever (but still a lot of human work) to make specifications uniform. I'm not sure where HTML using BIkeshed is at, but that would be a big step. |
| 14:20 | <annevk> | I haven't thought too long about Exposed=*, but at least one thought I had is that as a decision it's somewhat standalone from ShadowRealm, but if nobody implemented Worklet support for these types we might well have to revisit those annotations. |
| 14:29 | <annevk> | To the other point above, I think to the extent we can improve our prose and make it more uniform so we can use scripts on it more easily we should. And if we have improvements for the existing linting at https://github.com/whatwg/whatwg.org/blob/main/resources.whatwg.org/build/deploy.sh we should make those changes there. AI is great, but it's also a huge resource hog so anything we can do to just make things better overall we should absolutely try to do. |
| 15:20 | <Noam Rosenthal> | I personally use AI a lot to self review, but it's easy to forget to run it in the course of a back and forth on a particular PR so I miss things. Having this as some sort of non-intrusive part of the spec review process could potentially be very useful. |
| 15:21 | <janvarga> | annevk: When you have a moment, could you take a look at https://github.com/w3c/IndexedDB/issues/494 ? (not sure if @RupinMittal and @beidson got notified about it) |
| 15:53 | <annevk> | janvarga: did you see https://github.com/w3c/IndexedDB/issues/493? The specification is rather nonsensical in places. I think we might have implemented from the tests... |
| 21:53 | <Luke Warlow> | Would anyone mind if <area> got a type and hreflang attribute added to it that were essentially no-ops (the same as <a>), reason I ask is because HTML <a> and SVG <a> both have them, so it seems good to add it to MathML <a> but for the mixin that would also apply to HTML <area>? |
| 21:57 | <Dominic Farolino> | Most event names are present tense, despite representing actions that happened in the past. Exceptions to this are DOMContentLoaded and some SW events, and maybe other one-offs. Do we want to keep this up? If I introduce a new event name whose firing notifies script that something happened, should it be present or past? Past is more logical IMO, but I guess inconsistent with what we already have. |
| 22:08 | <bkardell> | can you cancel the event Dominic Farolino ? |
| 22:09 | <Jeffrey Yasskin> | FWIW, this seems helpful as long as the AI reviews happen in private. I've had trouble when someone has a long PR thread with Copilot and then wants me to review the result. Or worse, they send me a PR, and then cc me on the whole back-and-forth with the LLM. |
| 22:12 | <Dominic Farolino> | No because the thing already happened. It's purely notification |
| 22:13 | <Luke Warlow> | I would still lean towards using present tense. Like the "close" event and "toggle" event, and many others that are task delayed and non-cancelable. |
| 22:14 | <bkardell> | yeah I was just curious. I would lean toward present, but it seems like the sort of thing there should be solid advice about somewhere for sure :) |
| 22:17 | <bkardell> | I guess https://github.com/w3ctag/design-principles/issues/280 was a start, but didn't get there yet |
| 22:21 | <bkardell> | I guess this is still draft but recommends present tense https://github.com/w3ctag/design-principles/pull/592/changes#diff-5e793325cd2bfc452e268a4aa2f02b4024dd9584bd1db3c2595f61f1ecf7b985R2406 |
| 22:24 | <Dominic Farolino> | Ah thanks for finding that! I was about to file one of my own, so that's good to see. |