Copy link
Contributor
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.
Copy link
Member
Author
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.
Copy link
Member
Author
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.
Copy link
Contributor
For users, the best thing is if alt text does not get cut off, no?
Copy link
Member
I'd expect both, not cut off and rendered as a button (when displaying alt).
Copy link
Contributor
How do you expect to work for long alt text, especially when there are size styles on the element?
Copy link
Member
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.)
Copy link
Contributor
Right, but you can't really render an inline "as a button" once it's line-wrapping, since buttons don't do that.
Copy link
Contributor
Somewhat related, I think we need a spec for ::before/::after pseudos on form controls: #4086.
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):
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.
Copy link
Contributor
It seems that this point applies only in some special cases when the image has not loaded.
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.
👍
1
zcorpan
added a commit
that referenced
this issue
Oct 29, 2018
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
Copy link
Member
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.
Copy link
Contributor
@emilio you might be interested.
Copy link
Member
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.
Copy link
Contributor
How does that interact with the vertical-alignment issue?
Copy link
Member
For which vertical-align values and which controls would changing between inline and inline-block change the vertical alignment?
Copy link
Contributor
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).
Copy link
Contributor
So, does Chrome commit to fixing this bug so that uses an actual CSS inline box? And to change its etc to use inline-block by default instead of inline-flex?
Copy link
Contributor
@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 regardless of it's type?
Copy link
Collaborator
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?
Copy link
Member
Author
Differences in form controls rendering are a pain, and this is part of it, though I suppose this issue in isolation has little impact.
Copy link
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.
Copy link
Contributor
@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,
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,
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.
👍
1
Copy link
Member
@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.
👍
1
Copy link
Contributor
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.)
6 hidden items
Load more…
mykmelez
pushed a commit
to mykmelez/gecko
that referenced
this issue
Jun 5, 2019
…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
Copy link
Member
Author
Per mozilla/gecko-dev@1e7b303 Gecko has now changed to inline-block for all input elements.
@emilio did this change baseline alignment? Overflow? What happens with images showing alt text?
I'd like to fix the spec (this week or next week), but I'm still a bit confused about what it should say. From https://www.w3.org/Bugs/Public/show_bug.cgi?id=24296 it seems some magic needs to be specified...
Copy link
Member
Author
Sorry, I glossed over @MatsPalmgren comment above
So, here's what I would recommend as the next steps for the spec:
Does this match what is now implemented in Firefox?
Copy link
Contributor
I think that matches what Firefox does atm, yes.
A broken with alt text would create a non-replaced inline-block box by default, but it honors display, so would create an inline box and so on.
gecko-dev-updater
pushed a commit
to marco-c/gecko-dev-comments-removed
that referenced
this issue
Oct 4, 2019
…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
UltraBlame original commit: d0be9ca49bd74bf80de70031fc21ad4cd9f8f092
gecko-dev-updater
pushed a commit
to marco-c/gecko-dev-wordified
that referenced
this issue
Oct 4, 2019
…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
UltraBlame original commit: d0be9ca49bd74bf80de70031fc21ad4cd9f8f092
gecko-dev-updater
pushed a commit
to marco-c/gecko-dev-wordified-and-comments-removed
that referenced
this issue
Oct 4, 2019
…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
UltraBlame original commit: d0be9ca49bd74bf80de70031fc21ad4cd9f8f092
Copy link
Member
Author
If we want to keep the interior layout of opaque then css-display should probably say that its 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.)
...and thatdisplay on other s, and , only affect and never counts as "block/grid/flex/multicol/table container"s and thus properties that only applies to such containers do not apply.
This will mean that other properties that apply currently will also not apply, such as width and height. Right?
I don't think that making undefined makes it clear what the expected rendering is. We could force it to flow-root and also safelist a few "Applies to: block containers" properties that we want to support. If we do this, and don't include overflow in the safelist, that seems to me like it would address the concerns?
Copy link
Member
Author
...or a blocklist for things we definitely don't want to apply (like overflow), and leave it undefined (for now) which other properties apply and how.
Copy link
Contributor
Does this match what is now implemented in Firefox?
I think so, but form controls are under-tested and do lot's of weird stuff to support legacy behavior, so I might be wrong.
I don't think that making undefined makes it clear what the expected rendering is. We could force it to flow-root
Maybe. We still want to honor display for the ALT-text case though, but other than that I guess we could say that all values behaves as flow-root. I'm still a bit hesitant about it because I don't think we want to commit to supporting all things that are normally supported in block layout to the interior of these elements, say align-content:end or overflow:visible or ::first-letter.
or a blocklist for things we definitely don't want to apply (like overflow), and leave it undefined (for now) which other properties apply and how.
Yeah, I suspect that to achieve interoperability we'll likely need a list of which properties are honored and how. (IIRC, appearance:none also affects which properties are honored.) Excluding arbitrary values automatically excludes many properties though.
Copy link
Member
Author
I created a demo for baseline alignment of different input types when overflow is visible, hidden, scroll.
A few findings:
For most controls, the text in the control has the same baseline as the surrounding text regardless of 'overflow'.
Firefox: overflow: hidden on button types clips the text at the padding edge.
Chrome: type=color has different baseline depending on overflow.
Safari/Firefox: type=color has "baseline" alignment regardless of overflow.
range, checkbox and radio don't have text and have the same alignment (like replaced elements) regardless of overflow.
Chrome: type=file changes alignment for non-visible overflow.
Firefox/Chrome: type=image changes alignment for non-visible overflow (as @MatsPalmgren prefers)
Safari: doesn't show the alt text for type=image. When setting a src attribute it shows a blue questionmark, still no alt text. Aligned like a replaced element regardless of overflow.
Safari: button, reset, submit, file show a scrollbar for overflow: scroll.
Chrome: button, reset, submit, file, image show a scrollbar for overflow: scroll.
Firefox: only image shows a scrollbar for overflow: scroll.
Since maintaining the text baseline is recognized as an important property to maintain, I think we should say simply that 'overflow' doesn't apply to input (except for image).
Which other properties should be ignored?
Copy link
Member
Author
I've added a commit in #4840 to force inner display type to flow-root and ignore overflow for input elements that are not type=hidden or type=image.
Copy link
Contributor
I added three more columns that check each of the existing cases but with -webkit-appearance:none. Chrome Canary on Linux has different behavior for overflow when that is set. I see scrollbars in most cases in the last column. Chrome also synthesizes the baseline differently depending on that property for type=checkbox for example (content-box vs margin-box).
It's also worth noting that the baseline is different for some of these controls. For example, type=color uses the content-box edges, whereas type=range use the margin-box edges in Firefox but the border-box edges in Chrome. We need to agree on these baselines and specify them somewhere.
Since maintaining the text baseline is recognized as an important property to maintain, I think we should say simply that 'overflow' doesn't apply to input (except for image).
That sounds reasonable to me.
The type=image is only special when it displays it's ALT-text though. It then should create a box according to its display value with the ALT-text inside it. I added a few variations on that in the test.
Copy link
Member
Author
When input type=image is showing an image, it's a normal replaced element, right?
Copy link
Contributor
Yes, it's identical to from a layout POV.
Copy link
Member
Author
@MatsPalmgren do you think type=button, type=reset, type=submit should force inner display type to flow-root, while support grid and flex?
Granted, grid and flex aren't going to be particularly useful for input since the contents can only be text, but I wanted to check if this is desired since it's inconsistent.
Copy link
Member
Author
I added three more columns that check each of the existing cases but with -webkit-appearance:none. Chrome Canary on Linux has different behavior for overflow when that is set. I see scrollbars in most cases in the last column.
Thanks. On macOS in Chrome I see scrollbars for the same elements with and without -webkit-appearance: none:
file
submit
image (alt)
reset
button
Chrome also synthesizes the baseline differently depending on that property for type=checkbox for example (content-box vs margin-box).
I've filed a new issue about figuring out where the baseline actually is for different form controls:
#5065
zcorpan
added a commit
that referenced
this issue
Nov 8, 2019
And only support scrolling in the inline axis.
This should address the third bullet point in
#4082 (comment)
Copy link
Member
Author
specify that single-line text controls that by default supports scrolling its value in the inline-axis, i.e. counts as "scroll container" (this affects their min-size:auto)
I've specified this for text, search, tel, url, email, and password types in 98deb7d
For some controls it's a bit unclear if we should require scrolling. In particular date, month, week, time, datetime-local, number. They look like text entry widgets (in browsers), but the spec is very vague about these and I suppose they could have a very different UI.
We could require that the other controls (range, color, checkbox, radio, file, button, submit, reset) explicitly do not create a scroll container. Should we do that?
Copy link
Member
Author
(this affects their min-size:auto
but seems to be defined in https://drafts.csswg.org/css-sizing-3/#min-content-zero which form controls have the shrink-to-zero behavior. Are there wpt tests for that?
Edit: I filed #5071
Copy link
Member
Author
New attempt to test the scroll container aspect (with different assumptions)
Copy link
Contributor
I just came across a bug in chrome which referenced this: https://bugs.chromium.org/p/chromium/issues/detail?id=970249
I have a fix for chrome to stop using display:inline-flex for some input types: https://chromium-review.googlesource.com/c/chromium/src/+/2555698
Are these WPTs supposed to cover the changes? web-platform-tests/wpt#20148
moz-v2v-gh
pushed a commit
to mozilla/gecko-dev
that referenced
this issue
Apr 7, 2021
…f determining which element to zoom to for double tap to zoom. r=emilio
The specific case that motivated this was text areas, but in bug 1700535 we changed those to inline block to match all other input elements and other browsers.
Bug 1539469 changed all inputs to inline-block based on the spec discussion whatwg/html#4082 but textarea's were not part of that.
elements remain as inline though, and we probably do want to zoom to them (and they are replaced), so this change is still desirable.
Differential Revision: https://phabricator.services.mozilla.com/D109574
Copy link
Contributor
Are these WPTs supposed to cover the changes? web-platform-tests/wpt#20148
Yes, I think so, @zcorpan? I think I also landed some tests when I made the change in Firefox.
扫一扫
2124
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
