Persona is no longer an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 155955 - [BC] outer half of collapsed table border bleeds out of table box (border-collapse)
: [BC] outer half of collapsed table border bleeds out of table box (border-col...
: css2, testcase
Product: Core
Classification: Components
Component: Layout: Tables (show other bugs)
: Trunk
: All All
: -- normal with 11 votes (vote)
: ---
Assigned To: Bernd
: 170281 210175 224492 255029 277117 280207 282224 287011 291104 291147 293870 319350 322236 333643 346533 347130 369730 390617 435019 448077 461486 461699 470977 482226 538658 (view as bug list)
Depends on: 484258 484260
Blocks: 170281 212036 254035 410621
  Show dependency treegraph
Reported: 2002-07-05 13:49 PDT by Tarmo Järvalt
Modified: 2014-04-25 15:17 PDT (History)
43 users (show)
roc: wanted1.9.1+
bernd_mozilla: in‑testsuite+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

testcase, HTML CSS (1.32 KB, text/html)
2002-07-05 13:53 PDT, Tarmo Järvalt
no flags Details
expected rendering (574 bytes, image/png)
2002-07-05 14:06 PDT, Tarmo Järvalt
no flags Details
Testcase #2 (596 bytes, text/html)
2002-07-25 01:29 PDT, Mats Palmgren (:mats)
no flags Details
Testcase #3 (582 bytes, text/html)
2002-08-11 18:22 PDT, Mats Palmgren (:mats)
no flags Details
patch (964 bytes, patch)
2003-02-26 10:10 PST, Bernd
no flags Details | Diff | Splinter Review
patch (9.41 KB, patch)
2008-11-29 14:21 PST, Bernd
no flags Details | Diff | Splinter Review
patch (12.63 KB, patch)
2009-01-02 09:36 PST, Bernd
fantasai.bugs: review+
Details | Diff | Splinter Review
revised patch (26.52 KB, patch)
2009-01-17 06:36 PST, Bernd
roc: superreview+
Details | Diff | Splinter Review
test case (1.06 KB, text/html)
2009-04-06 17:36 PDT, Johannes Langlotz
no flags Details

Description Tarmo Järvalt 2002-07-05 13:49:07 PDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1a+) Gecko/20020629
BuildID:    2002062904

Using style="float: left" on tag before table tag causes table (with
style="margin: 0px 0px 0px 1px" set) to have visible style of "margin-top: -1px,
margin-left: -1px" but DOM Inspector says that it has 0px margin all the way.

In second row containing div and table with 10px borders it is seen that the
elements collide.

This bug only appreas when running in strict mode, removing doctype and
therefore going to quirks mode displays it correctly.

Reproducible: Always

Steps to Reproduce:
1. Open testcase
2. See wether boxes are aligned and with 1px spacing

Actual Results:  table box is not correctly aligned

Expected Results:  table box is at same height and has 1px margin either side

M$ IE 6.0 displays the testcase as expected.
Comment 1 Tarmo Järvalt 2002-07-05 13:53:57 PDT
Created attachment 90342 [details]
testcase, HTML CSS
Comment 2 Tarmo Järvalt 2002-07-05 14:06:04 PDT
Created attachment 90343 [details]
expected rendering
Comment 3 David Baron :dbaron: ⌚️UTC-7 (busy until November 7) 2002-07-06 16:13:51 PDT
Given 'border-collapse: collapse' this seems like the correct result.  See CSS2
Comment 4 Mats Palmgren (:mats) 2002-07-25 01:29:34 PDT
Created attachment 92697 [details]
Testcase #2
Comment 5 Mats Palmgren (:mats) 2002-07-25 01:38:58 PDT
It seems the origin of a collapsed border table is set where the upper-left
grid lines meet. See:

I don't know if this is a bug or not.

--> HTMLTables.
Comment 6 Tarmo Järvalt 2002-07-25 03:40:21 PDT
What would be the workaround to display floated table in strict mode Mozilla as
it is rendered with MSIE?

