| 09:29 | <zcorpan> | Psychpsyo: ok thanks |
| 11:09 | <zcorpan> | Dominic Farolino: ping https://github.com/whatwg/html/pull/11560#discussion_r2338608768 |
| 14:04 | <Jake Archibald> | Does anyone know why eg button and form cannot have shadow roots, or was the allowlist deliberately conservative? |
| 14:41 | <annevk> | Jake Archibald: it is conservative, yeah. I'm not sure how much interest there is to extend shadow roots for non-custom elements though. I think in retrospect we should only have had shadow roots for custom elements. Would have allowed for a better design overall, but it's always easier with hindsight. |
| 14:45 | <Jake Archibald> | annevk: I'm looking at the use-cases in https://bsky.app/profile/jakearchibald.com/post/3lzxy7um7q22h and also thinking of Shopify's use-case for a custom form component. It feels like these could be easily solved by <button is="blah-whatever"> and allowing shadow roots on those elements. Maybe the original pitch for is was too broad, but it feels like it works for these cases. |
| 14:46 | <annevk> | WebKit isn't interested in is. |
| 14:46 | <Jake Archibald> | yeah |
| 14:47 | <Jake Archibald> | (although I hadn't quite realised that position was immutable) |
| 14:48 | <annevk> | I regret not pushing back on it harder at Mozilla when it ended up in the build. Only Google kinda liked it at standardization time. |
| 14:48 | <Jake Archibald> | Aside from the no-JS-fallback use-case, allowing a custom element to inherit button/form in a way that picks up all behaviour would also work. That would certainly be preferable to Shopify because the DX doesn't suddenly change from "yes it's <s-textbox> but for forms it's <form is="s-form">" |
| 14:49 | <Jake Archibald> | Is that DOA? If I interpreted the standards position correctly, WebKit was more interested in that |
| 14:50 | <annevk> | Yeah, the questions there are "what is all that behavior?" and "does everyone want all that behavior or do they only want those bits they are thinking of right now?" |
| 14:50 | <annevk> | Domenic had a pretty insightful post on it a couple weeks back. Let me find that thread. |
| 14:50 | <Jake Archibald> | Yeah, that's why I was asking in places like https://bsky.app/profile/jakearchibald.com/post/3lzxy7um7q22h |
| 14:51 | <Jake Archibald> | It seems like people want focus, and all attributes & properties to behave as is. That's certainly what we wanted for forms at Shopify. Having it for buttons would be nice too. |
| 14:51 | <annevk> | https://github.com/whatwg/html/issues/11061#issuecomment-3213526709 |
| 14:57 | <Jake Archibald> | That's fair. Yeah, and if folks are 'extending' HTMLButtonElement etc, it makes it harder to add to those APIs in future. |
| 15:01 | <Luke Warlow> | WebKit isn't interested in |
| 15:03 | <annevk> | Luke Warlow: certainly from WebKit, but that's insufficient as per https://whatwg.org/working-mode#changes. I suspect Mozilla is unwilling to touch it at this point unless Chrome does something and Chrome seems happy to keep it. |
| 15:08 | <Luke Warlow> | I guess the alternative is to add some notes that show that but I don't know how many Devs actually read the spec even the for Devs view and MDN does actually have a note on it, so perhaps that's the most we can do for now. |
| 15:27 | <Jake Archibald> | I guess it'd be nice to dig down into what a 'button' mixin would look like. There are certainly things like reflection helpers that would be useful elsewhere. |
| 15:30 | <Jake Archibald> | Making reflection & form input properties work like other HTML elements was a tricky thing at Shopify |
| 15:31 | <Jake Archibald> | eg the interaction between value & defaultValue |
| 15:32 | <Luke Warlow> | For reflection I recently did think we perhaps should add a "retarget" function that you give an element and it well retargets. Perhaps the ability to provide an array of shadow roots to allow "leaking"? That would help custom elements provide similar element reflection properties but also provide other APIs that do retargeting. |
| 15:33 | <Jake Archibald> | I was thinking more low-level, like "reflect this attribute as a number". But maybe we need decorator support to do that well |
| 15:33 | <Jake Archibald> | At Shopify we used decorators |
| 15:34 | <Luke Warlow> | I was thinking more low-level, like "reflect this attribute as a number". But maybe we need decorator support to do that well |
| 15:35 | <Luke Warlow> | Retarget could be useful for custom event setups separately though |
| 15:39 | <annevk> | It's worthwhile trying to think through those things again to see if we have the necessary building blocks, but ultimately those are capabilities developers already have today. They are just awkward. Whereas making a custom element focusable in the same way as a button or text input is something that's not possible today. |
| 15:40 | <Luke Warlow> | It's worthwhile trying to think through those things again to see if we have the necessary building blocks, but ultimately those are capabilities developers already have today. They are just awkward. Whereas making a custom element focusable in the same way as a button or text input is something that's not possible today. |
| 16:39 | <Noam Rosenthal> | curious to see a userland "behaves like a button" mixin effort with posting HTML issues when things are missing from the platform in ElementInternals or whatever... I think it would be a productive way to make built-in extends an actual thing |
| 17:23 | <Luke Warlow> | curious to see a userland "behaves like a button" mixin effort with posting HTML issues when things are missing from the platform in |
| 17:23 | <annevk> | Luke Warlow: yeah, there is an issue that goes into the various modes one would have to pick from. I believe there's four modes, but we couldn't quite figure out the precise naming at the time. And the proposal lost steam for one reason or another. |
| 20:36 | <Psychpsyo> | As a web dev, I tried making a custom element that extends <dialog> before. (which is when I learnt that extending builtins isn't really a thing) My current 'workaround' is a regular custom element that I put into a <dialog> manually every time I use it. |
| 21:05 | <cwilso> | Hey gang! Hi! At our last triage meeting, I took an action item to look into what the most effective schedule of meetings should be. Please respond to this poll - should only take a minute or two. (I also sent this in email) https://forms.gle/NvQKHGDPVSd6MebX7 |