Last Comment Bug 96463 - border widths are subtracted from table's intrinsic width.
: border widths are subtracted from table's intrinsic width.
Status: NEW
: testcase
Product: Core
Classification: Components
Component: Layout: Tables (show other bugs)
: Trunk
: x86 All
: P5 normal with 4 votes (vote)
: Future
Assigned To: Nobody; OK to take it and work on it
: 109780 111691 113849 127027 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2001-08-22 11:10 PDT by Alexey Chernyak
Modified: 2013-06-11 14:38 PDT (History)
8 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

testcase (1.70 KB, text/html)
2001-08-22 11:14 PDT, Alexey Chernyak
no flags Details
testcase proving Karnaze's claim (1.73 KB, text/html)
2001-08-23 12:05 PDT, Bernd
no flags Details
this is the reason why box-width is necessary for tables (452 bytes, text/html)
2001-08-23 12:43 PDT, Bernd
no flags Details
Table-Div width comparison (372 bytes, text/html)
2002-02-21 09:34 PST, Robert Kieffer
no flags Details
same testcase in quirks mode (1.57 KB, text/html)
2002-02-23 19:41 PST, Alexey Chernyak
no flags Details
patch (6.30 KB, patch)
2002-02-23 19:44 PST, Alexey Chernyak
no flags Details | Diff | Review
same patch without whitespace changes (1.27 KB, patch)
2002-02-24 01:21 PST, Alexey Chernyak
no flags Details | Diff | Review
strict collapsed testcase (1.70 KB, text/html)
2002-02-25 19:29 PST, Alexey Chernyak
no flags Details

Description Alexey Chernyak 2001-08-22 11:10:48 PDT
OS: Win2K
Build: 2001082203

If a table is given an explicit width, the thicker it's borders - the less wider
it is drawn.
There is an error somewhere in calculations, and borders are getting subtracted
from the width.
Comment 1 Alexey Chernyak 2001-08-22 11:14:35 PDT
Created attachment 46745 [details]
Comment 2 Alexey Chernyak 2001-08-22 12:06:48 PDT
This *might* be what is causing bug 15248, but I haven't looked at it closely
enough, so maybe they are unrelated.
Comment 3 Bernd 2001-08-23 10:24:32 PDT
AIM conversation with Chris:  If we want to fix this in standard mode, there is
a very simple fix - just put box-sizing:content-box in html.css and put
box-sizing:border-box in quirks.css (right now it may be in html.css, not sure).
If we do that, keep in mind that few web page will look right in standard mode,
which is why we never made the change. I've lost track of history, but I think
css 3 defines box-sizing. I am very afraid to make such a change. It definetely
cannot be changed in quirks mode.