And how is it useful being rendered as it is currently by strict mode Mozilla?
Comment 7 Mats Palmgren (:mats) 2002-08-11 18:21:52 PDT
After reading the spec some more, I agree with Tarmo - this is a bug.
It breaks the box model, CSS2 8.1 and 9.4.1 for example.
Comment 8 Mats Palmgren (:mats) 2002-08-11 18:22:47 PDT
Created attachment 94882 [details]
Testcase #3
Comment 9 David Baron :dbaron: ⌚️UTC-7 (busy until November 7) 2002-08-11 18:23:50 PDT
Note the sentence:  "Note that in this model, the width of the table includes
half the table border."  I still don't think this is a bug.
Comment 10 Mats Palmgren (:mats) 2002-08-18 17:56:25 PDT
Yes, I saw that sentence, it is also indicated in the figure directly above.
What I don't understand is why this has anything to do with the positioning of
the table. Assuming 'margin:0', then the "outer edge" is the "border edge" (8.1).
I don't see anything in 17.6.2 that indicates an exception to this rule.
Comment 11 David Baron :dbaron: ⌚️UTC-7 (busy until November 7) 2002-08-18 18:01:26 PDT
Hmm.  I always interpreted that as meaning both outer width and inner width, but
I guess it could mean just inner width.
Comment 12 fantasai 2002-11-30 00:18:33 PST
There's also this:
"Note only half of the two exterior borders are counted in the table width; the
other half of these two borders lies in the margin area."

If the margin has zero width, how can 5px of border lie in it? The margin would
have to be at least 5px wide for a 10px collapsed border. The question is,
should the space be added to the margin or should the space collapse with it?
Comment 13 Bernd 2002-11-30 04:59:16 PST
fantasai: thats a really nice sentence, how did I overlook this treasure. We can
easily incorporate this in nsTableOuterFrame.cpp. This would yield that the
table does not leak outside the outer table frame. I like this. Probably adding
the space is the clearer way to go.
Comment 14 fantasai 2002-11-30 12:41:12 PST
Hmmm.. I think that even if we add the space for a border that takes effect
along the whole edge (table, row group, col group, col, row), we should collapse
any extra due to individual cells. Suppose I had
    <tr><td id="c">c</td><td>d</td></tr>

table {
  margin: auto;
  border: 2px solid;
  border-collapse: collapse;
  width: 80%;
#c {
  border: 10px solid;

We want the table to appear centered, but if the extra 4px gets added to the
left margin, it will be off-center.
Comment 15 Bernd 2002-12-01 00:29:15 PST
I would rather not collapse them for cell but let them leak out of the outer
table frame.
Comment 16 fantasai 2002-12-01 11:50:16 PST
If you let the borders leak out, they'll overpaint adjacent content. Like in my
testcases for 4510: the top border overwrites part of the caption. And, it says
"exterior borders", not "exterior row, col, table, colgroup, or row group
borders". :) So, you should find the greatest effective border width on that
side and the greatest continuous (row/col/row group/col group/table) border
width. Add the greatest continuous border width and make sure that the resulting
margin is at least as big as the greatest effective border width.

... Suppose that the table border is 10px, but all the cells along the top have
border: hidden. Would it make sense to leave room for a border that doesn't exist?
Comment 17 Hixie (not reading bugmail) 2003-02-07 05:18:46 PST
The current model, as I understand it, lets you lay out the first row of a fixed
layout table without knowing the border widths of subsequent rows' first and
last cells. If you change the model to have the table width go up to the widest
border, then your table width can change upon receiving the data for subsequent

I don't pretend to understand this stuff though. Did I mention I hate tables?
Comment 18 Bernd 2003-02-07 06:05:45 PST
If you would not hate tables, the css2.1 spec would be implementable and may be
self consistent and I would have a person to ask :-). At least the question has
been posted to w3c-style: 

Did I mention that there was no reply, as usual with table related questions?
Comment 19 fantasai 2003-02-15 10:47:48 PST
Ian -
In border-collapse mode, table width is measured from the center of the border,
not from the edge.

The extra width from the border would become part of the margin, so fixed layout
would still work. (The margin only affects the table width if the width is auto,
and if the width is auto we use auto layout.)
Comment 20 Hixie (not reading bugmail) 2003-02-26 08:19:40 PST
fantasai: yes, but haven't you requested that that be changed?
Comment 21 Bernd 2003-02-26 10:10:24 PST
Created attachment 115653 [details] [diff] [review]
Comment 22 fantasai 2003-02-26 17:03:07 PST
> fantasai: yes, but haven't you requested that that be changed?

