Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Default 'display' value for form controls #4082

Open
zcorpan opened this issue Oct 10, 2018 · 29 comments

Comments

9 participants
@zcorpan
Copy link
Member

commented Oct 10, 2018

Test: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/6270

Element Chrome Firefox Edge Safari
<select></select> inline-block inline-block inline-block inline-block
<button></button> inline-block inline-block inline-block inline-block
<input type=text> inline-block inline inline-block inline-block
<input type=search> inline-block inline inline-block inline-block
<input type=tel> inline-block inline inline-block inline-block
<input type=url> inline-block inline inline-block inline-block
<input type=email> inline-block inline inline-block inline-block
<input type=password> inline-block inline inline-block inline-block
<input type=date> inline-flex inline inline-block inline-block
<input type=month> inline-flex inline inline-block inline-block
<input type=week> inline-flex inline inline-block inline-block
<input type=time> inline-flex inline inline-block inline-block
<input type=datetime-local> inline-flex inline inline-block inline-block
<input type=number> inline-block inline inline-block inline-block
<input type=range> inline-block inline-block inline-block inline-block
<input type=color> inline-block inline inline-block inline-block
<input type=checkbox> inline-block inline-block inline-block inline-block
<input type=radio> inline-block inline-block inline-block inline-block
<input type=file> inline-block inline-block inline-block inline-block
<input type=submit> inline-block inline inline-block inline-block
<input type=image> inline-block inline inline-block inline-block
<input type=reset> inline-block inline inline-block inline-block
<input type=button> inline-block inline inline-block inline-block

Should all of them be inline-block?

cc @tkent-google @MatsPalmgren @jwatt @bzbarsky @thejohnjansen @cdumez

@bzbarsky

This comment has been minimized.

Copy link
Collaborator

commented Oct 10, 2018

There are also rendering differences around underline propagation into text controls: Firefox doesn't do it even if display: inline is set (which is the default), while Chrome, at least, does.

Is there any other aspect of rendering that would be different for inline-block vs inline here?

Apart from that, it's mostly OK to set these inline-block, I guess. One exception is image inputs with alt text when the image load fails. Having those be inline-block could easily lead to unreadable alt text, no?

Also interested in whether @dbaron has thoughts.

@zcorpan

This comment has been minimized.

Copy link
Member Author

commented Oct 10, 2018

I don't think there's anything else rendering-wise.

Good point about alt text. I need to test that, but it could make sense to make type=image inline by default.

@zcorpan

This comment has been minimized.

Copy link
Member Author

commented Oct 11, 2018

https://html.spec.whatwg.org/multipage/rendering.html#images-3 says input type=image should be rendered as a button, but browsers don't do that. It seems better for users to do that though. Is there interest in changing this in implementations?

Firefox renders the alt text inline (like it does for img). Edge, Chrome, Safari render as inline-block, honoring any specified dimensions. In Safari, the other dimension is based on the aspect ratio of the rendered alt text, which seems... weird. The text is not rendered at all if it doesn't fit.

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/6273

@bzbarsky

This comment has been minimized.

Copy link
Collaborator

commented Oct 11, 2018

For users, the best thing is if alt text does not get cut off, no?

@annevk

This comment has been minimized.

Copy link
Member

commented Oct 11, 2018

I'd expect both, not cut off and rendered as a button (when displaying alt).

@bzbarsky

This comment has been minimized.

Copy link
Collaborator

commented Oct 11, 2018

How do you expect to work for long alt text, especially when there are size styles on the element?

@annevk

This comment has been minimized.

Copy link
Member

commented Oct 11, 2018

As an inline (which ignores size styling I think). (That seems like the ideal behavior, given that we can get away with displaying alt text inline.)

@bzbarsky

This comment has been minimized.

Copy link
Collaborator

commented Oct 11, 2018

Right, but you can't really render an inline "as a button" once it's line-wrapping, since buttons don't do that.

@MatsPalmgren

This comment has been minimized.

Copy link

commented Oct 11, 2018

