Last Comment Bug 308801 - min-height/max-height does not work for box-sizing:border-box
: min-height/max-height does not work for box-sizing:border-box
Status: RESOLVED FIXED
[reflow-refactor] fixed by bug 776265
: css2, dev-doc-complete, testcase
Product: Core
Classification: Components
Component: Layout: Block and Inline (show other bugs)
: Trunk
: All All
: -- normal with 56 votes (vote)
: mozilla17
Assigned To: Nobody; OK to take it and work on it
:
: Jet Villegas (:jet)
Mentors:
: 406438 653643 777258 (view as bug list)
Depends on: 776265
Blocks: 243412 653643
  Show dependency treegraph
 
Reported: 2005-09-16 03:13 PDT by Sebastian Werner
Modified: 2014-08-07 14:35 PDT (History)
53 users (show)
mats: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
The test file described in the bug report. (6.57 KB, text/html)
2005-09-16 03:15 PDT, Sebastian Werner
no flags Details
Ok, new new minimized test file. (1.18 KB, text/html)
2005-09-16 05:48 PDT, Sebastian Werner
no flags Details
Minimized testcase (compare branch 1.x with 1.8) (311 bytes, text/html)
2005-09-16 06:59 PDT, José Jeria
no flags Details
the corrected minimized example (368 bytes, text/html)
2005-09-17 10:53 PDT, Sebastian Werner
no flags Details
Testcase #3 (962 bytes, text/html)
2005-09-17 12:09 PDT, Mats Palmgren (:mats)
no flags Details
Testcase #4, min-/max-height (2.74 KB, text/html)
2005-09-18 13:53 PDT, Mats Palmgren (:mats)
no flags Details
Testcase #5, min-/max-width (2.67 KB, text/html)
2005-09-18 13:54 PDT, Mats Palmgren (:mats)
no flags Details
Testcase #6, <select> lists (989 bytes, text/html)
2005-09-18 13:59 PDT, Mats Palmgren (:mats)
no flags Details
Testcase: A page layout using min-height and border-box (6.96 KB, text/html)
2010-05-08 11:19 PDT, ddowning8
no flags Details
Testcase #4 and #5 converted to reftests (8.35 KB, patch)
2012-08-18 10:15 PDT, Mats Palmgren (:mats)
no flags Details | Diff | Splinter Review

Description Sebastian Werner 2005-09-16 03:13:45 PDT
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.
Comment 1 Sebastian Werner 2005-09-16 03:15:39 PDT
Created attachment 196303 [details]
The test file described in the bug report.
Comment 2 José Jeria 2005-09-16 05:33:27 PDT
Can you please minimize the testcase to show the issue?
Comment 3 Sebastian Werner 2005-09-16 05:34:54 PDT
I have reduced it already. This is normally generated by DHTML. But I will try
to slim down it more now. One moment.
Comment 4 Sebastian Werner 2005-09-16 05:48:42 PDT
Created attachment 196319 [details]
Ok, new new minimized test file.
Comment 5 José Jeria 2005-09-16 06:59:10 PDT
Created attachment 196320 [details]
Minimized testcase (compare branch 1.x with 1.8)
Comment 6 Mats Palmgren (:mats) 2005-09-17 10:41:22 PDT
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)
Comment 7 Mats Palmgren (:mats) 2005-09-17 10:46:30 PDT
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.
Comment 8 Sebastian Werner 2005-09-17 10:50:34 PDT
Yes you are right. The last example is missing the:

*{
  box-sizing: border-box;
  -moz-box-sizing: border-box;
}
Comment 9 Sebastian Werner 2005-09-17 10:53:16 PDT
Created attachment 196435 [details]
the corrected minimized example
Comment 10 Mats Palmgren (:mats) 2005-09-17 12:09:01 PDT
Created attachment 196445 [details]
Testcase #3

