Open Bug 567039 Opened 14 years ago Updated 14 days ago

support -moz-fit-content, and -moz-available for height/min-height/max-height (block axis)

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

People

(Reporter: giorgio.liscio, Unassigned)

References

(Depends on 1 open bug, Blocks 2 open bugs,
URL
)

Details

(Keywords: dev-doc-needed)

Attachments

(2 files)

test min content (run outer.htm)
1.46 KB, application/x-zip
Details
resizing_grid_items.zip
27.41 KB, application/x-zip-compressed
Details 
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
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
> 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>?
See Also: → 852367
URL: http://dev.w3.org/csswg/css-sizing/#w...
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
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.
See also IsNonAutoNonZeroBSize (helper used by nsBlockFrame::IsSelfEmpty), which received a similar tweak in bug 1126420.
No longer blocks: 1044597
Is there any progress here?
I think this bug should also block bug 145503 .
Flags: needinfo?(dbaron)
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)
Depends on: 1496558
Probably also depends on Bug 527285, or a duplication.
Depends on: 527285
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.
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)
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
Blocks: 1495868

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.

Webcompat Priority: --- → ?
See Also: → 1693399
Webcompat Priority: ? → P2
Severity: normal → S3

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

(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?

(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

(In reply to Daniel Holbert [:dholbert] from comment #31)

Fixfox version: 106.0.2

None of the sites listed seem to have webcompat issues with this anymore, so dropping the webcompat priority for now.

Webcompat Priority: P2 → ---
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: