As a security precaution, we have turned on the setting "Require API key authentication for API requests" for everyone. If this has broken something, please contact
Last Comment Bug 295315 - table-cell height calculation uses border-box sizing; should use content-box
: table-cell height calculation uses border-box sizing; should use content-box
Status: RESOLVED DUPLICATE of bug 248239
: testcase
Product: Core
Classification: Components
Component: Layout: Tables (show other bugs)
: Trunk
: x86 All
: -- normal with 2 votes (vote)
: ---
Assigned To: Bernd
: 609757 668444 (view as bug list)
Depends on:
Blocks: css2.1-tests
  Show dependency treegraph
Reported: 2005-05-24 02:06 PDT by Jon Levell
Modified: 2012-07-02 12:52 PDT (History)
11 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

strict testcase (458 bytes, text/html)
2005-06-04 04:19 PDT, Bernd
no flags Details
quirks mode testcase (293 bytes, text/html)
2005-06-04 04:21 PDT, Bernd
no flags Details
patch (3.08 KB, patch)
2005-06-04 11:46 PDT, Bernd
bzbarsky: review-
bzbarsky: superreview-
Details | Diff | Splinter Review
strict pct testcase (645 bytes, text/html)
2011-08-27 01:28 PDT, Bernd
no flags Details
comparative rendering (50.65 KB, image/png)
2011-08-27 01:28 PDT, Bernd
no flags Details

Description User image Jon Levell 2005-05-24 02:06:18 PDT
At the URL given I would expect the red table to be as tall as it is wide (And
the offsetHeight reported in the alert to be strictly greater than than the
style.height reported).

The width and height of the cell are bigger than its contents, setting the width
to 50 pixels means the overall width of the cell (including a cellpadding of
5px) is 60px, which is correct (as I understand the box model).

Setting the height of the cell to 50, causes the overall height of the cell
(including the cellpadding of 5px) to be (much to my surprise) 50 pixels.

It doesn't matter if I set the height via <td height="" or <td style="height:.."

I don't understand why the calculation of the width and height of the cell are

This is a such a simple bug, that if it really was a bug, it would have been
report ad-infinitum but I don't know what I'm misunderstanding. I don't think
this is a dup of bug 22274 as giving the img a display style of block or
changing it to a few characters gives the same results - help?

(Tested with Mozilla Suite and Firefox 0.9.x upto latest 1.1 nightlies on Win
and Lin).
Comment 1 User image Jon Levell 2005-05-24 04:41:08 PDT
I should have mentioned that IE6 treats the Height equivalently to the width (so
the red box is square) as I (mistakenly?) expect.  (Konq. 3.3.1 has a more
oblong box than Gecko and seems to ignore the height attribute entirely so that
the offsetHeight is only 30px).
Comment 2 User image Bernd 2005-05-24 11:50:02 PDT
yeah it seems that the height is applied including the padding
Comment 3 User image Bernd 2005-06-04 04:19:35 PDT
Created attachment 185330 [details]
strict testcase
Comment 4 User image Bernd 2005-06-04 04:21:58 PDT
Created attachment 185331 [details]
quirks mode testcase

IE does differentiate between quirks and standards mode. So we need to follow
we should fix the behaviour for standards mode rendering and leave it as it is
for quriks mode.
Comment 5 User image Bernd 2005-06-04 11:46:05 PDT
Created attachment 185354 [details] [diff] [review]
Comment 6 User image Jon Levell 2005-06-29 03:08:27 PDT
This seems to work just fine to me - assuming people with the relevant authority
r & sr the patch should it be checked in pre or post Firefox 1.1?
Comment 7 User image Bernd 2005-06-29 22:11:14 PDT
the patch needs to be rtest`ed
Comment 8 User image Bernd 2005-10-08 08:22:35 PDT
Comment on attachment 185354 [details] [diff] [review]

I rtested the patch, the only testcases that changed the behaviour, have been
the cases where in standards mode the height was defined, but that was
Comment 9 User image Boris Zbarsky [:bz] (still a bit busy) 2005-10-09 12:17:39 PDT
Comment on attachment 185354 [details] [diff] [review]

>Index: nsTableRowFrame.cpp
>+    borderPadding = nsTableFrame::GetBorderPadding(nsSize(0, 0),
>+      GetPresContext()->PixelsToTwips(), (nsTableCellFrame*) aCellFrame);

Why 0x0? Won't this mess up percentage paddings?

>     case eStyleUnit_Percent: {
>+        SetPctHeight(position->mHeight.GetPercentValue() + + borderPadding.bottom);

No, this is wrong -- it's mixing percent and twips.
Comment 10 User image Bernd 2008-03-02 04:46:48 PST
Boris if I go for fixed height only patch similar to the one that you correctly r-ed, do I have chance to get this reviewed while leaving the pct case unfixed?
Comment 11 User image Boris Zbarsky [:bz] (still a bit busy) 2008-03-02 10:21:28 PST
To be honest, I think David would be better-qualified to review this; he's been doing a lot more table layout stuff recently.
Comment 12 User image David Baron :dbaron: ⌚️UTC-8 2010-11-13 08:32:35 PST
*** Bug 609757 has been marked as a duplicate of this bug. ***
Comment 13 User image gadjo 2011-01-16 04:47:45 PST
isn't it a dupe of bug 248239?
Comment 14 User image Cork 2011-06-29 22:22:02 PDT
*** Bug 668444 has been marked as a duplicate of this bug. ***
Comment 15 User image Bernd 2011-08-27 01:28:13 PDT
Created attachment 556233 [details]
strict pct testcase
Comment 16 User image Bernd 2011-08-27 01:28:39 PDT
Created attachment 556234 [details]
comparative rendering
Comment 17 User image Gérard Talbot 2012-01-13 13:35:12 PST
(In reply to Bernd from comment #15)
> Created attachment 556233 [details]
> strict pct testcase {height:50%;}

CSS 2.1 does not define how the height of table cells and table rows is calculated when their height is specified using percentage values. 
17.5.3 Table height algorithms


There is a spec clarification bug on this btw:

Does auto-height table row height depend on padding+border of cells or just height?

and their bug _15461_ is also somewhat related.

Such bug _15462_ is more a confirmation that what we are all thinking is correct than a real spec bug since there is no interoperability right now. 


(In reply to gadjo from comment #13)
> isn't it a dupe of bug 248239?

Yes it is. From examining
bug 248239 is a DUPLICATE of this bug.

Comment 18 User image Tal Aloni 2012-06-30 22:23:34 PDT
(In reply to Gérard Talbot from comment #17)
> bug 248239 is a DUPLICATE of this bug.
Correct, and now that 248239 is resolved, this could be marked resolved as well.

"strict pct testcase" is not a bug, the percentage height overrides the pixel height, and we render it just like Chrome / Safari / Opera.
Comment 19 User image j.j. 2012-07-02 12:52:24 PDT

*** This bug has been marked as a duplicate of bug 248239 ***

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