support -moz-fit-content, and -moz-available for height/min-height/max-height (block axis)
Categories
(Core :: Layout, defect)
Tracking
()
Webcompat Priority | P2 |
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•13 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•13 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
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•13 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•13 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•8 years ago
|
Updated•8 years ago
|
Comment 14•8 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•8 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•8 years ago
|
||
See also IsNonAutoNonZeroBSize (helper used by nsBlockFrame::IsSelfEmpty), which received a similar tweak in bug 1126420.
Updated•7 years ago
|
Comment 18•6 years ago
|
||
Is there any progress here?
Comment 20•5 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.
Comment 21•5 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•5 years ago
|
||
Probably also depends on Bug 527285, or a duplication.
Comment 23•5 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•5 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
Comment 25•4 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•3 years 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•3 years ago
|
Updated•3 years ago
|
Comment hidden (advocacy) |
Updated•2 years ago
|
![]() |
||
Updated•2 years ago
|
Updated•6 months ago
|
Comment hidden (obsolete) |
Comment hidden (obsolete) |
Comment 30•5 months ago
|
||
May I ask when this bug can be fixed? After 13 years, I am now encountering the problem that this attribute does not take effect, online and so on
Comment 31•5 months ago
|
||
(In reply to 289455964 from comment #30)
May I ask when this bug can be fixed?
It's been partly fixed; comment 24 noted that part of the bug's original scope has now been addressed (and updated the bug summary accordingly).
I am now encountering the problem that this attribute does not take effect
Could you post a testcase (or file a new dependent bug with a testcase), particularly if you're running into a case where things work the way you expect in other browsers but not in Firefox?
Comment 32•5 months ago
|
||
(In reply to Daniel Holbert [:dholbert] from comment #31)
The problem I ran into was height: -moz-available; Not valid, address: details
This is an image
Comment 33•5 months ago
|
||
(In reply to Daniel Holbert [:dholbert] from comment #31)
Fixfox version: 106.0.2
Description
•