Closed Bug 308801 Opened 19 years ago Closed 12 years ago

min-height/max-height does not work for box-sizing:border-box

Categories

(Core :: Layout: Block and Inline, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla17

People

(Reporter: sw, Unassigned)

References

Details

(Keywords: css2, dev-doc-complete, testcase, Whiteboard: [reflow-refactor] fixed by bug 776265)

Attachments

(7 files, 3 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4

I have created a slipped down examples of problematic code which shows that the
new layout engine behaves (Firefox 1.5 Beta 1) differently than the old one
(Firefox 1.0.6).

The red border should be inside the parent box. If you try to comment out the
overflow style for QxWidgetCore the effect go away. But I don't understand why
there is any change in rendering. All elements are positioned absolute and all
sizes should match the requirements of the content so this shouldn't have any
effect.

Reproducible: Always

Steps to Reproduce:
1. Load the example


Actual Results:  
The red box is bigger than the box around it.

Expected Results:  
Should render like the old firefox.

If you remove the min-height:28px inline style or the overflow: hidden from the
QxWidgetCore class it seems to be fixed.
Can you please minimize the testcase to show the issue?
Component: General → Layout
Product: Firefox → Core
QA Contact: general → layout
Version: unspecified → 1.8 Branch
I have reduced it already. This is normally generated by DHTML. But I will try
to slim down it more now. One moment.
Attachment #196303 - Attachment is obsolete: true
Attachment #196319 - Attachment is obsolete: true
Attachment #196320 - Attachment description: Minimized testcase → Minimized testcase (compare branch 1.x with 1.8)
Assignee: nobody → dbaron
Component: Layout → Style System (CSS)
QA Contact: layout → ian
Keywords: testcase
Comment on attachment 196320 [details]
Minimized testcase (compare branch 1.x with 1.8)

This testcase renders as expected. The inner DIV has a specified
min-height:28px and a top-/bottom-border of 1px which makes
the total height 30px. The outer DIV has a specified
height:28px which makes the inner overflow by 2px and since you
specified overflow:hidden it will not be visible.
(This testcase does not reflect what was reported)
Attachment #196320 - Attachment is obsolete: true
Comment on attachment 196319 [details]
Ok, new new minimized test file.

Here the outer DIV has a specified height of 30px also with
1px top/bottom border and with '-moz-box-sizing:border-box'
this gives a content height of 28px.

The first inner DIV have height:28px and no border, so it's
total (border-box) height is 28px.

The second inner DIV have a specified height of 28px + 1px border
which gives a total (border-box) height of 28px.

There is a problem that the 1st inner DIV element is not properly
closed with an end tag. If I close it the problem goes away, but
as far as I can tell this shouldn't matter, since there was no
border for the 1st inner DIV it's content height is 28px and the
2nd inner DIV should fit precisely.
Attachment #196319 - Attachment is obsolete: false
Yes you are right. The last example is missing the:

*{
  box-sizing: border-box;
  -moz-box-sizing: border-box;
}
Attached file Testcase #3 (obsolete) —
Looks like we apply 'min-height' as content height when there is a
ScrollFrame...
Assignee: dbaron → nobody
Status: UNCONFIRMED → NEW
Component: Style System (CSS) → Layout: Block and Inline
Ever confirmed: true
Keywords: css2
OS: Windows XP → All
QA Contact: ian → layout.block-and-inline
Hardware: PC → All
Version: 1.8 Branch → Trunk
Assignee: nobody → mats.palmgren
Attachment #196445 - Attachment is obsolete: true
Summary: Problem with the combination of overflow: hidden, min-height and box-sizing: border-box → min-height/max-height/min-width/max-width does not work for box-sizing:border-box
Assignee: mats.palmgren → nobody
Whiteboard: [reflow-refactor]
The test cases #4 and #5 look fine to me in Firefox 2.0.0.7, or I don't understand what they are supposed to do. As to #6 I have no idea what it's supposed to show...
On 2007120118 Minefield/3.0b2pre (OS X 10.4.11), the min-/max-width test case (testcase #5) is working correctly. The min-/max-height test case (#4) is failing, however.
I do confirm that, testcase #5 works correctly width Firefox 3 Beta 1 on Linux (Xubuntu), too.
But min-height still doesn't work!
(I would like to use that attribute along with border-sizing for my Site!:
http://was-steckt-hinter-freebies.pytalhost.de/
)
It would be great, when it worked on the final!
(I don't speak English as nativ language)
Blocks: 243412
Summary: min-height/max-height/min-width/max-width does not work for box-sizing:border-box → min-height/max-height does not work for box-sizing:border-box
Could someone please work on support for min-height in the "border-box" mode of box-sizing? (Bug #308801)

I don't think box-sizing is particularly well-known among web designers, but it's a useful property and seems to have achieved cross-browser support--with the possible exception of this Firefox bug.

Case in point: A recent web page design featuring a dynamic main area, with a footer positioned absolutely at the bottom. Applying "min-height: 100%" to the main container allows it to extend to the full window height even when the content is minimal, while "box-sizing: border-box" allows padding to be added directly to the container to accommodate the absolutely positioned footer, without any accidental overlap between the two sections.

The above-described layout works beautifully in Safari 4.0.5 and Opera 10.10, but breaks in Firefox 3.6 (where it appears as if padding is added after the 100% height, extending the page beyond window height, and forcing the footer below). I have not tested this in IE, but I understand that box-sizing is supported in IE8.

Thank you for your consideration of this problem.
Here's a test case (attached) to help illustrate my previous comment. In this example, the desired layout is a page that occupies the full height of the browser window—at any zoom level or window size—with a footer positioned at the bottom.

   1. To ensure the page will stretch to full window height, "height:100%" is applied to html and body elements, and "min-height:100%" is applied to the wrapper div containing all the page's content:

      html, body {height: 100%;}
      #wrapper {min-height: 100%;}

   2. So that the footer (in black) will appear at the bottom of the window, it is positioned absolutely in relation to the surrounding wrapper:

      #wrapper {position: relative;}
      #footer {position: absolute; bottom: 0;}

   3. To keep the footer from overlapping the main content (e.g., at higher zoom levels or smaller window sizes), the wrapper is assigned bottom padding to compensate for the height of the footer:

      #wrapper {padding-bottom: 9em;}

   4. At this point, the footer will always appear below the window and out of view no matter what the height of the main content, as the padding that was assigned to the wrapper is not included in the calculated min-height (Thanks a lot, content box model!). To fix this, the border box model is invoked via the box-sizing property:

      #wrapper {
      box-sizing: border-box;
      -moz-box-sizing: border-box;
      -webkit-box-sizing: border-box;
      }

Voila! Well, almost. Step 4 is where the layout breaks uniquely in Firefox (but not in other current browsers). The footer continues to appear below the browser window, out of view, just as in Step 3. In other browsers (e.g., Safari and Opera), the layout renders beautifully at any zoom level or window size. But it seems that in Firefox, min-height does not acknowledge the border-box model (?).

Please note that the layout described above can be especially useful in situations where the main content is dynamic—for example, a search results page, where the output may occupy an entire window or just a few lines.

I hope this helps, and I hope someone can try solving this issue!

Thanks!
Attachment #444269 - Attachment description: A page layout using min-height and border-box → Testcase: A page layout using min-height and border-box
Blocks: 653643
I also just ran into this, here was the test case I created: http://jsfiddle.net/5NnFg/1/

Notice how in webkit (chrome and safari) the total height of the ul is 36px, but in Firefox 4 it is 45px.
Whiteboard: [parity-opera] [parity-webkit]
Keywords: CSS3
I have this issue too.

Platform: Windows 7 Firefox 5.
Sample: http://jsfiddle.net/dpJyk/1/

On IE9, li's height is 51px,
On chrome 13, li's height is 51px too
On Firefox 5, li's height is 71px. Apparently the padding does confused min-height.
I was about to report the same issue. Here's the testcase I was going to submit, in case it helps in something: http://jsfiddle.net/leaverou/qJ8MX/show
Basically this requires looking at all the callers of nsLayoutUtils::ComputeHeightValue:
http://mxr.mozilla.org/mozilla-central/search?string=computeheightvalue

The ones in nsFrame.cpp already handle box-sizing; the others don't.  Probably the right thing to do is move the box-sizing handling *inside* ComputeHeightValue (but not ComputeHeightDependentValue) like we already do for nsLayoutUtils::ComputeWidthValue.
The other thing to be careful of is that we don't want to handle box-sizing twice for 'height'.  We probably want box-sizing handled by the time we're done ComputeHeightValue, which might mean we'd need to remove handling somewhere else to avoid its effect being doubled.
I just ran into this as well. As noted by Lionel above, IE9 behaves as expected, thus making this a compatibility issue, in addition to a layout headache.
Just another vote for this to be fixed. This fiddle demo of the problem was sent to me by Beau Smith

http://jsfiddle.net/beau/SCUED/
Firstly, just asking for this to be fixed, like soon. This bug "borks" my blog - http://blog.nath.is

Secondly, can I ask how this has been open close to 7 years, and it still hasn't been fixed? Over 10 major releases, and it still hasn't been fixed. Sound crazy to you?
Hi Nathaniel,

I am not from the Firefox team, but since I have spent quite some time in the Mozilla project, I feel I can reply to your questions.

(In reply to Nathaniel Higgins from comment #28)
> Firstly, just asking for this to be fixed, like soon. This bug "borks" my
> blog - http://blog.nath.is
> 
> Secondly, can I ask how this has been open close to 7 years, and it still
> hasn't been fixed?
During these 7 years, a ridiculous amount of CSS features have also been implemented, like transitions, transformations, multiple-background, calc(), etc. As it turns out, the web is composed of plenty of technologies and for one person asking for a bugfix in a rare case (min-height in border-sizing:border-box is a rare case), you have thousands of people asking for the shiny border-radius or gradients.
Additionally to an already well-filled roadmap is that Mozilla has limited resources (paid staff and contributors). So it all comes down to priorities. And apparently this bug is currently not a priority.


> Over 10 major releases, and it still hasn't been fixed.
> Sound crazy to you?
It does not to me. I understand your frustration and I feel exactly the same way you do for some JavaScript bugs (I'm more of a JavaScript guy). But that's the game. This bug has not been fixed because people were working on other things. Implementing more important features, fixing more important bugs.

"just asking" for this bug to be fixed is not what will get it fixed faster as far as I know. So, either you're willing to contribute and get this bug fixed or do what everyone CC'ed on this bug does: patiently wait and find a workaround meanwhile.
I don’t code in C or XUL or whatever else is being used for the Mozilla/Gecko engine, so I can't really contribute anything myself other than additional test cases (which seems unnecessary at this point), but since this is OPEN Source, and since WebKit is also open source, wouldn't it be possible to at least look at—and learn from—how their implementation of this is handled, since theirs works perfectly fine?

I guess I'm just surprised that two open-source projects doing the exact same thing have such widely differing code bases that no knowledge can be shared, nor benefits claimed. There’s something contradictory about open source in there ;)
This has nothing to do with learning how to fix it; that's just work.  It's about somebody thinking that fixing it is worth the time to do so when box-sizing is a poorly-designed feature that's frankly intended only for backwards-compatibility with quirks mode.
Oh, and see comment 24 and comment 25 for a description of how to fix it.
Whiteboard: [reflow-refactor] → [reflow-refactor][see comment 24 and 25 for how to fix]
I’d like to apologize here (as well) for my earlier comment; it was not meant to sound hostile—the little joke at the end being specifically intended to make that clear—but I understand that some can legitimately feel that it was, so: apologies. 

What I meant to express was simply my surprise which came about from discovering that 7 years later this bug is still unresolved, and only in Firefox at that. Part of the surprise stemmed from the fact that I find a great benefit to OSS being that you can learn from (if not reuse) other people's code when it does the same thing. I see now that David outlined a fix above, which wasn’t particularly clear to me earlier since I don’t speak browser vendor lingo. I do hope that people can understand that much, at least.

The reason I drew people’s attention to this bug on Twitter is because thus far, it seems it doesn't have enough votes to get the priority needed to get it fixed. Surely that's exactly what the voting system is for, though?
(In reply to Faruk Ates from comment #33)
> What I meant to express was simply my surprise which came about from
> discovering that 7 years later this bug is still unresolved, and only in
> Firefox at that. Part of the surprise stemmed from the fact that I find a
> great benefit to OSS being that you can learn from (if not reuse) other
> people's code when it does the same thing.
I get what you mean, but I don't think your reasoning is right. Let's say you're writing an open source wiki engine and there are other open source wiki engine. When editing a page, you have a "preview" feature. Let's say yours is buggy. Would it be of any help to look at how other wikis get their "preview" correctly?
My guess is that it's likely that the wiki engine architectures are very different, so implementing the same feature is done very differently.


> The reason I drew people’s attention to this bug on Twitter is because thus
> far, it seems it doesn't have enough votes to get the priority needed to get
> it fixed. Surely that's exactly what the voting system is for, though?
I don't mean to be pessimistic, but I can't recall having seen one bug receiving more attention because it had more votes. Whatever your feeling is on this sentence, I feel the same :-)
Blocks: 777258
Depends on: 776265
I really think this bug should get attention.

The obvious way to get a 100% height container yet also have padding on the body (surely a common desire) is to use min-height: 100% in combination with border-box and padding. I'm sure I'm not the only one that's been frustrated by Firefox's lack of support on this, it forces me to use an extra wrapper div just for the sake of Firefox when every other browser can deal just fine.
(In reply to David Baron [:dbaron] from comment #31)
> when box-sizing is a poorly-designed feature that's frankly intended only for
> backwards-compatibility with quirks mode.

I can think of countless uses beyond "backwards compatibility with quirks mode". I don't understand your statement that it is "poorly designed". This feature seems far too simple and useful for anything to be poor about its design.
It's poorly designed because mode-switch properties are a bad idea in CSS.  When the styles come from different sources, a property that switches how other properties behave can make other styles behave the wrong way.

Correctly designed, this probably would have been an extra keyword on the 'width' (etc.) properties, e.g., "width: 100% border-box" rather than a separate property.
(In reply to David Baron [:dbaron] from comment #37)
> It's poorly designed because mode-switch properties are a bad idea in CSS. 

While I don’t disagree with that, the property is implemented in all browsers, and Firefox—and only Firefox—just happens to have one particular situation (a specific property) where the implementation fails to take effect. That makes the design aspects of the feature seem, to me at least, entirely irrelevant at this point.

This isn't a new feature or property in any way, this is something that FFox has been doing wrong for min/max-height ever since the overall feature of box-sizing was implemented many years ago, and which not a single other browser has raised a fuss over. The time for discussion around the design of the feature really seems 8 years ago.
(In reply to David Baron [:dbaron] from comment #37)
> It's poorly designed because mode-switch properties are a bad idea in CSS. 
> When the styles come from different sources, a property that switches how
> other properties behave can make other styles behave the wrong way.

You're probably confusing implementation difficulties with bad design of the feature itself. From web-developer perspective, `box-sizing` is totally intuitive, usable, and useful (especially in conjunction with `min-height` for form elements where adding an extra wrapper to workaround this Firefox bug is just impossible).

> Correctly designed, this probably would have been an extra keyword on the
> 'width' (etc.) properties, e.g., "width: 100% border-box" rather than a
> separate property.

This unlikely would make `min-height`+`border-box` combination implementation easier.
(In reply to David Baron [:dbaron] from comment #31)
> This has nothing to do with learning how to fix it; that's just work.  It's
> about somebody thinking that fixing it is worth the time to do so when
> box-sizing is a poorly-designed feature that's frankly intended only for
> backwards-compatibility with quirks mode.

Sorry, but you are fool!
w3c box-size model worse than MS box-size model and it is know every of web-master.
I very happy because I can change box-size in development today. But 2 years ago I must create thousands spikes.
(In reply to David Baron [:dbaron] from comment #37)
> It's poorly designed because mode-switch properties are a bad idea in CSS. 
> When the styles come from different sources, a property that switches how
> other properties behave can make other styles behave the wrong way.

I disagree that this is a big problem. Currently we have many CSS properties that change the meaning and/or behavior of other properties as a side effect (e.g. 'width: auto' behaves differently for different 'display' values, 'height: 100%' has different meaning in static and absolute positioning, vertical alignment of inline-blocks depends on their 'overflow', etc.). Having the property that has the only effect in changing of box calculation rules (very intuitive) isn't something new or exceptional in CSS, on the contrary, it makes the CSS rule much easier to understand, than the compound values for length (which may also become hard to be parsed).

I also can't agree that 'box-sizing: border-box' has anything to do with quirks mode, at least because Firefox itself doesn't use it in quirks mode:). As Marat Tanalin mentioned above, this box model is EXTREMELY useful in many practical use cases (e.g. column with width in "%" and padding/border in "px/em", sticky footer with container padding etc.), it's implemented in ALL other browsers, it's well-promoted (http://paulirish.com/2012/box-sizing-border-box-ftw/), and there are even CSS frameworks based on it (https://github.com/vladocar/Box-CSS-Framework). An at least 54 people here agree that this bug IS worth fixing!
Border-box is massively useful, even more so for responsive/adaptive design. It makes no sense to apply the principle to the width, but not the height – it is expected behaviour if you are choosing to use border-box.

Let's not forget this is an optional style so a fix is being requested for those that use and understand it, not breaking something for those that don't.

I really don't understand why heels are digging in when the request is so logical.
I'm not digging my heels; I'm merely explaining why it's not a high priority for me.

I explained quite clearly how to fix the bug in comment 24 and comment 25 for anyone else who wants to pick up the work.
These pass locally on Linux64 debug with the patch in bug 776265.
https://hg.mozilla.org/mozilla-central/rev/8e7ce1cd72a6
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
Whiteboard: [reflow-refactor][see comment 24 and 25 for how to fix] → [reflow-refactor] fixed by bug 776265
No longer blocks: 777258
Keywords: dev-doc-needed
I think I can speak for a lot of people, thanks for working on this bug and getting it fixed.
If it has been fixed, what is holding this from being unprefixed?
(In reply to paulo8624 from comment #50)
> If it has been fixed, what is holding this from being unprefixed?

(following up on this: box-sizing has now been unprefixed -- see bug 243412.)
You need to log in before you can comment on or make changes to this bug.