[css-position] Behaviour of semi-replaced elements. #6789

bfgeek · 2021-11-02T22:39:28Z

For buttons and inputs, behavior seems inconsistent across browsers; in particular, it seems WebKit just treats buttons (and inputs) like any other box, so seems like that would be a reasonable direction to go in given the other browsers are very inconsistent? In any case, should be a separate issue if we need to address anything in the spec.

Doing this breaks this particular WPT test:
https://wpt.fyi/results/html/rendering/widgets/button-layout/abspos.html

This was added in:
web-platform-tests/wpt#14824
By @zcorpan , (primarily reviewed by @emilio )
whatwg/html#4143
whatwg/html#2948 (by @dholbert )
whatwg/html#4081 (comment)

etc.

Currently we (Blink) have different behaviour in the inline/block axis which we were about to fix (with zero insets, should still shrink-fit, instead of stretch).

bfgeek · 2021-11-02T23:04:05Z

More history:
https://bugs.chromium.org/p/chromium/issues/detail?id=281380

bfgeek · 2021-11-10T17:10:55Z

Example:
https://www.software.hixie.ch/utilities/js/live-dom-viewer/saved/9793

tabatkins · 2021-11-10T17:21:07Z

Doing this breaks this particular WPT test:

Well, it would fix it for Safari. ^_^

Currently we (Blink) have different behaviour in the inline/block axis which we were about to fix (with zero insets, should still shrink-fit, instead of stretch).

I suppose I'd find it acceptable to have it shrink-fit in both axises (at least it would be consistent, rather than a new and weird behavior), but every divergence that buttons make from a standard inline-block is unfortunate.

css-meeting-bot · 2021-11-10T17:33:04Z

The CSS Working Group just discussed [css-position] abspos semi-replaced elements.

The full IRC log of that discussion

<fantasai> Topic: [css-position] abspos semi-replaced elements
<fantasai> github: https://github.com//issues/6789
<fantasai> iank_: Bunch of history here
<fantasai> iank_: When we have width/height=auto
<fantasai> iank_: can either shrink-to-fit or stretch in that axis
<fantasai> iank_: in Grid Layout, most items will stretch except replaced elements
<fantasai> iank_: every layout mode make these decisions
<fantasai> iank_: semi-replaced element in block layout, frex, is shrhink-to-fit
<fantasai> iank_: Question is about abspos semi-replaced element, say with inset: 0
<fantasai> iank_: Firefox stretches in block axis, shrink in inline
<fantasai> iank_: webkit stretch both axes
<fantasai> iank_: chrome ...
<fantasai> iank_: So what do we want to do here?
<fantasai> iank_: previously FF team strongly wanted shrink-to-fit here
<fantasai> Rossen_: anyone from FF?
<TabAtkins> As I said in the issue a few minutes ago, "every divergence that buttons make from a standard inline-block is unfortunate."
<fantasai> Rossen_: Do we shrink-to-fit in both axes, or stretch in both axes, to make behavior symmetric and consistent
<TabAtkins> Because it has been asserted quite confidently in the past by implementors that buttons were *not* replaced elements, and were fully described solely by inline-block behavior ^_^
<fantasai> dholbert: Don't have an answer atm, but will take a look
<Rossen_> q?
<drott> fantasai: tab and i figured that
<drott> fantasai: since webkit implements stretch on both axis
<drott> fantasai: that makes it web compatible
<drott> fantasai: [missed] you can always get the other behavior by switching alignment
<Rossen_> ack TabAtkins
<Rossen_> ack fantasai
<fantasai> TabAtkins: In the past, impl have said that buttons aren't replaced elements
<fantasai> TabAtkins: and fully described by inline/block behavior, so the more we can make that true the better
<fantasai> TabAtkins: having them stretch by default would make them match non-replaced
<fantasai> iank_: I'm fine either way, but historically FF folks have been very strong in their opinion wrt shrink-to-fit
<fantasai> Rossen_: OK, let's give dholbert some time to look through it
<fantasai> Rossen_: if we can resolve on this later on in the call, great, if not, bring back next week