bernd: I am scared to, so I was asking your opinion what is going on.
Chris: The good news is that we have thought of it and have a simple fix if need be.
bernd: I just tried the stuff with IE6 and they handle quirks and standard mode
for the div and the textarea different but not for the table
Comment 4 Bernd 2001-08-23 12:05:46 PDT
Created attachment 46916 [details]
testcase proving Karnaze's claim
Comment 5 Alexey Chernyak 2001-08-23 12:20:49 PDT
CSS3 has 2 different width properties: width and box-width.
At the moment when width is applied to table, it behaves as if it was box-width.
The goal of Mozilla is standard compliance, so yes, this should be fixed for
standard mode.
As for quirks mode, the way Mozilla renders it at the moment is nothing like any
other browser, thus pages already don't look right in it.
So for quirks it's basically either:
a) Fix it to display as CSS standard requires.
b) Make it display like other browsers (which is probably harder than the first
Comment 6 Bernd 2001-08-23 12:43:42 PDT
Created attachment 46920 [details]
this is the reason why box-width is necessary for tables
Comment 7 Alexey Chernyak 2001-11-11 18:18:41 PST
It appears that table layout has been fixed to behave like other browsers now.
Except that for some reason tables are now wider than they should be. I filed
bug 109680 on that.

Maybe we could leave it like this in quirks, and do proper width: in strict?

CCing Ian to have a look at this bug.
Comment 8 Boris Zbarsky [:bz] 2001-12-08 15:08:08 PST
*** Bug 109780 has been marked as a duplicate of this bug. ***
Comment 9 Boris Zbarsky [:bz] 2001-12-08 15:10:03 PST
*** Bug 113849 has been marked as a duplicate of this bug. ***
Comment 10 anthonyd 2001-12-13 18:14:16 PST
so.. what is the resolution for this bug then?
Comment 11 Alexey Chernyak 2001-12-13 19:24:11 PST
I think this should be fixed at least for strict mode.
Comment 12 karnaze (gone) 2001-12-13 20:00:37 PST
Comment 13 Boris Zbarsky [:bz] 2001-12-15 21:56:38 PST
*** Bug 111691 has been marked as a duplicate of this bug. ***
Comment 14 Bernd 2002-02-21 09:25:50 PST
*** Bug 127027 has been marked as a duplicate of this bug. ***
Comment 15 Robert Kieffer 2002-02-21 09:34:52 PST
Created attachment 70727 [details]
Table-Div width comparison

Attaching a test case that illustrates the problem in relation to DIV elements.
 Note that this discrepency is going to be really annoying for production folks
who need stuff to line up with 1-2 pixel accuracy.
Comment 16 Alexey Chernyak 2002-02-23 19:41:41 PST
Created attachment 71140 [details]
same testcase in quirks mode
Comment 17 Alexey Chernyak 2002-02-23 19:44:09 PST
Created attachment 71141 [details] [diff] [review]

this patch does proper thing in strict mode and leaves behaviour the same in
quirks mode.

also I removed trailing spaces across these files.
review please
Comment 18 Alexey Chernyak 2002-02-24 01:21:28 PST
Created attachment 71172 [details] [diff] [review]
same patch without whitespace changes
Comment 19 Bernd 2002-02-24 03:38:17 PST
Alexey, how did you test your patch?
Comment 20 Alexey Chernyak 2002-02-24 04:09:45 PST
run Mozilla with these modified files and looked at the above testcases in
strict and quirks mode.
Comment 21 karnaze (gone) 2002-02-24 09:25:27 PST
Alexey, if only the last patch is to be considered, please mark the previous one 
Comment 22 Alexey Chernyak 2002-02-24 17:20:08 PST
the patches are identical in functional changes
the first one also cleans up some unneeded trailing whitespaces in the files.
the second shows where the functional changes were made.
I'll mark the last patch obsolete, but you can still use it to see where changes
were made.
Comment 23 Bernd 2002-02-24 22:14:13 PST
Alexey, as you might have seen I am scared about the patch, the problem here is
not the patch but how to test it. My proposal is to turn on in the viewer the
standard mode rendering and to run the regression tests as only a minority of
the bug testcases is currently in standard mode. And then I would assume that
95% of all tests will fail, then one needs to verify visual every test that it
is not broken but only slightly changed.
Comment 24 Alexey Chernyak 2002-02-25 00:12:01 PST
I'm not sure what you are so worried about here?
The behaviour in quirks stays the same, so it won't break mainstream pages.
The behaviour in strict mode complies with the spec, which is what most of the
people who create strict mode pages expect. And it is goal of Mozilla to comply
with standard specs.
We already have profound differences between strict and quirks mode presentation
and this one is rather minor compared to others.
This bug affects a page only if all of these are true:

* Page is in strict mode
* Page uses CSS
* Page uses tables
* Tables use borders
* Tables use width: property

And still the level of distortion will be affected by border width.
It should have quite thick borders to be noticeably distorted.
As for pages that use tables for putting different pieces together with one
pixel precision, they usually don't use borders at all.
Once again, quirks pages are not affected.

Maybe I'm missing something that makes this change so scary?
Comment 26 Alexey Chernyak 2002-02-25 04:34:53 PST
Ok, Hixie, I see what you are saying: neither way is right and the border
shouldn't be outside or inside the table width, but should have half of it on
either side in the above testcases since they have border-collapse: set to
"collapse" (by default).
Ok, then it really gets more complicated.

However, don't you agree that it's still the right fix for "border-collapse:
separate"? Even though these testcases do not apply.
It fixes half the problem. Another half should be done in C++ I guess?
Comment 27 karnaze (gone) 2002-02-25 08:04:25 PST
I'm not sure what the problems is. With collapsed borders in strict mode, 
border-box excludes the outside half of the borders (I made it include the 
outside half of the borders in quirks mode since I think IE does it that way, 
and it seems more nataural despite what the spec says). With separate borders 
border-box includes all of the borders. content-box is pretty much the same in 
all cases - the area inside the borders excluding padding (except there is no 
padding with collapsed borders).
Comment 28 Bernd 2002-02-25 09:45:25 PST
>I'm not sure what you are so worried about here?
I am worried that I don't know how to run meaningfull regression tests for this
one. All table patches are supposed to pass the regression tests before they are
checked in. Our standard regression tests will be nearly blind to regressions
caused by this as the quirks mode will not change. My black soul can imagine
several bad scenarios, pages where images wrap or don't wrap vice versa, nested
tables that overwrite their parents border. While we are on it, with my old
build 2002010103 the first  caption and table in the first testcase are
perfectly aligned, while a current build shows a offset of a pixel. And these
regressions in table code are usually the result of not running the table
regression tests (and this makes me angry). Btw the separate border model is now
the default, see the w3c css2 errata.
Comment 29 Alexey Chernyak 2002-02-25 19:29:19 PST
Created attachment 71424 [details]
strict collapsed testcase

oh I thought collapsed was the default. I got confused by URLs Hixie provided.
ok I see now that collapsed is done correctly (except caption is misalligned).
Comment 30 Alexey Chernyak 2002-02-25 19:36:12 PST
So to answer Hixies question why is this the right fix for separated model:
Because with this fix it behaves exactly as defined in this URL:

The picture in there clearly shows that borders lie outside of table width.

Can you think of a better/simpler fix? Or why this is not the right fix?
Comment 31 Hixie (not reading bugmail) 2002-02-26 10:34:42 PST
karnaze: That's good to hear! Excellent news.

Given what karnaze said, I don't see the point of this patch.
Comment 32 karnaze (gone) 2002-02-26 12:15:10 PST
I think the point is that the box sizing in standard mode should be content-box 
rather than border-box.
Comment 33 Alexey Chernyak 2002-02-26 18:34:19 PST
bingo :o)
Comment 34 Hixie (not reading bugmail) 2002-02-27 01:11:51 PST
So to sumarise from

   border-collapse: |    separate     |     collapse     |
   box-sizing:   +--+-----------------+------------------+
   --------------+                    |                  |
    content      |       correct      |     invalid *    |
    border       |       invalid      |     correct      |

