Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
[css-sizing] percentage [max-]width|height and intrinsic sizes #765
@dbaron changed our layout in Gecko in this bug:
It would be great to actually have a specification for this so
I think the upcoming introduction of Grid layout in some browsers makes
Fwiw, I tend to think that max-size/size should work symmetricly in both axes.
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+.
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
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
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
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.
Proposal atm is:
The key question is, is this Web-compatible, given form controls don't currently respond to
@fantasai @dbaron Ok here is my recipe I plan to run with: https://github.com/MicrosoftEdge/css-usage/blob/master/src/recipes/max-height-replaced-elems.js
This does what I was saying in IRC that this will determine if a % is used on
We can figure this out after the crawl is complete. Please let me know ASAP if there is any concern with the recipe I linked to above.
Not sure why you're looking at height rather than width. I think the idea that there are intrinsic sizes in the block dimension is a spec fiction that I'm working on an alternative proposal for. But any issues in the wild would almost certainly be with width, not height.
Also, I think the proposed change to the widely-implemented behavior affects only
I must have mis-read what @fantasai meant by
I assumed she was wanting to know about web compat concerns to make the block direction match the inline. My bad, this is easy enough to modify.
Here is the updated file: https://github.com/MicrosoftEdge/css-usage/blob/master/src/recipes/max-width-replaced-elems.js
So, the results of a slightly-more-careful review this time:
So it still needs to test somewhere that
Wow, I'm surprised I missed the not checking
Ok, following up on my action - here is what the crawl found:
To follow this up for manual inspection, I checked of these URLs if they had a parent with a potential shrink-to-fit parent (abspos, float, table cell, flex).
12,265 of them remain with potential. I did NOT check to see if the parent was setting its own width or if the found element's siblings would have caused the problem to not be noticeable by the end user.
We will follow up on how best we want to determine if this problem will be visible by the end user. @fantasai had some ideas.
Oh, it's worth noting since @fantasai and I had discussed the possibility of manually looking at these pages to extrapolate on I went ahead and grabbed the ID/classes of the parent, as well as the outerHTML of the element that was using max-width with a %. This should aid in finding the parent quickly and then flooring the s2f to see if the input would overflow with adverse affects on the overall layout to the end user.
Ok, @fantasai I have attached it. Let me explain how the columns relate.
Take the following:
This should be read that we found the
I did reach out to our central data science team regarding how to extrapolate on this and they said, without deeper insights that a good starting place is to select 2% of random URLs and review those. If I and this team, have the time I'll try to get a deeper more specific answer to this question so that we can make this calls with an even higher confidence.
Disclaimer - this data is gathered from the web with as limited bias as possible so there may be some offensive sites included in the results.
OK, just to clarify, this is a list of pages that have 'width: auto; max-width: ' on either an INPUT or TEXTAREA, correct?
Probably the easiest way to test would be to use a user stylesheet with
and see if any of the pages appear broken on a random sample of 260 pages from the list.
The CSS Working Group just discussed
RESOLVED: take the change "However, in the case of a replaced box with a percentage-based width/max-width/height/max-height, the percentage is resolved to zero when calculating the min-content contribution in the corresponding axis."
The full IRC log of that discussion<astearns> topic: percentage [max-]width|height and intrinsic sizes
<dbaron> github: https://github.com//issues/765
<tantek> TabAtkins: intrinsic size of some elements with a % width or height
<tantek> fantasai: special behavior that images and form controls have
<tantek> fantasai: if you specify their width as a %, then their min-content size is assigned as if 0 sized
<tantek> fantasai: so this behavior has not been spec'd anywhere and should be spec'd
<tantek> fantasai: the one open consideration, form controls did not do this for max-width, but images did. so images responded to max-width, but form controls didn't
<tantek> fantasai: TabAtkins and I decided to do min and max for both images and form controls
<tantek> fantasai: e.g. you hav especiied mx widht % on a form control. the form control is inside shrink-wrapped container, and the form conrol is affecting the size of the shrink-wrapped container
<tantek> fantasai: seems like a really obscure case and I haven't found any. there may be some out there
<tantek> fantasai: after talking with dbaron it seems that would be ok. want wg resolution to make changes to the spec
<fantasai> s/e.g./the only affected case would be/
<tantek> s/hav especiied mx widht/have specified max width
<tantek> astearns: I want to see the changes in the spec so we can see them in the spec
<tantek> astearns: and discuss them there
<tantek> dbaron: to be clear, the thing that browsers do today isn't in the spec
<tantek> dbaron: tab & fantasai are proposing something simpler but still fairly consistent
<tantek> astearns: are you interested in changing your behavior?
<tantek> dbaron: willing to. have been running with a patch and haven't found anything broken yet
<tantek> dbaron: other part hard here is defining replaced elements
<tantek> TabAtkins: apparently a commit went in today to HTML to define them
<tantek> fremy: on some we are even more inconsistent
<tantek> fantasai: for the sake of sanity we'd like to have ...
<TabAtkins> https://github.com/whatwg/html/pull/2857 PR to define replaced elements
<tantek> fremy: e.g. video element with a slider
<tantek> fremy: all browser but edge, the default size of the contol
<tantek> fremy: meanwhile in edge, default size of 0
<fantasai> Proposed text is "However, in the case of a replaced box with a percentage-based width/max-width/height/max-height, the percentage is resolved to zero when calculating the min-content contribution in the corresponding axis."
<fantasai> in https://drafts.csswg.org/css-sizing/#intrinsic-contribution
<tantek> fantasai: we're not ...
<fantasai> s/fantasai: we're not ...//
<tantek> fremy: there was a slider for the video element which was sized with max-width %
<tantek> fremy: in edge since do we apply ... to this size, the minimum size was ... px, and the author provided size was 41px
<tantek> fremy: in other browsers, they just use the normal default size of the control which was bigger than 41px
<tantek> fremy: I do believe the edge behavior is what the author wanted
<tantek> astearns: if we take this change then ...
<tantek> fremy: all browsers will behave as edge is behaving
<tantek> astearns: any objections to taking this change?
<tantek> dbaron: FWIW I just checked the WHATWG HTML dfn and it's not the one we want
<tantek> dbaron: it's the stricter one
<fremy> well, the website has been redesigned
<tantek> dbaron: it doesn't count form elements
<tantek> dbaron: only images, iframes, input type=image
<dbaron> and a bunch of other things
<tantek> astearns: I'm hearing no objection to making the change
<fantasai> I think we need to add "(including form controls)" here
<tantek> astearns: RESOLVED: take the change "However, in the case of a replaced box with a percentage-based width/max-width/height/max-height, the percentage is resolved to zero when calculating the min-content contribution in the corresponding axis."
@dbaron / @MatsPalmgren Would you mind reviewing the edits to ensure they are correct? The section is https://drafts.csswg.org/css-sizing-3/#intrinsic-contribution and the proposed edits are:
However, I think it wasn't clearly discussed whether the calc() case should resolve to 50px vs. zero. The alternate set of edits would be
@tabatkins Sounds good to me. :) I'll close the issue, then, esp. since the WG resolution explicitly includes that wording and you represent Chrome, which is the browser that (afaict) gets it wrong.
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.
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
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.