dholbert · 2021-11-10T19:03:28Z

iank_: I'm fine either way, but historically FF folks have been very strong in their opinion wrt shrink-to-fit

Clarifying this: I think we've mostly been arguing for something coherent/sensible, rather than arguing specifically for shrink-to-fit. It just happened to be that shrink-to-fit seemed to be the sensible/spec-mandated behavior, at the time of those earlier discussions; but I don't think we're inherently opposed to stretching behavior.

I do want to be sure that we consider other related form controls (e.g. textarea, <input type="image">, etc.) as well. It looks like things are a bit all over the place right now -- e.g. for buttons, WebKit stretches in both axes (vs. Gecko/Chrome shrink in the inline axis). But for <input type="image">, WebKit shrinks in both axes, Gecko stretches in both axes, and Chrome stretches in the block axis and shrinks in the inline axis.

dholbert · 2021-11-10T19:48:45Z

I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1740580 as a place to post a testcase with screenshots.
Here's my testcase, which has a variety of form controls with all the inset properties set to 3px, and with a green outline around the form control to highlight its final bounds.

Here are screenshots in the three major browser engines:
screenshot in Firefox Nightly 96
screenshot in Chrome dev 97
screenshot in Safari 15.1

dholbert · 2021-11-10T20:03:47Z

Some observations:

It's not as simple as "Safari stretches buttons in both axes". They do that for literal <button>, but they don't for any other button-like element. [except sort-of for color inputs, read on...]. (They shrink-to-fit <input type="button/reset/submit"> in the block axis, and they shrink <input type="image"> in both axes. And by default, they shrink <input type="color"> in both axes, too -- but if you manually specify width:auto;height:auto, then Safari does stretch <input type="color"> in both axes, as it does for literal <button>.) [Note: I edited this piece of the comment to add some nuance about color that I discovered in my next comment below.]
Textfield-like elements are another related area where browsers disagree. Firefox does shrink-to-fit in both axes (except for date which is an outlier that we stretch in the block axis for some reason); Chrome does shrink-to-fit in the inline axis only and stretches in the block axis; Safari stretches in both axes.
input type="range" has the same behavior across the three engines (fully shrink-to-fit in Firefox; shrink-to-fit in inline axis in Chrome, fully-stretched in Safari)
All three browsers agree on shrink-to-fit for <input> with type="color/checkbox/radio", and also for <progress>, and <meter>.
All three browsers agree on stretching for <label> and <fieldset>, and we nearly-agree for <output> (Chrome shrinks in the inline axis for that one so it's not full agreement).

So: things are a bit of a mess, though (4) and (5) are the points of agreement. Ideally I'd like to have a coherent and likely-to-be-web-compatible way forward here, and I'm not sure that the proposed change (stretching in both axes) is that, given that there are a handful of button-like elements that no browser stretches in both axes at this point.

bfgeek · 2021-11-10T20:41:35Z

@dholbert - I think your testcase can be slightly improved by adding:

.abs { width: auto; height: auto; }

radio/checkboxes in Blink have some magic happening where they effectively set:

width: 13px !important; height: 13px !important;

which is why that behaviour is observed.

With those explanations currently Blink stretches in the block-axis, and shrink-to-fit in the inline-axis everywhere - except for <label>, <fieldset> as discussed.

(5) - agree that can move to stretching in all axes for those three.

(4) - Is clouded by default UA styles I believe.

The results of above makes me think that'd it be safest to move to a shrink-to-fit behaviour in both axes (except for fieldset, label, output).
E.g. where Blink stretches in the block-axes there is at least one other engine which shrink-to-fit in the block-axis (with the exception of the regular button element).

dholbert · 2021-11-10T21:27:10Z

Thanks. Here's a variant of my earlier testcase, now with explicit width:auto; height:auto on the abspos elements:
https://bug1740580.bmoattachments.org/attachment.cgi?id=9250287

This change doesn't change the outcome much, though. The only rendering differences from this change:

In all browsers, it makes <input type="color"> size itself the same way as <button> (whatever that means for the given browser)
In Chrome and Safari, it makes progress and meter stretch in both axes. (This makes them consistent with <input type="range"> in Safari, though not in Chrome, since Chrome shrinks-to-fit <input type="range"> in the inline axis.)

dholbert · 2021-11-10T22:34:07Z

I think I'm still neutral as to which is the best way forward here.

Argument in favor of stretching all of these elements (aside from checkbox/radio):

Essentially, every form-control has its inline size stretched in some browser, and has its block size stretched in some (possibly-different) browser. The exceptions here are: checkbox/radio which interoperably refuse to stretch and so we could set them aside as special cases; and also <input type='color'>, <progress>, and <range>, which aren't really exceptions since they fully-stretch in Safari when styled with width:auto;height:auto.

Argument in favor of shrinking all of these elements (aside from output/label/fieldset):

The ~reverse of the above argument is nearly true but not quite. i.e. we can say that nearly every form control has its inline-size shrunk in some browser and has its block-size shrunk in some (possibly-different) browser. But there are more exceptions here; in particular, no browser does block-axis shrinking for <button>, or for <input type="color"> (with explicit width:auto;height:auto), or for <input type="date">, or <input type="file">.

So, from a position of maximal paranoia, it's conceivable that there'd be more webcompat fallout from changing to shrink-to-fit for button (for example) since no browser shrinks button in the block axis right now. So there could be content that assumes that button with top:0;bottom:0 stretches vertically, because in fact it does stretch vertically in all browsers right now.

dholbert · 2021-11-10T23:13:25Z

All of which is to say: it feels like stretching would probably be the safest change here (from a webcompat perspective).

bfgeek · 2021-11-10T23:42:33Z

All of which is to say: it feels like stretching would probably be the safest change here (from a webcompat perspective).

I'd be fine w/ that.

css-meeting-bot · 2021-11-17T17:37:43Z

The CSS Working Group just discussed [css-position] Behaviour of semi-replaced elements., and agreed to the following:

RESOLVED: Semi-replaced elements stretch in both directions in abspos

The full IRC log of that discussion

<fantasai> Topic: [css-position] Behaviour of semi-replaced elements.
<fantasai> github: css-position] Behaviour of semi-replaced elements.
<fantasai> github: https://github.com//issues/6789
<fantasai> iank_: After last week's meeting dholbert did an in-depth investigation, which was great to see
<fantasai> iank_: test page with a whole bunch of replaced elements, and looked at behavior
<fantasai> iank_: we both agreed that it's probably reasonable to stretch in both directions for all semi-replaced elements
<fantasai> iank_: There's no browser which does something consistently, so every browser would need to change
<fantasai> iank_: but this is a straighforward path forward
<fantasai> dholbert_: Every form control is stretched in at least one browser
<fantasai> dholbert_: but not every form control is shrunk in at least browser
<fantasai> iank_: e.g. we stretch in block direction but not inline
<fantasai> iank_: webkit and FF together have complete coverage of stretching in inline direction
<fantasai> astearns: change is to stretch in both directions in all browsers eventually?
<fantasai> iank_: correct
<fantasai> astearns: any other opinions?
<fantasai> fantasai: Tab and I are in favor of this
<fantasai> RESOLVED: Semi-replaced elements stretch in both directions in abspos
<fantasai> iank_: We'll likely make this change in the next few months, and will report back if any web-compat concerns
<fantasai> astearns: Thanks, dholbert_, for your investigation

bfgeek · 2021-11-17T17:39:42Z

Opps - should probably have mentioned that we'll likely need to leave checkbox & radio buttons alone for the moment. But all browsers are currently consistent there. (and all likely apply an equivalent of a !important width/height property).

dholbert · 2021-11-17T17:52:17Z

Opps - should probably have mentioned that we'll likely need to leave checkbox & radio buttons alone for the moment. But all browsers are currently consistent there. (and all likely apply an equivalent of a !important width/height property).

Right, those are the exception to this stretching.

