| 08:37 | <annevk> | TabAtkins: did you end up finding anything? |
| 09:32 | <keithamus> | annevk: I believe I've addressed your latest feedback in https://github.com/whatwg/html/pull/9841. I was wondering if you think you'll have time this week to review the PR? Would be awesome to see it progress |
| 10:27 | <annevk> | keithamus: I did another pass. Looks like zcorpan also spotted some test-related things. |
| 10:30 | <keithamus> | annevk: Right. As I understand it zcorpan has confirmed it's not possible for us to test the expanded state. We don't alter the role or accname so we have no need to test that. |
| 10:34 | <annevk> | keithamus: ah right. But the state of https://github.com/web-platform-tests/wpt/pull/42664 is unclear. Left a comment there. |
| 10:44 | <keithamus> | annevk: okay I've pushed some changes to the spec around your commentary, I think I added button attributes to the right index. Please let me know if I missed another spot 🙏 |
| 10:51 | <keithamus> | annevk: I also followed up here: https://github.com/web-platform-tests/wpt/pull/42664#issuecomment-2665277023. I failed to properly reply to your comments before but AIUI everything is good to go with the WPT tentative PR. |
| 12:20 | <zcorpan> | Not sure what to make of this error https://github.com/whatwg/quirks/actions/runs/13389769434/job/37396534098 (cc TabAtkins ) |
| 12:31 | <Ms2ger> | I think it's Florian Rivoal 's change: https://github.com/speced/bikeshed-boilerplate/commit/123d968f7615d7d38675028666f97d587e7d6ea5 |
| 12:32 | <Ms2ger> | I suspect it should be type="ab", not type=ab |
| 12:55 | <annevk> | keithamus: Luke Warlow: did you look into an Auto state for <button type>? I think it would make things much clearer. |
| 12:57 | <Luke Warlow> | As in for the spec or as a new value the button type would reflect to? (Either way it's not something I've personally considered much but Keith has been doing most of the spec side of this feature) |
| 12:59 | <annevk> | For the specification. Because then we don't have to check that the type attribute is present or not. And we don't have the weird case of a Submit Button not being a submit button. |
| 13:00 | <annevk> | And as far as I can tell there's very few callers of this state to begin with. |
| 13:00 | <annevk> | I've suggested it a few times before, but I think I'm going to ask that as the final change as I really think it would make the button element much clearer. |
| 13:09 | <annevk> | Oh also, zcorpan do you have time to do a pass on that command PR once that change is in? I've done a lot of passes and I'm starting to worry I'm missing things. |
| 13:09 | <annevk> | Or maybe Domenic or foolip? |
| 13:14 | <keithamus> | annevk: How do you anticipate the auto state helping clarify things? I think it would change the criteria for when it's a submit button but it seems like algorithms would just change to using the auto state, likely resulting in more checks and logic, no? |
| 13:22 | <annevk> | keithamus: where we now check for Submit Button and not command/commandfor; we can check for Auto and not command/commandfor; where we check for the type attribute and it being in the Submit Button state, we can just check for the Submit Button state; the type getter can start using the canonical keyword (but needs handling for the Auto case); I don't think anything else is impacted. To me this seems like a solid improvement. |
| 13:24 | <annevk> | And it's more aligned with how we treat similar cases elsewhere. If the default is actually "it depends", we don't pretend it's one of the other states and use some kind of side channel (such as attribute presence) to cope. |
| 13:29 | <keithamus> | annevk: I've pushed up a new commit with the auto state; let me know if this aligns with what you're thinking |
| 13:29 | <keithamus> | it changes the submit button prose, and the type getter per your above comments |
| 14:01 | <annevk> | keithamus: thanks, I'll take a look. I think those are the only places as everything else already used the lowercase submit button per earlier refactor |
| 14:04 | <annevk> | Yeah looks good. It seems like foolip started reviewing while that was still in process unfortunately, but hopefully that's easily sorted. |
| 14:16 | <keithamus> | Thanks for you work reviewing annevk, much appreciated. Likewise foolip! I believe I've tackled your recent comments sufficiently so ready for another round whenever you have time 🙏 |
| 15:03 | <TabAtkins> | TabAtkins: did you end up finding anything? |
| 15:03 | <TabAtkins> | Just got distracted playing civ 7 and didn't push the update |
| 15:03 | <TabAtkins> | (yesterday was a us holiday) |
| 15:27 | <annevk> | TabAtkins: so everything that is an IP address will need escaping? |
| 15:28 | <annevk> | TabAtkins: can you check in some regression test that ensures it will always remove the escape correctly? Perhaps that's already covered. I'm rather worried about these Markdown parsing rules changing and messing with my document. |
| 15:38 | <TabAtkins> | No, just the very few things (I think maybe just one) that start with [: |
| 16:06 | <Greg Kuruc> | Hi, I have a question about the spec. I think what I'm trying to do might not be possible. We're trying to monitor usage of window.postMessage calls for security auditing. We do similar things elsewhere where we override the prototype to add our logging and then call the original function. We can't do that with window because the window already exists so we override the window object itself. However, we're having issues doing this for postMessage because what happens is the message source on the event listener always comes from the same source because you're always overriding the same function no matter what frame you're coming from. So when we override it, the source is always going to be whichever overrode the function first. Okay, so I'm trying to work around this problem but I don't know if there is a way because what I need is the incumbent window but there's no way for me to know what that is, I only have the current window in JS. Is it possible I'm missing something or does this not seem possible. I wonder why it's not just |
| 16:27 | <TabAtkins> | annevk: Okay, new version pushed. With it, it now cleanly reports an error (a [:...:] autolink that's unclosed) in three spots; those'll need escaping. It also spotted a missing </code>, which I confirmed is a correct detection. |
| 16:28 | <TabAtkins> | I do have several tests for shorthands and markdown already, but I can go ahead and make them a little more exhaustive. |
| 16:29 | <TabAtkins> | Alternately, instead of escaping you can turn off that autolink category: Markup Shorthands: http no |
| 16:58 | <annevk> | Thanks for the suggestions, I'll investigate what solution to go with. Prolly tomorrow. |
| 16:59 | <annevk> | smaug: when you have a moment, https://github.com/whatwg/dom/pull/1268#issuecomment-2656686537 could use your input. (I also put up a fix for the attribute's node document problem.) |
| 17:12 | <smaug> | annevk: yes. I'll try to look at that and see if it matches what was very recently implemented in Gecko (behind a pref still) |
| 17:56 | <annevk> | smaug: note that Daniel is proposing a change so I kinda doubt it fully matches that. |
| 17:56 | <annevk> | TabAtkins: so now CI is giving me Python exception traces: https://github.com/whatwg/dom/pull/1360 |
| 17:57 | <TabAtkins> | that was just fixed in the bikeshed-boilerplate repo a few minutes ago |
| 17:59 | <TabAtkins> | yeah, landed in bikeshed-data 35 minutes ago, so just kick the PR again |
| 17:59 | <annevk> | Okay. I'll re-run. |
| 18:00 | <annevk> | Great, it indeed seems to work now. (Haven't tried URL yet, I guess I'll re-run that now too.) |
| 18:00 | <TabAtkins> | that one is on me, i don't have a CI check in place for bikeshed-boilerplate that ensures the doctypes file parses, so a commit last night broke it |
| 18:00 | <TabAtkins> | (not from me, at least) |
| 18:01 | <TabAtkins> | yeah you should have 4 errors in URL - three autolink false-positives, and one missing end tag |
| 18:07 | <annevk> | Thanks, yeah, that was easy to resolve now: https://github.com/whatwg/url/pull/858 |
| 18:07 | <annevk> | \o/ |
| 18:37 | <keithamus> | annevk: you mentioned in the Web Components f2f that the specs for Scoped CE registries were perhaps out-of-date? What's the current source of truth for the latest work? Is it the tests inside of WebKit? Do you know if there's a timeline for getting them exported back into WPT? |
| 20:46 | <Noam Rosenthal> | Greg Kuruc: I don't know how to answer your specific question, but https://github.com/WICG/Realms-Initialization-Control comes to mind as an emerging proposal for this sort of issue |
| 21:48 | <Greg Kuruc> | Thanks so much! I'll take a look! |