[forms] Make <input type=button> magic clip not magic

[emilio]

What is the issue with the HTML Standard?

<input type=button> forces overflow: clip on their contents, but "magically".

I propose we remove that magic and instead add:

input:is([type=button], [type=reset], [type=submit]) {
  overflow: clip !important;
}

To the UA stylesheet in the spec here.

That would allow other features like text-overflow: ellipsis to also work, see https://bugzilla.mozilla.org/show_bug.cgi?id=1800077 / https://bugs.chromium.org/p/chromium/issues/detail?id=1383144.

[emilio]

cc @zcorpan

[zcorpan]

The current text says

https://html.spec.whatwg.org/#form-controls

For input elements where the type attribute is not in the Hidden state or the Image Button state, and that are being rendered, are expected to act as follows:

• The inner display type is always 'flow-root'.
• The 'overflow' property is ignored, and always behaves as 'visible' for the purpose of interaction with other CSS features (in particular, the 'vertical-align' property), but still clips any overflow at the border edge, and no scrolling mechanism is displayed.

Would vertical-align be affected by changing to 'clip'?

cc @whatwg/rendering

[emilio]

I don't think so, no.

[emilio]

And clearly given the bugs linked above the overflow property isn't completely ignored, either...

[zcorpan]

https://www.w3.org/TR/CSS22/visudet.html#propdef-vertical-align

The baseline of an 'inline-block' is the baseline of its last line box in the normal flow, unless it has either no in-flow line boxes or if its 'overflow' property has a computed value other than 'visible', in which case the baseline is the bottom margin edge.

My understanding is that if the computed value of 'overflow' is 'clip' then the baseline is the bottom margin edge, which isn't what we want for buttons (or form controls in general).

https://html.spec.whatwg.org/#form-controls has

input, button {
  display: inline-block;
}

Maybe the spec for vertical-align could be changed so that form controls are exempt from the baseline change based on 'overflow'?

[zcorpan]

Demo: https://software.hixie.ch/utilities/js/live-dom-viewer/saved/12199

It seems WebKit/Chromium/Gecko don't honor CSS 2.2 wrt the above-quoted text about where the baseline should be. (WebKit and Chromium also use the first line instead of the last line for multi-line buttons, but that's a separate issue.)

[emilio]

CSS2 is not the thing to follow here, see w3c/csswg-drafts#6212.

[zcorpan]

Ah, thanks! Then yes, I think switching to overflow: clip !important should work.

The only change to the suggested CSS in OP would be to use the i flag.

[emilio]

type is case insensitive in html elements iirc, but doesn't hurt to be explicit I guess

[mfreed7]

This seems like a reasonable change to me. If I'm reading the comments correctly, changing to overflow: clip !important would seem to "just work" and would unblock other features like text-overflow.

[josepharhar]

chrome issue for this: https://bugs.chromium.org/p/chromium/issues/detail?id=1513949

ah nevermind, we already have this: https://bugs.chromium.org/p/chromium/issues/detail?id=1383144

[MrHBS]

I always thought <input type=“button”> was soft deprecated.