(Minor correction: they don't seem to do this via something along the line of !important width/height; this testcase shows that authors can specify their own sizes without any !important handcuffs (though the rendering is perhaps not what they'd expect):
data:text/html,<input type="checkbox" style="width: 400px; height: 400px; outline: 3px solid orange">.
But in any case, they are special in that interoperably shrink-to-fit when abspos, and they're typically quite tiny, both of which mean it wouldn't make sense to stretch them.)

zcorpan · 2021-11-18T22:00:40Z

Does https://html.spec.whatwg.org/multipage/rendering.html#button-layout need changes? (This section should probably be moved to some CSS spec, but not sure where.)

As per: w3c/csswg-drafts#6789 Removes the tests which were previously testing the shrink-to-fit behaviour, and adds new tests for the stretch behaviour (on more elements). Bug: 1274898 Change-Id: I5c40a4b88fe06d7ef79113a66ef3976375d026eb

As per: w3c/csswg-drafts#6789 Removes the tests which were previously testing the shrink-to-fit behaviour, and adds new tests for the stretch behaviour (on more elements). Bug: 1274898 Change-Id: I5c40a4b88fe06d7ef79113a66ef3976375d026eb Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3272378 Commit-Queue: Ian Kilpatrick <ikilpatrick@chromium.org> Reviewed-by: Morten Stenshorne <mstensho@chromium.org> Cr-Commit-Position: refs/heads/main@{#946530}

…when OOF in inline direction., a=testonly Automatic update from web-platform-tests [layout] Stretch semi-replaced elements when OOF in inline direction. As per: w3c/csswg-drafts#6789 Removes the tests which were previously testing the shrink-to-fit behaviour, and adds new tests for the stretch behaviour (on more elements). Bug: 1274898 Change-Id: I5c40a4b88fe06d7ef79113a66ef3976375d026eb Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3272378 Commit-Queue: Ian Kilpatrick <ikilpatrick@chromium.org> Reviewed-by: Morten Stenshorne <mstensho@chromium.org> Cr-Commit-Position: refs/heads/main@{#946530} -- wpt-commits: 5bf9341f0881529d809045b71ba7ae887d8919a8 wpt-pr: 31786

bfgeek · 2022-02-24T18:01:18Z

Does https://html.spec.whatwg.org/multipage/rendering.html#button-layout need changes? (This section should probably be moved to some CSS spec, but not sure where.)

I don't beleive this section needs immediate change. The button element is under "widgets" now - so pretty clear it isn't replaced, (and no mention of semi-replaced in that document). The change decided here makes it so there isn't any special behaviour for these widget elements.

As per: w3c/csswg-drafts#6789 Removes the tests which were previously testing the shrink-to-fit behaviour, and adds new tests for the stretch behaviour (on more elements). Bug: 1274898 Change-Id: I5c40a4b88fe06d7ef79113a66ef3976375d026eb Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3272378 Commit-Queue: Ian Kilpatrick <ikilpatrick@chromium.org> Reviewed-by: Morten Stenshorne <mstensho@chromium.org> Cr-Commit-Position: refs/heads/main@{#946530} NOKEYCHECK=True GitOrigin-RevId: da65a23485a8a1abedd0fff0f390238fdd56258b

tabatkins · 2023-01-06T23:32:17Z

We should adapt dholbert's test case into a reftest for this issue.

dholbert · 2023-01-07T00:50:29Z

I posted another testcase on the bug which is a slightly better reftest than the previous ones, and has a reference:
testcase: https://bugzilla.mozilla.org/attachment.cgi?id=9311171
reference: https://bugzilla.mozilla.org/attachment.cgi?id=9311172

Chrome almost matches the expectations here but they seem to have a subtle bug with one form control -- <input type="image"> (the first item in the second row) has slightly different positioning of its contents for some reason. I'll file that as a Chrome bug in a sec.

dholbert · 2023-01-07T01:04:05Z

