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

[bfgeek]

From: #6580 (comment)

By @tabatkins

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]

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

[bfgeek]

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

[tabatkins]

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]

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

The full IRC log of that discussion

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

[dholbert]

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, , 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 , WebKit shrinks in both axes, Gecko stretches in both axes, and Chrome stretches in the block axis and shrinks in the inline axis.

[dholbert]

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]

Some observations:

1. It's not as simple as "Safari stretches buttons in both axes". They do that for literal , but they don't for any other button-like element. [except sort-of for color inputs, read on...]. (They shrink-to-fit in the block axis, and they shrink in both axes. And by default, they shrink in both axes, too -- but if you manually specify width:auto;height:auto, then Safari does stretch in both axes, as it does for literal .) [Note: I edited this piece of the comment to add some nuance about color that I discovered in my next comment below.]
2. 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.
3. 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)
4. All three browsers agree on shrink-to-fit for with type="color/checkbox/radio", and also for , and .
5. All three browsers agree on stretching for and
   , and we nearly-agree for

   (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]

@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 ,

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]

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 size itself the same way as (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 in Safari, though not in Chrome, since Chrome shrinks-to-fit in the inline axis.)

[dholbert]

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 , , and , 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 , or for (with explicit width:auto;height:auto), or for , or .

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]

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

[bfgeek]

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]

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

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

[bfgeek]

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]

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,.
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]

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

[bfgeek]

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.

[tabatkins]

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

[dholbert]

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 -- (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]

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

[fantasai]

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