No, Bernd did. I don't agree with him on that. :) I still think the extra width
should be part of the margin--and if you consider table backgrounds (*grin*)
you'll see that it only makes sense this way. I should've replied by now, though.
Comment 23 karnaze (gone) 2003-03-31 11:25:30 PST
mass reassign to default owner
Comment 24 Mats Palmgren (:mats) 2003-06-20 07:52:58 PDT
See also bug 170281 (testcase: attachment 100223 [details])
Comment 25 Mats Palmgren (:mats) 2003-11-02 17:08:37 PST
*** Bug 224492 has been marked as a duplicate of this bug. ***
Comment 26 fantasai 2004-02-19 04:35:37 PST
*** Bug 210175 has been marked as a duplicate of this bug. ***
Comment 27 fantasai 2004-04-11 12:20:03 PDT

At the 2004 Plenary, the CSS WG decided to leave this detail of border-collapse
behavior undefined. I recommend we follow Opera's example and implement what
I've decribed in the www-style proposal above.
Comment 28 fantasai 2004-04-12 21:23:59 PDT
*** Bug 170281 has been marked as a duplicate of this bug. ***
Comment 29 Boris Zbarsky [:bz] (still a bit busy) 2004-08-10 09:29:24 PDT
*** Bug 255029 has been marked as a duplicate of this bug. ***
Comment 30 Mats Palmgren (:mats) 2005-01-25 18:21:25 PST
*** Bug 277117 has been marked as a duplicate of this bug. ***
Comment 31 Mats Palmgren (:mats) 2005-01-28 10:35:05 PST
*** Bug 280207 has been marked as a duplicate of this bug. ***
Comment 32 Mats Palmgren (:mats) 2005-01-28 11:01:54 PST
(In reply to comment #27)
"The solution ... and add it to the table margin."

Instead of adding it one could perhaps inflate it instead?
(That is, the margin does not change when the border fits inside and is only
made wide enough, but not more, when the border does not fit.)
Comment 33 Bernd 2005-02-14 10:02:39 PST
*** Bug 282224 has been marked as a duplicate of this bug. ***
Comment 34 Benjamin Streeck 2005-02-14 10:51:07 PST
As long as this bugs lacks a real solution due to a lack of concesus on what to
do here (or where is the problem now?), shouldn't an intermediary solution fix
the different calculations for left/right and top/bottom positioning as
demonstrated by (from dupe -- sorry!)? Then at least
the behavior is calculatable, and the discussion could go on forever, as much as
I care.

FYI: Opera does it just like the attachment proposes, and not not as described
by comment #27. Version 7.54 and 8.0b1.
Comment 35 Bernd 2005-02-14 11:52:16 PST
The problem is that this bug has lower priority, than
Feel free to fix it, ask me if you need help.
Comment 36 Julien "_FrnchFrgg_" RIVAUD 2005-03-17 12:20:14 PST
Should'nt the title of the bug be changed to reflect its evolution ?

I agree that the current way, people not understanding (or not reading at all)
the W3C specs and filing a bug can see there is already one.
Yet, the fact that the border bleeds outside of table is no longer considered
the bug to correct, but rather "outer half of collapsed table border should
inflate/extend/... the table margin to prevent overlap" or something like that.

Doing so, the bug may become invisible to people wanting the border to be _in_
the box, but volontary programmers could discover a bug they _do want_ to fix
because it better fits their view of the world.


P.S.: Is it complicated to a newbie in Mozilla's code (but not in coding) to
take over this bug and try to write a patch ? Given a hint as to the place where
collapsed border's code hides, I could try (and maybe loose, you've been warned ;)
Comment 37 Bernd 2005-03-18 09:44:37 PST
>Is it complicated to a newbie in Mozilla's code (but not in coding) to
take over this bug and try to write a patch ?

Hmm it would be not fair to say its easy for a newbie however its feasible its
not rocket science.

The table margin handling is done at

