[css-forms-1] Shouldn't all buttons be replaceable with custom content?

[mfreed7]

This was discussed a bit in #11847, but I think it's a much more general question for all of appearance:base, so I'm opening this issue.

From #11847:

Also, what if a developer wants tO replace the ::file- selector -button with their
own custom element button?

How common is this?

Most customisations I've done in the past were essentially hiding the label entirely and then making the button an icon (like a paper clip) which I think the pseudo would allow provided I could set the content to an empty string (with an alt fallback value) and using background-image.

It seems somewhat common for design systems to have a standard "button" component. And it also seems natural to want to use that component for all "buttons" that users see.

As an example, here is the demo page for the Angular Material button component:
https://material.angular.io/components/button/overview

If you click on any button there, you'll see the "ripple". In Material, when you click a button, a colored "ripple" expands from the clicked point outward, to visually indicate the click back to the user. To implement that, the Material button component has about 5 <span>s inside, used for various purposes. One <span> renders the visual effect, and another <span> is used for click detection. Others render the label and focus/hover styles, etc. I'm not sure how that would be done with just a single pseudo element button? It's possible that the same (or close) behavior could be engineered into just CSS styles on the pseudo element, but that still requires each design system to "redesign the wheel" twice, once for the standalone <button> that uses arbitrary HTML content, and the other for the system provided pseudo element buttons.

I'd also point out that the very first appearance:base(-select) control, <select>, has a button, and we decided to make it fully-replaceable with arbitrary HTML. I'm not sure why we wouldn't follow that pattern with the rest of the appearance:base control designs?

These controls would seem to have button-like things:

• <select> (done, with arbitrary HTML supported)
• <input type="file"> ("pick file" button)
• <input type="number"> ("up" and "down" spin buttons)
• <input type="date|time|etc"> ("clear" button, "today" button, "picker" button)
• <input type="button|reset|submit"> (actually a button itself)
• <input type="search"> (“clear” button)
• <input type="password"> (“reveal” button, "clear" button)

Perhaps we just want to punt on allowing customization of all of these buttons, but I thought it at least warrants a specific discussion first.

[sorvell]

I agree this would be extremely useful, and it could possibly help pave the way to future customization of popup content, for example, inside input type color, date, and time.

It seems challenging v. <select> since <input> cannot have children, but perhaps <datalist> could be used, or perhaps another element could be added with a similar association.

[mfreed7]

It seems challenging v. <select> since <input> cannot have children, but perhaps <datalist> could be used, or perhaps another element could be added with a similar association.

This is precisely why I'd like to have this conversation now, and not do all of this work to improve stylability of these controls only to have to invent new controls or new mechanisms later to "fix" the lack of replaceable content.

[fantasai]

I'd also point out that the very first appearance:base(-select) control, <select>, has a button, and we decided to make it fully-replaceable with arbitrary HTML. I'm not sure why we wouldn't follow that pattern with the rest of the appearance:base control designs?

The reason is that these other controls don't have HTML internals. If HTML provides them with internals, then CSS can style that. But until then, and for cases where it's not necessary to modify the markup, being able to style these components through CSS is still desirable.

Note that ::file-selector-button in particular has existed for years.

[mfreed7]

The reason is that these other controls don't have HTML internals. If HTML provides them with internals, then CSS can style that. But until then, and for cases where it's not necessary to modify the markup, being able to style these components through CSS is still desirable.

I would just encourage us to think about these problems holistically, and not just from the "what can we change in CSS, keeping HTML constant" perspective. If things need to change in HTML to make a control usable and great for developers, let's do that!

[css-meeting-bot]

The CSS Working Group just discussed [css-forms-1] Shouldn't all buttons be replaceable with custom content?.

The full IRC log of that discussion

<lwarlow> q+
<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
<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.
<jarhar> masonf: some design systems have buttons, like angular. its a very complicated thing with animations and hit testing
<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
<jarhar> masonf: i think the idea here is to let people use the existing form controls
<jarhar> masonf: css-forms is a css spec, but it should be fair game to talk about html too
<jarhar> masonf: customizable select did this, a lot of behavior that changed in html. maybe we should do that where needed for other controls
<past> q?
<jarhar> annevk: this means theres still a lot of confusion about what these things are
<jarhar> annevk: we could have done appearance:base for select without semantic changes
<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
<jarhar> annevk: we have to figure out how it works for auto and none anyway
<jarhar> annevk: if appearance base comes after that, then we have to figure that out
<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 ?
<jarhar> annevk: there was big confusion about the select element from google about this
<jarhar> annevk: this part we change in the semantics layer, and this part is in the parser
<jarhar> annevk: you could ship them separately
<past> ack lwarlow
<jarhar> annevk: i dont know why we keep revisiting this idea that html and css co evolve in lock step
<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
<jarhar> lwarlow: we could have done this afterwards, and we could have done them separately
<jarhar> lwarlow: maybe for 95% of these controls, its not as important as the parser changes for select
<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
<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
<jarhar> do this now. maybe it solves the use cases enough
<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.
<jarhar> ntim: unnecessarily complex pattern for simple use cases
<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
<jarhar> ntim: i think it would be good to teach the simple thing first before the more complex way of doing things
<jarhar> ntim: i agree with anne that they are mostly independent
<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
<jarhar> masonf: in desiging them together, simple and compelx things are doable
<jarhar> masonf: for file input if you expose the pseudo now and compose later then ?
<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
<jarhar> masonf: i dont know a system where you design half and then design the other half
<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
<jarhar> angular is correct
<jarhar> annevk: it would be wrong if these things are so dependent as we suggest. that means we can never enhance the semantics
<jarhar> annevk: we want to continue to evolve these controls
<jarhar> annevk: in the next 5 years, if they actually have to be designed at the same time then theres something wrong
<jarhar> annevk: wouldnt it be bad if it required a new appearance value?
<jarhar> masonf: luke said it best. wouldnt it be a good idea to think about both halves?
<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
<jarhar> masonf: im not blocking it
<jarhar> annevk: i think its fine to discuss it, but it seems like its blocking appearance base

[mfreed7]

Just to make sure it's very clear, I'm not trying to block any part of the css-forms-1 work. In fact, I think @nt1m has done a great job with that spec, and we generally like the shape of things, as they've been evolving. @dbaron has a plan to start prototyping a few of the new appearance:base controls this year, to help with the effort. I was only trying to say that changes to HTML shouldn't be off the table, if they could improve the situation for developers and users. But those changes to HTML don't need to block anything, and can be additive.