| 09:52 | <foolip> | annevk: I've implemented https://github.com/whatwg/html/pull/12428 but think there's still a problem. Adding and removing the muted content attribute will affect the muted IDL attribute and :muted pseudo-class, but never fire the volumechange event. I've now implemented a different approach which is closer to the original behavior. Instead of a default muted state that reads the content attribute, there's an unset or initial muted state. Adding the content attribute would set the muted state to true, which could happen once. That would be the only observable change to .muted or :muted that doesn't fire a volumechange event. WDYT? |
| 10:08 | <foolip> | I also tried an approach where the muted content attribute is checked on insertion, but couldn't discern an upside compared to reacting to attribute changes directly. It would mean that the order of setting the attribute and inserting in scripts would matter, which isn't a good property to have. |
| 10:48 | <annevk> | foolip: I mentioned it not firing the volumechange event last time and I thought we agreed that was fine because we also don't fire it for playing backwards. |
| 11:23 | <foolip> | annevk: not firing the volumechange event for parser-created elements was my focus for https://github.com/whatwg/html/pull/12428, but when I implemented it I didn't make :muted invalidate when the content attribute is added/removed. Fixing that ends up requiring a "don't fire the event" flag to the internal muted state setter, since that's the only thing that shouldn't happen. But having added that, I think it's closer to the original behavior that the muted content attribute has an effect only once, which limits the "don't fire the event" case to when the content attribute is added to an element that hasn't had its muted state touched by something else already. So the parser case and cases where scripts set the attribute on a fresh element. cloneNode() works without special cloning steps since it sets the attribute. |
| 13:34 | <annevk> | foolip: I think an "ignore first set" behavior is rather magical. |
| 13:41 | <annevk> | smaug: ping regarding https://github.com/whatwg/dom/pull/1433. Will update OP now. I also created some tests at https://github.com/web-platform-tests/wpt/pull/60053 but everyone passes them so... |
| 14:03 | <smaug> | looking |
| 15:08 | <annevk> | keithamus: why does WPT expect data:text/html,<select><button>Foo</button><option>One</option></select> to render One? |
| 15:09 | <keithamus> | Because it is in auto appearance. |
| 15:10 | <annevk> | keithamus: that doesn't make sense to me. auto appearance can't impact the semantics. |
| 15:11 | <foolip> | annevk: https://github.com/whatwg/html/pull/12473 is how I think it should work. If you think it's worse then we should loop in Gecko and WebKit media people and see what they think. |
| 15:13 | <keithamus> | Is it semantics? AIUI there are two labels, and one is display:none in appearance:base, the other is not, and vice-versa. The user supplied button is only displayed in base styles. |
| 15:13 | <annevk> | keithamus: yes of course it is. There's no styling whatsoever in my example. That what it represents would change based on appearance makes no sense. |
| 15:14 | <annevk> | That also means that <selectedcontent> would not work in auto appearance. |
| 15:15 | <keithamus> | I mean, it works, but it's not displayed AIUI. |
| 15:16 | <annevk> | I don't think that's okay. We shouldn't have new markup features that only do something if you also add some styling. |
| 15:17 | <keithamus> | Yeah I agree. But the new markup features don't only do something if you add styling, they still operate, they're just styled to not be displayed. |
| 15:17 | <annevk> | That's not how auto appearance works. |
| 15:18 | <annevk> | That might be your particular implementation, but auto appearance is pretty much a blank canvas implementations can decide what to paint in. |
| 15:19 | <keithamus> | So you're saying auto should remain implementation defined? That's fine. I think there may be some work to do to assist that, though |
| 15:19 | <annevk> | I think we should all agree that we render the button text instead of the option text when there is a button. The spec should require that. |
| 15:20 | <keithamus> | We might request jarhar speak to the webcompat of that also. I don't know if there exists <select><button> in the wild, which may be why the first child is not visible in all apart from appearance:base. |
| 15:23 | <annevk> | If that's the case we need some other element I guess. I filed https://github.com/whatwg/html/issues/12474 |
| 15:28 | <annevk> | keithamus: I'm surprised you seem completely fine with this given that you wanted semantics to match elsewhere. |
| 15:30 | <keithamus> | I don't consider this to be a semantic issue, but one of styling. If what you're referring to me wanting to match elsewhere is the interaction with popovers (https://github.com/whatwg/html/issues/12099) then that to me is a usability issue which is far more important/concerning than a semantic issue. |
| 15:31 | <annevk> | I still can't wrap my head around how this is possibly a styling issue. |
| 15:33 | <keithamus> | Well, it is undeniable that appearance:base is a stylistic mode switch, and the display of elements is stylistic, and so there are two labels: the UA supplied and the custom button. The appearance:base stylistic mode switch displays one and not the other. |
| 15:34 | <annevk> | There's not two labels? Semantically there's only one. |
| 15:35 | <keithamus> | I fail to see how that can reconcile with an implementation defined auto mode, though. |
| 15:36 | <annevk> | In much the same way we reconcile rich text options by only rendering their text content? This is not rocket science. |
| 15:37 | <keithamus> | FWIW my preference would be that the UA supplied label live inside the default slotted content, so that a button slotting overrides it. That's still two labels, but that does have a semantic distinction (the semantics of default slotted content). That doesn't reconcile with what's specified though, and has some very unfortunate edge cases with e.g. writing modes. |
| 15:39 | <keithamus> | IIRC it would require something really strange like all:inherit on the slot or at least enough to allow it to adapt to writing modes from the parent select without requiring the user to respecify it all on the button. |
| 15:41 | <annevk> | I don't really understand all the slotting discussion. That is in fact a rendering detail. |
| 15:44 | <annevk> | At a conceptual level you have a select and that has an associated button text or some such. Normally that's always derived from the selected option, but when there's a button element it's derived from that. |
| 16:55 | <Ana Sollano Kim> | Thanks Noam Rosenthal for bringing the Platform-provided behaviors for CE explainer up here. I'm OOO so just caught up. I want to clarify a couple of things. I do have reservations on doing something like because we have a real use case where a design system wants to have only one class that represents a custom button and apply different behaviors (only once) at run time. I don't see how that would be possible. Bundle size is an issue for them, so they don't want to have three different classes for different types of buttons. If that weren't a real use case, my first option would just be to propose JS mixins, but since that's an inherent disadvantage it's not really an API shape that we ended up pursuing. Also, to be clear, we're not proposing input type again, I did write that explicitly in the explainer. Because once you call attachInternals once, that's it, you can't change it. And you can't get around the disabled attribute to "disable" |
| 17:50 | <Lea Verou> | Re: the OpaqueRange offsets discussion today, I wrote up a proposal for the idea I suggested in the meeting, since I don't think I explained it well at the time: https://github.com/whatwg/html/issues/12475 |
| 19:27 | <Noam Rosenthal> |
|
| 19:37 | <Noam Rosenthal> | (as in, it would be good to understand why that matters given that the behaviors are anyway immutable after they're set. it feels a bit like an arbitrary design decision of a particular author/library |
| 19:47 | <Luke Warlow> | It's also a bit arbitrary to design around their requirements compared to someone who say wants fully dynamic type attribute handling (which is currently my preference to enable). |
| 19:48 | <Noam Rosenthal> | agreed. at the very least it can be claimed that making it fully static like formAssociated is simpler |