- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Fri, 05 Jun 2020 22:42:16 +0000
- To: public-css-archive@w3.org
Thinking about this and having off-list discussions with some implementors, @fantasai and I have come to some conclusions that we'd like to get WG review on. First, some design constraints: * Intention of 'stretch' and 'fit-content' was to replicate the fill-container and shrink-to-fit behavior of CSS2. * 'min-content' and 'max-content' were defined to be the minimum and maximum range of 'fit-content', respectively. * From authoring perspective, barring any overriding sizing constraints, having 'width: min-content' yield the same size as sizing under a min-content constraint makes sense. * 'aspect-ratio' + 'min-size: initial' on a replaced element should replicate the current behavior of replaced elements with that intrinsic aspect ratio Additionally, we want 'aspect-ratio' + 'min-size: auto' to have 'auto' resolve to the content height of a non-replaced element per #3268 (see [minutes](https://lists.w3.org/Archives/Public/www-style/2019May/0009.html)), so that the used height/width can violate the specified aspect-ratio if needed to prevent overflow. However, current implementations treat 'min-content' and 'max-content' as the natural size of an image, which is not consistent with the design constraints above: ```html <!DOCTYPE html> <img class=float src="https://placehold.it/50x50"> <img class=min-content src="https://placehold.it/50x50"> <style> body { width: 1px; } .float { height: 100px; float: left; } .min-content { height: 100px; width: min-content; } ``` An image with a naturalWidth of 50px, a 1:1 ratio, and "height: 100px" has, in implementations, a different width when floated in a zero-width container vs when it's assigned "width: min-content", which is wrong per the principles above, and not the behavior we'd want for non-replaced elements with 'aspect-ratio'. Implementors we discussed with from Blink and Gecko are optimistic that this behavior could be changed: replaced elements relying on an explicit non-prefixed 'min-content' or 'max-content' should be rare-to-nonexistent, since these relatively-obscure keywords grant no new abilities to replaced elements. So first, we want to verify with the CSSWG that this behavior can be changed, and that the spec is fine as-is. ---- Assuming the existing definitions are acceptable, we are missing the ability to explicitly restrain one axis of a non-replaced element with an aspect-ratio to its widest atomic inline (min) or longest line of unforced content (max) or, more significantly, its content-based block size. We have defined 'min-height/width: auto' to have this functionality (see earlier remarks about #3268), but it has additional magic such as resolving to zero on scroll containers, so some additional keyword is still needed if we want to represent this behavior unconditionally. If we agree that such keywords would be useful for authors, we propose 'min-intrinsic' and 'max-intrinsic' for these keywords. These would match the concept already named “intrinsic” in 'contain-intrinsic-size' as well (since it is also prior to applying aspect-ratio). Either way, we can adopt such distinct terminology in the specs at least, to resolve #4961. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5032#issuecomment-639874263 using your GitHub account
Received on Friday, 5 June 2020 22:42:18 UTC