Looks like we apply 'min-height' as content height when there is a
ScrollFrame...
Comment 11 Mats Palmgren (:mats) 2005-09-18 13:53:04 PDT
Created attachment 196586 [details]
Testcase #4, min-/max-height
Comment 12 Mats Palmgren (:mats) 2005-09-18 13:54:10 PDT
Created attachment 196587 [details]
Testcase #5, min-/max-width
Comment 13 Mats Palmgren (:mats) 2005-09-18 13:59:20 PDT
Created attachment 196588 [details]
Testcase #6, <select> lists
Comment 14 Marcus Better 2007-10-18 02:03:01 PDT
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...
Comment 15 philippe (part-time) 2007-12-02 17:36:55 PST
*** Bug 406438 has been marked as a duplicate of this bug. ***
Comment 16 philippe (part-time) 2007-12-02 17:46:38 PST
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.
Comment 17 KekS 2007-12-03 05:24:30 PST
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)
Comment 18 ddowning8 2010-03-16 16:41:20 PDT
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.
Comment 19 ddowning8 2010-05-08 11:19:06 PDT
Created attachment 444269 [details]
Testcase: A page layout using min-height and border-box

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!
Comment 20 Tim Finley 2011-05-05 07:57:44 PDT
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.
Comment 21 Tantek Çelik 2011-07-14 10:36:21 PDT
Whiteboard: [parity-opera] [parity-webkit]
Keywords: CSS3
Comment 22 Lionel Chan 2011-08-15 01:26:26 PDT
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.
Comment 23 Lea Verou 2011-12-01 03:53:57 PST
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
Comment 24 David Baron :dbaron: ⌚️UTC-8 2011-12-02 12:42:43 PST
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.
Comment 25 David Baron :dbaron: ⌚️UTC-8 2011-12-02 12:45:32 PST
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.
Comment 26 Curt Carpenter 2012-02-15 17:06:07 PST
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.
Comment 27 Chris Coyier 2012-04-05 14:03:37 PDT
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/
Comment 28 Nathaniel Higgins 2012-05-12 16:41:33 PDT
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?
Comment 29 David Bruant 2012-05-12 17:03:11 PDT
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.
Comment 30 Faruk Ates 2012-06-16 23:49:31 PDT
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 ;)
Comment 31 David Baron :dbaron: ⌚️UTC-8 2012-06-16 23:58:28 PDT
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.
Comment 32 David Baron :dbaron: ⌚️UTC-8 2012-06-17 00:02:49 PDT
Oh, and see comment 24 and comment 25 for a description of how to fix it.
Comment 33 Faruk Ates 2012-06-17 00:22:48 PDT
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?
Comment 34 David Bruant 2012-06-17 01:56:16 PDT
(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 :-)
Comment 35 mozilla 2012-08-07 15:58:24 PDT
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.
Comment 36 mozilla 2012-08-07 16:09:31 PDT
(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.
Comment 37 David Baron :dbaron: ⌚️UTC-8 2012-08-07 16:26:42 PDT
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.
Comment 38 Faruk Ates 2012-08-07 17:27:29 PDT
(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.
Comment 39 Marat Tanalin | tanalin.com 2012-08-08 01:02:28 PDT
(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.
Comment 40 kir_ss 2012-08-12 06:24:20 PDT
(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.
Comment 41 Ilya 2012-08-14 04:18:22 PDT
(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!
Comment 42 Graeme Blackwood 2012-08-14 04:40:48 PDT
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.
Comment 43 David Baron :dbaron: ⌚️UTC-8 2012-08-14 11:48:49 PDT
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.
Comment 44 Mats Palmgren (:mats) 2012-08-18 10:15:27 PDT
Created attachment 653084 [details] [diff] [review]
Testcase #4 and #5 converted to reftests

These pass locally on Linux64 debug with the patch in bug 776265.
Comment 45 Mats Palmgren (:mats) 2012-08-19 18:18:40 PDT
Landed the reftests:
https://hg.mozilla.org/integration/mozilla-inbound/rev/8e7ce1cd72a6
Comment 46 Ed Morley [:emorley] 2012-08-20 08:55:19 PDT
https://hg.mozilla.org/mozilla-central/rev/8e7ce1cd72a6
Comment 47 Dão Gottwald [:dao] 2012-08-20 09:06:52 PDT
*** Bug 777258 has been marked as a duplicate of this bug. ***
Comment 49 jeffw 2012-09-04 08:53:41 PDT
I think I can speak for a lot of people, thanks for working on this bug and getting it fixed.
Comment 50 paulo8624 2013-03-07 19:06:05 PST
If it has been fixed, what is holding this from being unprefixed?
Comment 51 Jorge Villalobos [:jorgev] 2013-12-10 15:24:27 PST
*** Bug 653643 has been marked as a duplicate of this bug. ***
Comment 52 Daniel Holbert [:dholbert] 2014-08-07 14:35:24 PDT
(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.)

Note You need to log in before you can comment on or make changes to this bug.