Somewhat related, I think we need a spec for ::before/::after pseudos on form controls: #4086.

@SelenIT

This comment has been minimized.

Copy link
Contributor

commented Oct 29, 2018

https://html.spec.whatwg.org/multipage/rendering.html#images-3 says input type=image should be rendered as a button

It seems that this point applies only in some special cases when the image has not loaded. One of these cases is Quirks mode, and at least Firefox in Quirks mode seems to display non-loaded image button pretty "button-like" (although it reports its border-style as none):
imagebutton-quirks

Chrome in Quirks mode renders it similarly, but with uniform border color. Unfortunately, I was not able to get this rendering in Standards mode, despite setting no alt attribute.

@bzbarsky

This comment has been minimized.

Copy link
Collaborator

commented Oct 29, 2018

It seems that this point applies only in some special cases when the image has not loaded.

No, you're looking at the wrong point. Per https://html.spec.whatwg.org/multipage/input.html#image-button-state-(type=image) we have:

The input element represents either an image from which a user can select a coordinate and submit the form, or alternatively a button from which the user can submit the form.

and then further makes it clear that the "represents a button" case is all cases when the image is not available. And then we end up in the last case of https://html.spec.whatwg.org/multipage/rendering.html#images-3 (the one for "If the element is an input element that does not represent an image and the user agent does not expect this to change") which says:

The user agent is expected to treat the element as a replaced element consisting of a button whose content is the element's alternative text. The intrinsic dimensions of the button are expected to be about one line in height and whatever width is necessary to render the text on one line.

None of this depends on quirks mode, in the spec as currently written.

zcorpan added a commit that referenced this issue Oct 29, 2018

Define button layout
This specifies the layout model of buttons (the button element,
the input element in the Button, Reset, Submit states, and the
button part of input in the File Upload state).

Fixes #1024. Fixes #2948. Part of #4081 and #4082.

Tests: TODO
@domenic

This comment has been minimized.

Copy link
Member

commented Mar 29, 2019

As noted in https://www.w3.org/Bugs/Public/show_bug.cgi?id=24296 inline-block for text inputs is not quite right. Moving that bug into here.

@domenic domenic added the interop label Mar 29, 2019

@bzbarsky

This comment has been minimized.

Copy link
Collaborator

commented Mar 29, 2019

@emilio you might be interested.

@dbaron

This comment has been minimized.

Copy link
Member

commented Mar 29, 2019

I'd be happy to switch all of them to inline-block -- now that inline-block exists (which it didn't when the original UA stylesheet was written) it's a better fit for what these form controls do.

@bzbarsky

This comment has been minimized.

Copy link
Collaborator

commented Mar 30, 2019

How does that interact with the vertical-alignment issue?

@dbaron

This comment has been minimized.

Copy link
Member

commented Mar 30, 2019

For which vertical-align values and which controls would changing between inline and inline-block change the vertical alignment?

@bzbarsky

This comment has been minimized.

Copy link
Collaborator

commented Mar 30, 2019

The relevant value of vertical-align is baseline.

I paged things a bit more, and it was only an issue if "overflow" actually applied to these things, because an overflow-not-visible inline-block can't do useful baseline-alignment (sets its baseline at the bottom of the box, not at anything related to the text).

@MatsPalmgren

This comment has been minimized.

Copy link

commented Apr 1, 2019

So, does Chrome commit to fixing this bug so that <input style="display:inline" type=image alt="ALT text..."> uses an actual CSS inline box? And to change its <input type=date> etc to use inline-block by default instead of inline-flex?

@emilio

This comment has been minimized.

Copy link
Contributor

commented Apr 1, 2019

@hayatoito / @tkent-google / @lilles / @ericwilligers would any of you be able to comment here?

Would you be willing to agree on inline-block as a default display value for <input> regardless of it's type?

@tkent-google

This comment has been minimized.

Copy link
Collaborator

commented Apr 1, 2019

type=date in desktop Chrome needs flex layout internally. It's possible to make the default display value to inline-block and ignore it. Is it helpful for web authors?

