1305297 - Make <button> element easier to style reliably for authors

Status: RESOLVED DUPLICATE of bug 984869

(Core :: Layout: Form Controls, defect)

Description

[Florens Verschelde :fvsch]

This is a generic bug but I’ll try to pinpoint specific issues as well.

Context: the recommendation for web sites and applications for clickable interactive elements is to use either <a href> (for interactive elements that take you elsewhere, and possibly for toggling the visibility of in-page elements) or <button> (most cases).
There has been a number of tweets and articles on this topic by web developers and accessibility experts. See for instance:

- "Just use button - A11ycasts #05" https://www.youtube.com/watch?v=CZGqnp06DnI (Google's Rob Dodson, ChromeDevelopers channel)
- "Semantic HTML: The Unbearable Rightness of Being" https://medium.com/shopify-ux/semantic-html-the-unbearable-rightness-of-being-9b3c493e1791 (describes differences between a clickable DIV, a link and a button)
- There's some debate on which cases call for a button or which would work better with an internal link (when toggling a block's visibility): https://adactio.com/journal/10475

Bottom line is that authors should be able to use either <a href> or <button> almost interchangeably, depending on the exact semantics to convey.

Which brings us to one reason why this doesn't happen in most code I've seen written by non-accessibility experts: <button> is too hard to style.

This bug is about removing one or more styling hurdles that affect <button> elements in Gecko (who is a bit more troublesome than other engines in that respect). If that’s deemed a worthwhile goal, maybe it could be used as a meta bug.

SPEC REQUIREMENTS

Looking at https://html.spec.whatwg.org/multipage/forms.html#the-button-element I don’t see particular requirements for the rendering of buttons.
In https://bugzilla.mozilla.org/show_bug.cgi?id=733914#c2 Boris Zbarsky writes:

> The correct rendering depends on whether a button is a replaced element or not.
> In Gecko and Presto it is, apparently.  In Trident and WebKit it's not, apparently.
> The HTML spec does not define whether it's a replaced element or not, so both
> renderings are allowed by the spec....

AUTHOR EXPECTATIONS

This would need a real survey but from my experience as the technical lead of a small team of front-end developers, we would expect:

- a default, platform-specific style for <button>
- a simple way to fall back to a less magical, bare-bones CSS rendering (with default styles equivalent to `display: inline-block; width: max-content;`)
- ability to remove or override border, background, padding
- ability to change the display value to: block (useful for full-width buttons), table, table-cell, flex, inline-flex (useful for layout out content inside the button, for instance an icon + text)…

Again, back to the context re. accessibility, I agree with Anthony Ricaud in https://bugzilla.mozilla.org/show_bug.cgi?id=984869#c5:

> the more restrictions we put on <button>, the more authors will use workarounds that might be less accessible.

That's my experience in my team, where I say "Use button" and teammates reply "but it doesn't work!"

I understand that not everything can be changed; there are constraints (e.g. a working `display:inline` would create major regressions). But the more things can be smoothed out, the better.

CURRENT ISSUES IN GECKO

Major: display: flex doesn't work for button elements
https://bugzilla.mozilla.org/show_bug.cgi?id=984869
(Web compat issue.)

Major: Gecko adds extra padding inside buttons
https://bugzilla.mozilla.org/show_bug.cgi?id=140562
https://bugzilla.mozilla.org/show_bug.cgi?id=654225
+ many duplicated
Workaround documented in e.g. http://fvsch.com/code/button-css/
This is not awful since there is a workaround, but the result is that half the code in a CSS reset for <button> targets Firefox specifically. And most developers will not know this fix (hence the duplicates), and will often write off the <button> element as impossible to use for “pixel-perfect” results where you want some links and buttons to use the same style and align correctly.

Medium: cannot dimension an absolutely positioned button with e.g. `left:0;right:0`
https://bugzilla.mozilla.org/show_bug.cgi?id=733914
Workaround is using width(+calc), but when you have already styled a <a> element the first way and you replace it with a <button>, the design breaks.

Minor: `display:block;width:auto;` doesn't work.
One has to force `width:100%`, which is an issue when swapping a <a href> for a <button> or the other way round.

At the very least, fixing the extra padding (::-moz-focus-inner) and the display:flex compatibility would go a long way to improving webcompat and making authors more confident when using <button>.

Comment 1

[Mats Palmgren (inactive)]

Thanks for your bug report, I agree with you that web developers
should use the HTML form controls rather than rolling there own.
Unfortunately, the W3C standards say very little regarding styling of
form controls so there's not much any single UA vendor can do there.
It would be better if you contact the W3C HTML/CSS working groups
directly instead to advocate standards improvements for that.
Bugzilla isn't the right forum for that.

Anyway, I don't see anything actionable other than the bugs you
point out, that are already on file.
A `display:block;width:auto;` button works the same in Edge, Chrome
and Firefox, so I don't think this is something we can change
for web compatibility reasons.  Also, I suspect the current
rendering is actually what the CSS2.2 spec requires.

So, I'm closing this bug since the issues you list are already
on file.  In the future, please don't file "generic bug"s like
this.  It's better if you file one report for each specific bug
you find (assuming it's not already filed).
Thanks.