But the first step is to get a working build (
Comment 38 Julien "_FrnchFrgg_" RIVAUD 2005-03-18 10:46:24 PST
(In reply to comment #37)

Shouldn't it be in nsTableFrame ? Because it is its margin that matters, and I
would rather have a table border non leaking into it's caption frame, do I ?

Comment 39 Bernd 2005-03-18 21:28:43 PST
No, its the outer table frame that takes care of its child (the table itself and
the caption) margins.
Comment 40 Julien "_FrnchFrgg_" RIVAUD 2005-03-19 02:33:48 PST
What I meant is :
If there exists a function that returns margins of the (inner child) table, and
whose result is used by the outer container to a) calculate its caption position
& size, and b) exhibit some margins too (I'd say 3 unmodified margins of the
table, and one of the caption), I'd rather modify this one.

And I would have searched such a function in the inner table class, because it
seems to belong to it.

Is GetMarginPadding(...) such a function ? And in some other functions
OuterReflowChild(...), nearly identical code is used as in GetMarginPadding. The
main problem for me is that not knowing exaclty the way you reflow and when you
calculate margins, I have to guess, and I may gess wrong, or forgot somewhere...
I'll try to go on the dev forums to find help, unless some short explaination
can be given here without bloating the bug and taking to much time of the happy
few who know.

Comment 41 fantasai 2005-03-20 08:19:54 PST
Making the margin adjustments in nsTableOuterFrame.cpp would not give the
intended effect when there is a caption. The changes must be in nsTableFrame.cpp.

I just went looking through the minutes of the csswg meeting. It was suggested
that the collapsed border width figure in the calculation of the table's
computed border width.

I think I need to run a few tests on what Opera's doing before we decide how
exactly we're going to fix this bug.
Comment 42 Bernd 2005-03-21 11:30:24 PST
*** Bug 287011 has been marked as a duplicate of this bug. ***
Comment 43 Bernd 2005-04-20 10:47:26 PDT
*** Bug 291104 has been marked as a duplicate of this bug. ***
Comment 44 Bernd 2005-04-20 10:50:40 PDT
*** Bug 291147 has been marked as a duplicate of this bug. ***
Comment 45 Bernd 2005-05-12 09:37:32 PDT
*** Bug 293870 has been marked as a duplicate of this bug. ***
Comment 46 Hixie (not reading bugmail) 2005-11-07 14:00:23 PST
For the record, the spec changed several times on this. When fixing this bug, make sure to read the new text (section 17.6.2), in particular about how the first row is magical and never spills out, but that subsequent rows may spill out if they have wider borders:

# UAs must compute an initial left and right border width for the table by 
# examining the first and last cells in the first row of the table. The left 
# border width of the table is half of the first cell's collapsed left border, 
# and the right border width of the table is half of the last cell's collapsed 
# right border. If subsequent rows have larger collapsed left and right borders, 
# then any excess spills into the margin area of the table.
Comment 47 Frank Wein [:mcsmurf] 2006-07-31 04:00:31 PDT
*** Bug 346533 has been marked as a duplicate of this bug. ***
Comment 48 Mats Palmgren (:mats) 2006-08-03 09:17:23 PDT
*** Bug 347130 has been marked as a duplicate of this bug. ***
Comment 49 Mats Palmgren (:mats) 2007-02-09 11:28:49 PST
*** Bug 369730 has been marked as a duplicate of this bug. ***
Comment 50 David Baron :dbaron: ⌚️UTC-7 (busy until November 7) 2007-02-21 15:33:20 PST
*** Bug 319350 has been marked as a duplicate of this bug. ***
Comment 51 David Baron :dbaron: ⌚️UTC-7 (busy until November 7) 2007-02-23 17:56:33 PST
Note that when we implement what the spec says, I think we can do it in quirks mode too and remove our implementation of a similar idea (but somewhat different rules) in quirks mode.
Comment 52 Mats Palmgren (:mats) 2007-09-03 03:44:06 PDT
*** Bug 390617 has been marked as a duplicate of this bug. ***
Comment 53 Mats Palmgren (:mats) 2008-05-21 08:08:00 PDT
*** Bug 435019 has been marked as a duplicate of this bug. ***
Comment 54 Elmar Ludwig 2008-07-26 04:34:25 PDT
*** Bug 448077 has been marked as a duplicate of this bug. ***
Comment 55 Glen A. 2008-08-18 03:05:04 PDT
What is the reason for calculating the width and height of the table using half of the border width/height? Wouldn't it be more logical to draw the left/right and top/bottom borders of the table inside the grid lines? (