@zcorpan

This comment has been minimized.

Copy link
Member Author

commented Apr 2, 2019

Differences in form controls rendering are a pain, and this is part of it, though I suppose this issue in isolation has little impact.

@SelenIT

This comment has been minimized.

Copy link
Contributor

commented Apr 2, 2019

to make the default display value to inline-block and ignore it

I don't like the idea of deliberately ignoring any specific values in default styles, as a web author, I would find this confusing, perhaps even frustrating.

Maybe the inline-flex layout of the date input can be replaced by the display:flex wrapper pseudo-element containing all other internal parts of the control, which is itself contained in the display: inline-block container similar to other inputs? Alternatively, the standard could specify only the outer display role of such controls (e.g. "The element is expected to render as an atomic inline-level box"), leaving its inner display layout model up to the implementation details.

@MatsPalmgren

This comment has been minimized.

Copy link

commented Apr 2, 2019

@tkent-google So, the implication of what you're saying is that "Chrome is THE web standard. Why should authors care about any other browser?".

The purpose of having web-platform standards is to ensure that anyone that implements them correctly should end up with a browser that is web-compatible. Here, let's try an example:
data:text/html,<input type=date style="flex-flow:column">
Does the layout in Firefox and Chrome look compatible to you?

Stuff like this is a major source of web-compat issues for Firefox precisely because the Chrome team apparently just make stuff up "because we need it internally". I'm not saying Firefox is perfect, but at least we try to implement what the specs say. BTW, Chrome also supports display:inline-grid for grid layout:
data:text/html,<input type=date style="display:grid; grid-template-columns:repeat(5, 100px)">
But when I style it display:inline-block the computed value ends up inline-flex, table maps to flex etc... Are other UA vendors expected to reverse-engineer Chrome like this in order to be web-compatible?

We could of course make the spec say that type=date etc should use flex layout, but then we also need to define what children they have and the values of all the other properties that apply to flex layout, etc. That's a lot more complicated than saying that it's display:inline-block and that the interior is opaque (regardless of type). It also limits the possible designs for a date control if we expose details of the interior like that.

If flex/grid/(other?) layout is the model you're advocating then please write up a detailed spec for what Chrome is doing exactly, so that we can discuss it.

@domenic

This comment has been minimized.

Copy link
Member

commented Apr 2, 2019

@MatsPalmgren let's please not make accusations like that. I understand it's frustrating trying to achieve interop here. But @tkent-google asked a simple question about the benefits from web authors, and made no statement of the type you say he is implying.

You did a great job answering his question, by pointing out concrete interop issues and how they might affect web developers. I just wish you had done it in a more welcoming tone, without sarcastic rhetorical questions or putting words in others' mouths.

Remember, we are all in this together, attempting to make a better web platform. Please assume good faith by others. Especially others like tkent, who has personally sunk hundreds of hours into interop work aligning Chrome with specs and web platform tests.

@MatsPalmgren

This comment has been minimized.

Copy link

commented Apr 2, 2019

Well, I asked a simple question if Chrome intends to honor the current specs and he replied that Chrome is intentionally not following the specs and asked why it would be helpful for web authors to do so. I think that's disrespectful towards standards and towards other UA vendors.

To be clear: it's fine with me if he wants to advocate for standardization of whatever Chrome is doing, but then someone needs to write up a detailed spec for it so that it can be discussed.

(Still waiting for an answer on the first part on my question regarding ALT text, btw.)

@emilio

This comment has been minimized.

Copy link
Contributor

commented Apr 2, 2019

I concur with @SelenIT and @MatsPalmgren that making it inline-block and fixing blink so it uses an anonymous wrapper inside if they need to seems the easiest way to achieve interop.

Indeed, that's what Firefox does for date and time inputs: We use display: inline-flex on an inner element that is inside a shadow root not accessible to content, that wraps the form controls: https://searchfox.org/mozilla-central/rev/44a212460990ffffecf50a8e972d3cbde2e7216b/toolkit/content/widgets/datetimebox.css#13