If I'm right, then that's not really acceptable :-)

The problem is the one marked (*) -- border-collapse: collapse should use
box-sizing: content (the default) to get the standards compliant behaviour.
Comment 35 Boris Zbarsky [:bz] 2003-02-03 21:39:34 PST
So... I'm still confused.  What exactly is this bug about?

The beginning sounds like complaints about the fact that we implement a
preliminary version of the CSS3 "box-sizing" property as -moz-box-sizing and use
it in our UA stylesheet....

Comment 34 confuses me.

So would someone explain to me what this bug is about?
Comment 36 Alexey Chernyak 2003-02-04 05:54:12 PST
Comment 32 summarises the reason I filed this bug for pretty well.

However this is not really about CSS3, but about our implementation of CSS2. Use
of CSS3 terms in comment 32 to describe behaviour just helps to formulate the
problem. And since we rely on preliminaty CSS3 properties to implement our CSS2
compliance, this is rather easy to fix.

However what is expected by CSS2 standard is opposite of all legacy
implementations. And if fixed, might result in slightly broken layouts.

That's why this should probably be fixed for Strict mode only. But I would
rather let Ian make such decisions.

Also <caption> behaviour in the testcase differs from <table> and should be
fixed as well. It should be the same width as the table.
Comment 37 karnaze (gone) 2003-03-31 11:28:45 PST
mass reassign to default owner
Comment 38 Gérard Talbot 2005-09-04 09:39:19 PDT
Testcase showing the problem marked as (*) in comment #34:

The way I understand this bug, the CSS 2.1 spec on border-collapse and comment #34:

Actual results: a table with collapsed borders in strict mode is as wide
(computed style width) as its intrinsec content minus (-) half of its borders:
its -moz-box-sizing value should is content-box. In that testcase, it is 400px -

Expected results: a table with collapsed borders in strict mode should be as
wide (computed style width) as its intrinsec content plus (+) half of its
borders: its -moz-box-sizing value should be border-box. In that testcase, it
should be 400px + 100px

Comment 39 Boris Zbarsky [:bz] 2005-09-05 15:52:45 PDT
What getComputedStyle returns in Mozilla has very little relation to CSS
computed style for various historical and compat reasons.  There are existing
bugs on this, for what it's worth.
Comment 40 Gérard Talbot 2005-09-05 16:36:42 PDT
I wanted to bring in this bugfile a testcase which I thought was more suitable,
easier to figure out bringing some light. Sorry Alexey, but attachment 71424 [details]
seems difficult to figure out.

> What getComputedStyle returns in Mozilla has very little relation to CSS
> computed style for various historical and compat reasons.

Then we also get fooled by DOM inspector as well.

  There are existing
> bugs on this, for what it's worth.

I haven't found those yet but I'll look.

Somehow, -moz-box-sizing can not be modified (from content-box to border-box) in
my testcase.
Comment 41 Alexey Chernyak 2005-09-06 00:48:17 PDT
(In reply to comment #40)
> I wanted to bring in this bugfile a testcase which I thought was more suitable,
> easier to figure out bringing some light. Sorry Alexey, but attachment 71424 [details]
> seems difficult to figure out.

Well it's simply a set of different types of boxes which all have the same
width, only their border widths differ.
Comment 42 Daniel.S 2007-06-03 12:55:23 PDT
Over time, there have been some changes on what Gérard Talbot's testcase reported.

While offsetWidth constantly reported 500, "width" correctly reported 500px before the reflow refactoring landed; Since the landing of the reflow refactoring it reports 807px.

Since that's a regression can it be fixed? Can offsetWidth or any other of the reported bugs also be fixed now?
Comment 43 Gérard Talbot 2013-06-11 14:38:12 PDT

in HTML and XHTML1, the width of the <table> element [in the border-collapse: separate model] is the distance from the left border edge to the right border edge. 
CSS 2.1, § 17.6.1,

The width of the table wrapper box is the border-edge width of the table box inside it
CSS 2.1, § 17.4

So, if width is set to 10cm, such width will include the table borders... which is like 'box-sizing: border-box' applying.

I have now examined attachment 46745 [details] with all of the tests at CSS2.1 test suite and I don't see a problem.

(In reply to Alexey Chernyak from comment #36)

> <caption> behaviour in the testcase differs from <table> and should be
> fixed as well. It should be the same width as the table.

Anonymous table box is as wide as max(table-width, table-caption-min-intrinsic-width)
[CSS21] table-caption width


Caption box width should be -> bug 674520 or -> bug 349144

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