If you open the following page ( and use Firebug (or similar) to change the border-color of the divs to green (#0C0), you can see how ridiculous it looks at the moment with no table margins (compared to the 'border-collapse off' rendering).

I don't see the point/meaning of auto-adding margin just to accommodate the border. It doesn't make sense placing part of the border into the margin, IMHO. Aren't margins supposed to be empty, and used for spacing between elements?

I don't really know much about this subject, so please keep that in mind when reading the above.
Comment 56 Mats Palmgren (:mats) 2008-10-21 04:36:58 PDT
*** Bug 322236 has been marked as a duplicate of this bug. ***
Comment 57 Mats Palmgren (:mats) 2008-10-24 08:27:41 PDT
*** Bug 461486 has been marked as a duplicate of this bug. ***
Comment 58 Bernd 2008-10-25 10:07:14 PDT
fantasai: we have three functions at

in a new CSS 2.1 compliant world what would the tree functions return

 nsMargin GetOuterBCBorder() const;

the new table border width? as defined by the width on the first and last cell on the first row together with the top border and bottom border on the first cell in the first and last row?

 nsMargin GetIncludedOuterBCBorder() const;

the new table border width?

 nsMargin GetExcludedOuterBCBorder() const;

Comment 59 philippe (part-time) 2008-10-26 16:22:50 PDT
*** Bug 461699 has been marked as a duplicate of this bug. ***
Comment 60 negora 2008-10-26 18:52:25 PDT
"That is actually what the spec says."

>>> philippe: But that part of the specification only states how the collapsed borders must be rendered according to the internal table grid, not how the whole border must be aligned with the container box, Right?

In my opinion that text "only" means that if you apply a border of 4 px, 2 px of it will be put out of the grid line and 2 px will be put inside. That doesn't mean that the alignment of the table has to be referred to the mentioned grid line. There's no line which says something like that. Am I wrong?

Indeed, doing that would contradict the "sense" of the CSS borders, as they take a room and they "push" any surrounding element (except if you use rules to alter that, obviously). The present implementation converts the border into a weird mixture: The inner half behaves like a border, whereas the external half acts like an outline.
Comment 61 fantasai 2008-10-30 15:23:55 PDT
Based on the semantics of these functions,

  nsMargin GetOuterBCBorder() const;
would return everything that spills out, as I imagine it does today

  nsMargin GetIncludedOuterBCBorder() const;
would be:
  * on the left, 1/2 the collapsed left border width on the first
    cell in the first row
  * on the right, 1/2 the collapsed right border width on the last
    cell in the first row
  * on the top, 1/2 the widest collapsed top border segment on the
    first row
  * on the bottom, 1/2 the widest collapsed bottom border segment
    on the last row

  nsMargin GetExcludedOuterBCBorder() const;
would return GetOuterBCBorder() - GetIncludedOuterBCBorder()

GetIncludedOuterBCBorder() would be used for width/margin calculations and would be included in table background painting. GetExcludedOuterBCBorder() would be used only for calculating overflow.

Personally, I don't like these rules. I think
  - the table's own border should be used for GetIncludedOuterBCBorder()
  - that GetOuterBCBorder() should be calculated as 1/2 max collapsed
    border on all sides, falling to the 2.1 rules only for fixed tables
  - that GetExcludedOuterBCBorder() should collapse with the table's
but that's not what 2.1 says...
Comment 62 Bernd 2008-10-31 00:05:01 PDT
fantasai: thanks,

is there a reason why the left/right  and top/bottom borders are treated differently?

>but that's not what 2.1 says...
you should talk to the editors ;-)
Comment 63 fantasai 2008-10-31 10:28:50 PDT
The goal there was to avoid two passes over the table.
Comment 64 Jan David 2008-11-07 01:26:03 PST
My 3.0.3 Firefox browser was updated to 3.0.4 and the left border of my home page disappeared. It's a xhtml 1.0 strict validated page. It used to work perfectly in 3.0.3.

Here's my home page:
Comment 65 Ilya 2008-11-24 03:48:53 PST
Hi all. This bug really strains. Somebody knows when will correct?
Comment 66 Bernd 2008-11-29 14:21:18 PST
Created attachment 350600 [details] [diff] [review]

This does roughly what is required, it lacks testing.
Comment 67 Bernd 2008-11-29 14:46:15 PST
re comment 64 Jan this is a old bug it is certainly unrelated to what you see.
Comment 68 Bernd 2009-01-02 09:36:51 PST
Created attachment 355133 [details] [diff] [review]
Comment 69 fantasai 2009-01-16 00:21:47 PST
Comment on attachment 355133 [details] [diff] [review]

Please update the comments in nsTableFrame.h for the functions you are changing.

+  <tr><td style="border:solid 4px red; height:30px">cell 1</td></tr>

Use a color other than red, since the presence of red is supposed to indicate failure.

+  if (propData) {
+ += BC_BORDER_TOP_HALF_COORD(p2t, propData->mTopBorderWidth);

This should be =, not +=.

-  nsMargin offset(0,0,0,0);
+ nsMargin offset(0,0,0,0);

Stray whitespace deletion.

r=fantasai otherwise
Comment 70 Bernd 2009-01-17 06:36:09 PST
Created attachment 357485 [details] [diff] [review]
revised patch
Comment 71 Bryan 2009-02-08 20:33:56 PST
Should this be fixed in the following build?

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090208 Minefield/3.2a1pre (.NET CLR 3.5.30729) ID:20090208181212

The test case is still not proper if it's supposed to be.

Comment 72 Bernd 2009-02-08 22:26:48 PST
If you do not see this in a build from 2009-02-09 please reopen the bug, there are several reftests that run on tinderbox that rely on this changed behaviour.
Comment 73 Bryan 2009-02-09 03:27:41 PST
Still not fixed in: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090209 Minefield/3.2a1pre (.NET CLR 3.5.30729) ID:20090209020258

Comment 74 Martijn Wargers [:mwargers] (not working for Mozilla) 2009-02-09 16:04:54 PST
Bryan, what exactly is not fixed? You mean the first testcase in this bug?
Comment 75 Bryan 2009-02-09 16:12:03 PST

Yes, the first testcase.  Maybe I've misunderstood this bug.

Comment 76 Mats Palmgren (:mats) 2009-03-09 08:15:19 PDT
*** Bug 482226 has been marked as a duplicate of this bug. ***
Comment 77 Jim Jeffery not reading bug-mail 1/2/11 2009-03-09 09:35:34 PDT
Did this patch actually land somewhere ?  I don't see where/when/by whom it was checked into either trunk or branch.  Perhaps 'fixed' by another bug that was not referenced ?
Comment 78 Mats Palmgren (:mats) 2009-03-09 09:45:38 PDT
It's fixed on trunk AFAICT:
as of 2009-02-08 it seems:
Comment 79 Daniel.S 2009-04-05 06:48:59 PDT
*** Bug 470977 has been marked as a duplicate of this bug. ***
Comment 80 Johannes Langlotz 2009-04-06 17:36:42 PDT
Created attachment 371352 [details]
test case
Comment 81 Johannes Langlotz 2009-04-06 17:45:22 PDT
OK, seems to be fixed in 3.6a1pre! Will this patch also be applied to 3.5?
Comment 82 Ryan VanderMeulen [:RyanVM] 2009-04-06 17:47:26 PDT
Not likely.
Comment 83 Daniel.S 2009-04-11 02:25:34 PDT
*** Bug 333643 has been marked as a duplicate of this bug. ***
Comment 84 Ria Klaassen (not reading all bugmail) 2009-04-22 02:11:53 PDT
Has this bug fixed Bug 489279 ?
Comment 85 soandso 2009-09-18 20:41:46 PDT
Issue no longer shows up after install of 3.6a1! :)
Comment 86 Bernd 2010-01-09 08:56:31 PST
*** Bug 538658 has been marked as a duplicate of this bug. ***

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