[csswg-drafts] [css-forms-1] Shouldn't all buttons be replaceable with custom content? (#11929)

mfreed7 has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-forms-1] Shouldn't all buttons be replaceable with custom content? ==
This was discussed a bit in https://github.com/w3c/csswg-drafts/issues/11847, but I think it's a much more general question for all of `appearance:base`, so I'm opening this issue.

From https://github.com/w3c/csswg-drafts/issues/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.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11929 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 12 March 2025 21:26:59 UTC