Open
Bug 567039
Opened 11 years ago
Updated 2 months ago
support -moz-fit-content, and -moz-available for height/min-height/max-height (block axis)
Categories
(Core :: Layout, defect)
Core
Layout
Tracking
()
NEW
People
(Reporter: giorgio.liscio, Unassigned)
References
(Depends on 1 open bug, Blocks 2 open bugs, )
Details
(Keywords: dev-doc-needed)
Attachments
(2 files)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; WOW64; en-US; rv:1.9.3a5pre) Gecko/20100518 Minefield/3.7a5pre ( .NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; WOW64; en-US; rv:1.9.3a5pre) Gecko/20100518 Minefield/3.7a5pre ( .NET CLR 3.5.30729) hi, I've tried the new css values of intrinsic sizing and they are a fantastic improvement in the box design, but i really do not understand why they are only relative to width and not for height too in flexbox orientation, for example, the improvement is only relative to horizontal oriented items as David Baron proposes, the values should be definitely accepted by height too http://dbaron.org/css/intrinsic/#new-width-values http://lists.w3.org/Archives/Public/www-style/2007Nov/0119.html thank you for your time Reproducible: Always
Comment 1•11 years ago
|
||
What would they mean for height?
hi David, i mean min-width:-moz-min-content; works min-height:-moz-min-content; does not -moz-*-content works only on [min|max]width
Comment 3•11 years ago
|
||
I know that. I'm asking what you want them to do.
ok sorry, i've bad interpreted your message... i'm building right now a simple test where min-content & co are useful thank you
in the meanwhile i try to simplify my problem for submitting here, i ask you what do you have concluded about this... what I've read let me think that you have decided to propose min|max-content for height too... but now i think not... this values are not available for height for a valid reason... height:auto is equivalent to min-content but i think with one or more exceptions, in my case when display:block is used in conjunction with display:box i'm not sure if my test is valid and maybe there is a workaround, but i try to submit it here
i don't know what is the problem... maybe the problem is html{min-height:100%;} that is not working if i can specify it instead of height:100%; probably it will works now i think that is another problem and not relative to min-content bye
Attachment #446609 -
Attachment description: test min content → test min content
(run outer.htm)
boris, on step 3 of the attachment here the border image follows the minimum width of the contained purple bordered box but in height not, there's no way to make the border image following content's height
![]() |
||
Comment 8•11 years ago
|
||
min-height: 100% would work fine for you if you had a non-auto height on <html>, no?
I'm trying to set a border image on the body the border image should have as minimum size the client(iframe) minimum width and minimum height -- min-height:100%; height:auto; on <html> should work, but min-height:100% on documentelement is probably not computed
![]() |
||
Comment 10•11 years ago
|
||
> but min-height:100% on documentelement is probably not computed
It is. But "height: auto" on the root means that a percentage height on the body will be ignored. Is there a reason you can't put your border-image on the <html>?
Updated•6 years ago
|
Status: UNCONFIRMED → NEW
Component: CSS Parsing and Computation → Layout
Ever confirmed: true
OS: Windows XP → All
Hardware: x86 → All
Summary: request for min-content max-content etc for "HEIGHT" too → support min-content, max-content, fit-content, and fill for height/min-height/max-height too
Updated•6 years ago
|
Keywords: dev-doc-needed
Comment 14•6 years ago
|
||
In vertical writing modes, the existing implementation for the width properties doesn't work (as it's really an implementation for inline-size). We should let it apply to height properties instead, but we don't parse these values there.
Comment 15•6 years ago
|
||
Fixing this involves fixing the callers of IsAutoBSize (which was tweaked in bug 1113216 to provide an auto/none/0-like behavior) to do the correct thing for thee values, which in some cases my involve propagating them on the nsHTMLReflowState.
Comment 16•6 years ago
|
||
See also IsNonAutoNonZeroBSize (helper used by nsBlockFrame::IsSelfEmpty), which received a similar tweak in bug 1126420.
Updated•4 years ago
|
Blocks: css-sizing-3
Comment 18•4 years ago
|
||
Is there any progress here?
Comment 20•3 years ago
|
||
I interpreted this bug as meaning adding support of min-content, max-content and fit-content for an inline size in vertical writing mode, but it meant adding support of these values for a block size in horizontal writing mode.
Flags: needinfo?(dbaron)
Comment 21•3 years ago
|
||
https://stackoverflow.com/questions/49647758/how-to-show-variable-number-of-elements-based-on-css-variable-value/49660163?noredirect=1#comment86334787_49660163 bemoans the lack of support for max-height: min-content;
Comment 22•2 years ago
|
||
Probably also depends on Bug 527285, or a duplication.
Comment 23•2 years ago
|
||
According to Bug 1322780 Comment 27, if we want to have a correct implementation, we may need to wait for the major spec issues solved, like https://github.com/w3c/csswg-drafts/issues/2890.
Comment 24•2 years ago
|
||
Bug 1496558 makes sure we handle `max-content` and `min-content` properly in block axis. i.e. Behave as the property's initial value [1][2]. For -moz-fill-content and -moz-available, we still treat them as initial values for now. (Only getComputedStyle() returns the correct keywords.) [1] https://drafts.csswg.org/css-sizing/#valdef-width-min-content [2] https://drafts.csswg.org/css-sizing/#valdef-width-max-content
Summary: support min-content, max-content, fit-content, and fill for height/min-height/max-height too → support -moz-fit-content, and -moz-available for height/min-height/max-height (block axis)
Comment 25•2 years ago
|
||
I recreated a situation where is useful to set -moz-min-content to height of an element: when it's a grid item. Tested on Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0
Comment 26•1 year ago
|
||
Hello, there's an issue in Webcompat.com (https://github.com/webcompat/web-bugs/issues/38293) where a site uses both height:100vh
and height:-moz-available
on a <div>
. It seems that Gecko renders its height as null
since it swaps out 100vh
in favor of -moz-available
.
The site owner was successfully contacted while this issue hasn't been fixed yet.
Updated•1 year ago
|
Updated•1 year ago
|
Comment hidden (advocacy) |
You need to log in
before you can comment on or make changes to this bug.
Description
•