W3C home > Mailing lists > Public > public-css-archive@w3.org > February 2017

Re: [csswg-drafts] [css-sizing] percentage [max-]width|height and intrinsic sizes

From: fantasai via GitHub <sysbot+gh@w3.org>
Date: Thu, 23 Feb 2017 20:38:41 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-282113836-1487882319-sysbot+gh@w3.org>
Testcase: 
http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4905
Renderings: 
https://developer.microsoft.com/en-us/microsoft-edge/tools/screenshots/?url=http%3A%2F%2Fsoftware.hixie.ch%2Futilities%2Fjs%2Flive-dom-viewer%2F%3Fsaved%3D4905

This is various kinds of insane. I understand wanting to have 
percentage width and/or max-width make the min-content size zero. I 
could also understand wanting to do this for images but not form 
controls or vice versa. But I don't understand wanting to do it for 
both width and max-width for images, but only width (and not 
max-width) for form controls.

Do we *have* to be randomly inconsistent here, or can we spec 
something somewhat sane like "all replaced elements are affected by 
both max-width and width" or suchlike?

Generally-speaking, the min-content size in the block axis is (like 
the max-content size) the content-based size--what results from 
`height: auto`. We define the concept so that things like grid layout 
and orthogonal flows can be defined with symmetry. So, for example, if
 I ask a grid to size a row filled with images or form controls as 
“min-content”, it's defined. Similarly if I wrap a float around a 
vertical-rl form control, its min-content width (logical height) needs
 to be defined.

Also, one thing to point out here: for form controls the min-content 
contribution isn't exactly zero, it's UA-defined based on how narrow 
the form control can actually get. This limitation is probably worth 
preserving in either case.

-- 
GitHub Notification of comment by fantasai
Please view or discuss this issue at 
https://github.com/w3c/csswg-drafts/issues/765#issuecomment-282113836 
using your GitHub account
Received on Thursday, 23 February 2017 20:38:48 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 19 October 2021 01:30:29 UTC