Repository navigation
[css-sizing] percentage [max-]width|height and intrinsic sizes #765
Description
Background: https://lists.w3.org/Archives/Public/www-style/2015Dec/0117.html
I'm quoting @dbaron's post here verbatim for convenience:
From: L. David Baron dbaron@dbaron.org
Date: Tue, 8 Dec 2015 21:51:01 -0500
To: Karl Dubost kdubost@mozilla.com
Cc: www-style@w3.org
Message-ID: 20151209025101.GA26911@pescadero.dbaron.orgOn Tuesday 2015-10-27 09:44 +0900, Karl Dubost wrote:
Gecko (Firefox) has a Webcompat issue related to the use of
max-widthinsidetable. I put an example on Codepen 1.For Webcompat reasons with Blink and WebKit, we will probably need to modify Gecko code (see Bugzilla 2). In the seeAlso section of this bug, you will find some of the reported Web Compat issues.
What I would like to know is if the CSS specification needs to be changed to reflect the reality.
[...]
Currently Blink and Safari are reducing the image so it fits the viewport.
You can see this in recent Web Compat bugs
https://webcompat.com/issues/1838
https://webcompat.com/issues/1837I summarized the issue in the webcompat space 4.
So the underlying behavior here that needs to be specified is (using
css-sizing terminology) that when either 'width' or 'max-width' on a
replaced element is a percentage, that element's min-content
contribution is zero. Note that given that this occurs for
'max-width', this needs to override the rule that the min-content
contribution is determined by the specified size, since a replaced
element with "width: 100px; max-width: 50%" has a min-content
contribution of 0.The relevant section of the specification is:
http://dev.w3.org/csswg/css-sizing/#replaced-intrinsicAt least, that's the relevant specification assuming a relatively
strict definition of replaced element. This rule should not apply
to form controls and similar things that aren't explained by CSS.
It should only apply to things that do replaced element sizing such
as images, plugins, videos, and iframes.I'm not sure if we have a clear enough definition of replaced
element, or whether we perhaps need two definitions.-David
Activity
MatsPalmgren commentedon Nov 25, 2016
@dbaron changed our layout in Gecko in this bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=823483
by reverse-engineering the Chrome/Edge behavior (IIUC).
However, there are still some case where UAs are not compatible.
When using vertical writing-mode for example:
https://bugzilla.mozilla.org/show_bug.cgi?id=1308929
It would be great to actually have a specification for this so
that everyone knows what to implement, and have this documented
for authors.
MatsPalmgren commentedon Nov 25, 2016
I think the upcoming introduction of Grid layout in some browsers makes
this more urgent to address; given the symmetric nature of track sizing
in Grid, it's likely this will lead to web-compat problems.
Here are a few simple examples where Firefox / Chrome differs currently:
https://people-mozilla.org/~mpalmgren/tests/grid/grid-item-image-size-percentages.html
Fwiw, I tend to think that max-size/size should work symmetricly in both axes.
wolfbeast commentedon Nov 26, 2016
I'd definitely prefer a definitive spec for this as well, since the undefined behavior makes it possible to implement it in any number of ways that are all logical, but aren't always compatible or giving the expected results to web designers.
fantasai commentedon Feb 16, 2017
So, from what Tab and I understand, the proposal is to have image-like replaced elements contribute zero as their min-content and max-content size contributions if they have a percentage as either their specified or max size.
There is an open question on whether this should apply only to the inline axis or to both axes (and in the former case which element is determining the axis mapping).
We're happy to make the necessary changes, but we need
Waiting on your response to the first two, and then we'll Agenda+.
dbaron commentedon Feb 18, 2017
I was proposing that this change affect only min-content sizing and not max-content sizing. I believe changing max-content sizing in this way would break Web-compatibility.
I believe this needs a definition slightly broader than image-like; for us it was essentially img, canvas, plugins (object/embed), video, and iframe. I believe that list was interoperable, although it's perhaps worth retesting.
(The rule also applies to
<textarea>and<input type="text">, although only for percentagewidthand not for percentagemax-width. I believe this was also pretty interoperable.)It's not clear to me what doing the same for both axes means; I don't think there is such a thing as a min-content size in the block axis.
Or is there a question as to whether the
heightproperty should also (in English) affect the min-content size contribution?fantasai commentedon Feb 23, 2017
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.
fantasai commentedon Feb 23, 2017
Proposal atm is:
widthormax-widthis percentage-basedcalc()expressions retain their fixed-length components.The key question is, is this Web-compatible, given form controls don't currently respond to
max-width?dbaron commentedon Mar 1, 2017
I think the phrasing around "maximally-squashed" might just be "add the padding and border and margin outside of the zero width".
astearns commentedon Mar 1, 2017
We discussed this on the call and asked some implementors to look at the web compatibility of fantasai's proposal above
gregwhitworth commentedon Mar 1, 2017
Ok, so based on the @fantasai statement above, to determine the "rough" web compatibility of this we need to essentially look for max-width being used on form controls, correct?
32 remaining items
dbaron commentedon Aug 9, 2017
I'm certainly OK with trying the first set of edits.
The biggest issue with them is that they need a clearer definition of replaced element. This is the definition of replaced elements that includes not only the ones that honor CSS 2.1's rules on sizing of replaced elements, but also includes most form controls, but not buttons. So I think it's <input> with type other than button/submit/reset, and also <select>, <textarea>, <progress>, and <meter>. I'm not sure about <output>, and I think <fieldset> doesn't count (but it's probably worth testing). The fact that buttons are not included means there isn't an appropriate canned definition floating around.
Another note is that if your testcase determined that Firefox zeroes out only the percentage, then your testcase is wrong, since the last time we talked about this I wrote a patch (still unlanded) to change that.
Also, I filed a Mozilla bug 1388840 on updating the behavior.
fantasai commentedon Aug 9, 2017
That's what I remembered... was very confused when I didn't get that result. Figured it out, here's the updated testcase: http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=5298
dbaron commentedon Aug 9, 2017
So what about the bit about pointing to an appropriate definition of replaced elements?
fantasai commentedon Oct 18, 2017
Filed that one as #1889 since this issue is plenty long enough and the issue as initially described has been fixed. Please only reopen if you have an objection to the resolution or the edits implementing it; defining “replaced element” is a whole other realm of problem.
fantasai commentedon Oct 27, 2017
Fwiw, we checked in edits for #1889 based on @dbaron's comment and would appreciate a review. Thanks~
[css-sizing-3] Cyclic percentage compression only affects min-content…