I know Blink does similar things in other form controls, so it doesn't seem unreasonable to ask for the same I think.

@tkent-google

This comment has been minimized.

Copy link
Collaborator

commented Apr 3, 2019

Oh, I wan't aware that the specification already asks inline-block vaguely. Then Chrome implementation should be fixed anyway. I thought the specification didn't specify display value, and it's implementation-dependent. I'm sorry for my wrong assumption.

@MatsPalmgren

This comment has been minimized.

Copy link

commented Apr 13, 2019

Is there any other aspect of rendering that would be different for inline-block vs inline here?

Can <input> be a "container" in the CSS meaning of the word? If so, then I assume specifying display:inline-block on it makes it a "block container". If so, then we have a problem with all properties that says "Applies to: block containers", right? Just to pick a couple of random examples: align-content and column-count. What effect do they have on say <input type=file>? Then there's display itself. What internal layout should <input type=file style="display:grid"> have? So, it's not just overflow that is problematic.
Regarding overflow, it's worth noting that UAs generally ignore the value (Gecko honors overflow:visible on <input type=file> though (Chrome doesn't) and this caused a web-compat issue). Chrome honors overflow:scroll though (test), but Gecko doesn't. (Filed a Chromium bug about that.)

If we want to keep the interior layout of <input> opaque then css-display should probably say that its <display-inside> is undefined and that it never counts as "block/grid/flex/multicol/table container". This means that overflow, align-content, flex-direction etc never applies. (With the exception of the ALT-text case, which I think should create a normal CSS box according to its display.)

<button> is a different kind of element though. It renders its child elements which the author has full styling control over and thus it makes sense to me that all of CSS should apply to it. This is also what UAs already do (mostly), overflow:visible is supported in both Firefox and Chrome for example. Firefox supports display:grid etc and Chrome intends to add support for that too, IIUC. So we should not treat <button> the same as <input> IMO.

So, here's what I would recommend as the next steps for the spec:

  • specify that <input type=image alt=text> and <button> creates a box normally according to its display value and that it honors all relevant CSS properties for that type of box...
  • ...and thatdisplay on other <input>s, and <select>, only affect <display-outside> and never counts as "block/grid/flex/multicol/table container"s and thus properties that only applies to such containers do not apply.
  • specify that single-line text controls that by default supports scrolling its value in the inline-axis, i.e. <input type=text/password/search/etc>counts as "scroll container" (this affects their min-size:auto)

With those additions, I think I'm fine with making <input> have display:inline-block by default in Gecko's UA sheet.

@zcorpan

This comment has been minimized.

Copy link
Member Author

commented May 14, 2019

Gecko bug https://bugzilla.mozilla.org/show_bug.cgi?id=1539469

Some of this is specified in #4143 and tested in web-platform-tests/wpt#14824

I will follow up with the rest that is in scope for this issue.

zcorpan added a commit that referenced this issue May 14, 2019

Define button layout
This specifies the layout model of buttons (the button element,
the input element in the Button, Reset, Submit states, and the
button part of input in the File Upload state).

Fixes #1024. Fixes #2948. Fixes #4081. Part of #4082.

Tests: web-platform-tests/wpt#14824

Bugs:
https://bugs.chromium.org/p/chromium/issues/detail?id=962936
https://bugs.webkit.org/show_bug.cgi?id=197879
https://bugzilla.mozilla.org/show_bug.cgi?id=1539469

moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Jun 4, 2019

Bug 1539469 - Make all input elements display: inline-block, for comp…
…at with other UAs. r=mats

See whatwg/html#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.

Differential Revision: https://phabricator.services.mozilla.com/D25566

--HG--
extra : moz-landing-system : lando

mykmelez pushed a commit to mykmelez/gecko that referenced this issue Jun 5, 2019

Bug 1539469 - Make all input elements display: inline-block, for comp…
…at with other UAs. r=mats

See whatwg/html#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.

Differential Revision: https://phabricator.services.mozilla.com/D25566
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.