Closed
Bug 295315
Opened 19 years ago
Closed 12 years ago
table-cell height calculation uses border-box sizing; should use content-box
Categories
(Core :: Layout: Tables, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 248239
People
(Reporter: jon, Assigned: bernd_mozilla)
References
(Blocks 1 open bug, )
Details
(Keywords: testcase)
Attachments
(5 files)
458 bytes,
text/html
|
Details | |
293 bytes,
text/html
|
Details | |
3.08 KB,
patch
|
bzbarsky
:
review-
bzbarsky
:
superreview-
|
Details | Diff | Splinter Review |
645 bytes,
text/html
|
Details | |
50.65 KB,
image/png
|
Details |
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 different. 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).
Reporter | ||
Comment 1•19 years ago
|
||
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).
yeah it seems that the height is applied including the padding
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.
Reporter | ||
Comment 6•19 years ago
|
||
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 on attachment 185354 [details] [diff] [review] patch 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 expected.
Attachment #185354 -
Flags: superreview?(bzbarsky)
Attachment #185354 -
Flags: review?(bzbarsky)
![]() |
||
Comment 9•18 years ago
|
||
Comment on attachment 185354 [details] [diff] [review] patch >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.top + borderPadding.bottom); No, this is wrong -- it's mixing percent and twips.
Attachment #185354 -
Flags: superreview?(bzbarsky)
Attachment #185354 -
Flags: superreview-
Attachment #185354 -
Flags: review?(bzbarsky)
Attachment #185354 -
Flags: review-
Assignee | ||
Comment 10•16 years ago
|
||
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•16 years ago
|
||
To be honest, I think David would be better-qualified to review this; he's been doing a lot more table layout stuff recently.
Updated•13 years ago
|
Summary: Box model not respected for td height? → table-cell height calculation uses border-box sizing; should use content-box
Updated•13 years ago
|
Blocks: css2.1-tests
Comment 13•13 years ago
|
||
isn't it a dupe of bug 248239?
Assignee | ||
Comment 15•12 years ago
|
||
Assignee | ||
Comment 16•12 years ago
|
||
Comment 17•12 years ago
|
||
(In reply to Bernd from comment #15) > Created attachment 556233 [details] > strict pct testcase td.target {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 http://www.w3.org/TR/CSS21/tables.html#height-layout ------------ There is a spec clarification bug on this btw: Does auto-height table row height depend on padding+border of cells or just height? https://www.w3.org/Bugs/Public/show_bug.cgi?id=15462 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 https://bug248239.bugzilla.mozilla.org/attachment.cgi?id=152910 bug 248239 is a DUPLICATE of this bug. Gérard
Comment 18•12 years ago
|
||
(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. p.s. "strict pct testcase" is not a bug, the percentage height overrides the pixel height, and we render it just like Chrome / Safari / Opera.
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•