(I filed https://bugs.chromium.org/p/chromium/issues/detail?id=1405560 for the Chromium mismatch that I noted. for input type="image")

…c#6789

fantasai · 2023-02-14T05:47:46Z

Reopening to double-check the behavior around input type=image

bfgeek added the css-position-3 Current Work label Nov 2, 2021

bfgeek added the Agenda+ label Nov 3, 2021

css-meeting-bot removed the Agenda+ label Nov 17, 2021

mozilla-apprentice mentioned this issue Nov 17, 2021

[css-position] Behaviour of semi-replaced elements. mozilla/wg-decisions#688

Closed

chromium-wpt-export-bot mentioned this issue Nov 30, 2021

[layout] Stretch semi-replaced elements when OOF in inline direction. web-platform-tests/wpt#31786

Merged

benface mentioned this issue Jun 28, 2022

[css-sizing] Possible to reproduce a <div>'s width: auto behavior on any element? #7427

Open

fantasai added the Needs Edits label Jan 6, 2023

tabatkins added a commit that referenced this issue Jan 6, 2023

[css-position-3] Clarify that HTML form controls are non-replaced. #6789

fd3abba

fantasai added Closed Accepted by CSSWG Resolution Needs Testcase (WPT) and removed Needs Edits labels Jan 6, 2023

fantasai closed this as completed Jan 6, 2023

jakearchibald pushed a commit to jakearchibald/csswg-drafts that referenced this issue Jan 16, 2023

[css-position-3] Clarify that HTML form controls are non-replaced. w3…

3e0b157

…c#6789

fantasai reopened this Feb 14, 2023

fantasai added a commit that referenced this issue Mar 29, 2023

[css-position-3] <input type=image> is still replaced #6789

20bfa00

fantasai closed this as completed Mar 29, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[css-position] Behaviour of semi-replaced elements. #6789

[css-position] Behaviour of semi-replaced elements. #6789

bfgeek commented Nov 2, 2021

bfgeek commented Nov 2, 2021

bfgeek commented Nov 10, 2021

tabatkins commented Nov 10, 2021

css-meeting-bot commented Nov 10, 2021

dholbert commented Nov 10, 2021

dholbert commented Nov 10, 2021

dholbert commented Nov 10, 2021 •

edited

bfgeek commented Nov 10, 2021

dholbert commented Nov 10, 2021 •

edited

dholbert commented Nov 10, 2021 •

edited

dholbert commented Nov 10, 2021

bfgeek commented Nov 10, 2021

css-meeting-bot commented Nov 17, 2021

bfgeek commented Nov 17, 2021

dholbert commented Nov 17, 2021 •

edited

zcorpan commented Nov 18, 2021

bfgeek commented Feb 24, 2022

tabatkins commented Jan 6, 2023 •

edited by fantasai

dholbert commented Jan 7, 2023

dholbert commented Jan 7, 2023

fantasai commented Feb 14, 2023 •

edited

[css-position] Behaviour of semi-replaced elements. #6789

[css-position] Behaviour of semi-replaced elements. #6789

Comments

bfgeek commented Nov 2, 2021

bfgeek commented Nov 2, 2021

bfgeek commented Nov 10, 2021

tabatkins commented Nov 10, 2021

css-meeting-bot commented Nov 10, 2021

dholbert commented Nov 10, 2021

dholbert commented Nov 10, 2021

dholbert commented Nov 10, 2021 • edited

bfgeek commented Nov 10, 2021

dholbert commented Nov 10, 2021 • edited

dholbert commented Nov 10, 2021 • edited

dholbert commented Nov 10, 2021

bfgeek commented Nov 10, 2021

css-meeting-bot commented Nov 17, 2021

bfgeek commented Nov 17, 2021

dholbert commented Nov 17, 2021 • edited

zcorpan commented Nov 18, 2021

bfgeek commented Feb 24, 2022

tabatkins commented Jan 6, 2023 • edited by fantasai

dholbert commented Jan 7, 2023

dholbert commented Jan 7, 2023

fantasai commented Feb 14, 2023 • edited

dholbert commented Nov 10, 2021 •

edited

dholbert commented Nov 10, 2021 •

edited

dholbert commented Nov 10, 2021 •

edited

dholbert commented Nov 17, 2021 •

edited

tabatkins commented Jan 6, 2023 •

edited by fantasai

fantasai commented Feb 14, 2023 •

edited