Closed Bug 1539469 Opened 7 months ago Closed 5 months ago

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

Categories

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

enhancement

Tracking

()

RESOLVED FIXED
mozilla69
Tracking Status
firefox69 --- fixed

People

(Reporter: mbrodesser, Assigned: emilio)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

Attachments

(1 file)

No description provided.
Assignee: nobody → mbrodesser

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

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.

Flags: needinfo?(emilio)

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

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

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?

Flags: needinfo?(emilio)

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.

Depends on: 1540176
Depends on: 1540180

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?

Flags: needinfo?(emilio)

Yeah, that seems reasonable to me.

Component: DOM: Core & HTML → Layout: Form Controls
Flags: needinfo?(emilio)

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

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

Assignee: mbrodesser → nobody
Assignee: nobody → emilio

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.

Summary: Fix WPT: testing/web-platform/tests/html/semantics/forms/the-input-element/input-width.html → Make <input> elements display: inline-block by default (was: Fix WPT: testing/web-platform/tests/html/semantics/forms/the-input-element/input-width.html)
Priority: -- → P3
Blocks: 1546389
No longer blocks: wpt.fyi-firefox-fails

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">.

Flags: needinfo?(emilio)
Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/d0be9ca49bd7
Make all input elements display: inline-block, for compat with other UAs. r=mats
Status: NEW → RESOLVED
Closed: 5 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla69
You need to log in before you can comment on or make changes to this bug.