support -moz-fit-content, and -moz-available for height/min-height/max-height (block axis)
NEW
Unassigned
Status
()
People
(Reporter: giorgio.liscio, Unassigned)
Tracking
(Depends on 1 bug, Blocks 2 bugs, {dev-doc-needed})
Firefox Tracking Flags
(Not tracked)
Details
()
Attachments
(2 attachments)
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
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
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•9 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•9 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•5 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•5 years ago
|
Keywords: dev-doc-needed
Blocks: 1044597
|
||
Comment 14•4 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.
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•4 years ago
|
||
See also IsNonAutoNonZeroBSize (helper used by nsBlockFrame::IsSelfEmpty), which received a similar tweak in bug 1126420.
|
|
||
Updated•3 years ago
|
Blocks: css-sizing-3
|
||
Comment 18•2 years ago
|
||
Is there any progress here?
|
||
Comment 20•a year 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•a year 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•8 months ago
|
||
Probably also depends on Bug 527285, or a duplication.
|
||
Comment 23•8 months 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•7 months 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•6 months 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
You need to log in
before you can comment on or make changes to this bug.
Description
•