- From: Daniel Holbert via GitHub <sysbot+gh@w3.org>
- Date: Wed, 10 Nov 2021 22:34:08 +0000
- To: public-css-archive@w3.org
I think I'm still neutral as to which is the best way forward here. Argument in favor of stretching (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 (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. In particular, no browser does block-axis shrinking for `<button>`, or for `<input type="color" style='width:auto;height:auto">`, `<input type="date">`, or `<input type="file">`. So, from a position of maximal paranoia, it's conceivable that there'd be 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` always stretches. -- GitHub Notification of comment by dholbert Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6789#issuecomment-965807622 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 10 November 2021 22:34:10 UTC