- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 17 Apr 2025 16:02:10 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-forms-1] Shouldn't all buttons be replaceable with custom content?`. <details><summary>The full IRC log of that discussion</summary> <lwarlow> q+<br> <jarhar> masonf: the reason i wanted to discuss this here is because there are a couple things - issues against css-forms-1, they are things that affect html and css<br> <jarhar> masonf: in the context of buttons, some of the buttons that are in the proposal, like the button in the file picker, are not replaceable with content. you cant put your own html <button> in there.<br> <jarhar> masonf: some design systems have buttons, like angular. its a very complicated thing with animations and hit testing<br> <jarhar> masonf: if were redesigning all the form controls, you should be able to use a button from a design system, or hide the control and build it from scratch<br> <jarhar> masonf: i think the idea here is to let people use the existing form controls<br> <jarhar> masonf: css-forms is a css spec, but it should be fair game to talk about html too<br> <jarhar> masonf: customizable select did this, a lot of behavior that changed in html. maybe we should do that where needed for other controls<br> <past> q?<br> <jarhar> annevk: this means theres still a lot of confusion about what these things are<br> <jarhar> annevk: we could have done appearance:base for select without semantic changes<br> <jarhar> annevk: if we wanted the input type file button to be replaceable, youd have to put a button somewhere in the tree and make the input reference it. it doesn't have anything to do with css<br> <jarhar> annevk: we have to figure out how it works for auto and none anyway<br> <jarhar> annevk: if appearance base comes after that, then we have to figure that out<br> <jarhar> annevk: use this layout tree with appearance base. theyre not intertwined in the way you suggest. one is about styling and one is about ?<br> <jarhar> annevk: there was big confusion about the select element from google about this<br> <jarhar> annevk: this part we change in the semantics layer, and this part is in the parser<br> <jarhar> annevk: you could ship them separately<br> <past> ack lwarlow<br> <jarhar> annevk: i dont know why we keep revisiting this idea that html and css co evolve in lock step<br> <jarhar> lwarlow: they dont have to be intertwined. we could have done appearance base select and not done the parser and replaceable buttons, but it wouldnt have solved use cases<br> <jarhar> lwarlow: we could have done this afterwards, and we could have done them separately<br> <jarhar> lwarlow: maybe for 95% of these controls, its not as important as the parser changes for select<br> <jarhar> lwarlow: i dont think its wrong to think about html composability while we do this. especially because it does have an impact about how appearance:base is defined for some of these controls<br> <jarhar> lwarlow: one solution is that we do have command invokers now, you can have buttons do things declaratively. for the file picker, you could just have a way to say heres a button, it calls showpicker on the other one. using css and customizability of file inputs now, you could hide it and put the other thing in its place. anchor positioning lets you<br> <jarhar> do this now. maybe it solves the use cases enough<br> <jarhar> ntim: one of the reasons i wanted this discussion to happen after is because if we introduced composability now and people start using that before they use pseudo elements, then youre essentially teaching a bad pattern for simple use cases.<br> <jarhar> ntim: unnecessarily complex pattern for simple use cases<br> <jarhar> ntim: it would be nice if what we have now came out and people start using them widely and then see where the gaps are if there still are some<br> <jarhar> ntim: i think it would be good to teach the simple thing first before the more complex way of doing things<br> <jarhar> ntim: i agree with anne that they are mostly independent<br> <jarhar> masonf: in select thats exactly one of the things that we designed it together. you can design some parts of the in page control or replace its content<br> <jarhar> masonf: in desiging them together, simple and compelx things are doable<br> <jarhar> masonf: for file input if you expose the pseudo now and compose later then ?<br> <jarhar> masonf: angular is going to jump through a lot of hoops to make their ripple effect happen with the pseudo element, but if they have the composability now then its going to be much easier for them to implement<br> <jarhar> masonf: i dont know a system where you design half and then design the other half<br> <jarhar> annevk: i dont think its like that. enhancing the semantics of the element is different from making things stylable. theyre not tied into appearance base. if appearance base already exists, then how does it this impact the layout tree that we have. we could have done that with select, and i dont think your argument about how its difficult for<br> <jarhar> angular is correct<br> <jarhar> annevk: it would be wrong if these things are so dependent as we suggest. that means we can never enhance the semantics<br> <jarhar> annevk: we want to continue to evolve these controls<br> <jarhar> annevk: in the next 5 years, if they actually have to be designed at the same time then theres something wrong<br> <jarhar> annevk: wouldnt it be bad if it required a new appearance value?<br> <jarhar> masonf: luke said it best. wouldnt it be a good idea to think about both halves?<br> <jarhar> annevk: the issue i have is blocking the work that were putting into appearance base with the idea that it needs to be developed with new semantics<br> <jarhar> masonf: im not blocking it<br> <jarhar> annevk: i think its fine to discuss it, but it seems like its blocking appearance base<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11929#issuecomment-2813435602 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 17 April 2025 16:02:11 UTC