1539469 - Make <input> elements display: inline-block by default (was: Fix WPT: testing/web-platform/tests/html/semantics/forms/the-input-element/input-width.html)

Status: RESOLVED FIXED

(Core :: Layout: Form Controls, enhancement, P3)

Comment 1

[Mirko Brodesser (:mbrodesser-Igalia)]

If src="someExistingPicture.gif", width can be changed as expected.

Comment 2

[Boris Zbarsky [:bzbarsky]]

What's going on here is that we are giving the input an inline frame (because it's falling back to alt text), which does not allow width styling.

In terms of the spec, per https://html.spec.whatwg.org/multipage/input.html#image-button-state-(type=image) the input "represents a submit button" (because there is no src attribute). Then https://html.spec.whatwg.org/multipage/rendering.html#images-3 is the relevant spec that applies. I guess for the input case it's always expected to be a replaced element whose content is the text involved... I wonder whether we can use a button control frame here or something, since that's what the spec is really pushing for.

Comment 3

[Boris Zbarsky [:bzbarsky]]

it's always expected to be a replaced element whose content is the text involved

When it's not representing an image, that is.

Comment 4

[Emilio Cobos Álvarez (:emilio)]

Perhaps. It probably wouldn't be too hard, though it likely requires a bit of fiddling to get the forms.css rules right.

Looks like this test just works in Blink / WebKit because all inputs are inline-block by default, that may be another (maybe more compatible) way to go about this, wdyt?

Comment 5

[Boris Zbarsky [:bzbarsky]]

It's observably different from the spec in terms of how absolute positioning works (because it works differently for replaced vs non-replaced).

I'm fine using non-replaced inline-block here, if everyone else does, but then we should get the spec fixed.

Comment 6

[Mirko Brodesser (:mbrodesser-Igalia)]

The inline-block solution is blocked by two newly discovered bugs (see dependencies). As this bug seems to belong to the layout component, Emilio, does it makes sense to move it?

Comment 7

[Emilio Cobos Álvarez (:emilio)]

Yeah, that seems reasonable to me.

Comment 8

[Mirko Brodesser (:mbrodesser-Igalia)]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #7)

Yeah, that seems reasonable to me.
Thanks, also for the link. Interesting!

Comment 9

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1539469 - Make all input elements display: inline-block, for compat with other UAs. r=dholbert,mats

See https://github.com/whatwg/html/issues/4082 for the data and some comments
from Boris and David.

I didn't look into fixing the font-inflation reftests, see bug 1540176 for that.

Comment 10

[Mats Palmgren (inactive)]

BTW, can you file a Chromium bug regarding the flex layout they are currently using for some of their form controls?
I.e. they should add input { display: inline-block } in their UA sheet like we now have, and they shouldn't "leak" their internal child boxes even if you override it like data:text/html,<input type=date style="display:flex;flex-flow:column">.

Comment 11

[Emilio Cobos Álvarez (:emilio)]

I filed https://bugs.chromium.org/p/chromium/issues/detail?id=970249.

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d0be9ca49bd7
Make all input elements display: inline-block, for compat with other UAs. r=mats

Comment 13

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/d0be9ca49bd7