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.
Created attachment 46745 [details]
This *might* be what is causing bug 15248, but I haven't looked at it closely
enough, so maybe they are unrelated.
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
Created attachment 46916 [details]
testcase proving Karnaze's claim
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
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
Created attachment 46920 [details]
this is the reason why box-width is necessary for tables
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.
*** Bug 109780 has been marked as a duplicate of this bug. ***
*** Bug 113849 has been marked as a duplicate of this bug. ***
so.. what is the resolution for this bug then?
I think this should be fixed at least for strict mode.
*** Bug 111691 has been marked as a duplicate of this bug. ***
*** Bug 127027 has been marked as a duplicate of this bug. ***
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.
Created attachment 71140 [details]
same testcase in quirks mode
Created attachment 71141 [details] [diff] [review]
this patch does proper thing in strict mode and leaves behaviour the same in
also I removed trailing spaces across these files.
Created attachment 71172 [details] [diff] [review]
same patch without whitespace changes
Alexey, how did you test your patch?
run Mozilla with these modified files and looked at the above testcases in
strict and quirks mode.
Alexey, if only the last patch is to be considered, please mark the previous one
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
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.
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?
Why is this the right fix?
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?
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).
>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.
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).
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?
karnaze: That's good to hear! Excellent news.
Given what karnaze said, I don't see the point of this patch.
I think the point is that the box sizing in standard mode should be content-box
rather than border-box.
So to sumarise from http://bugzilla.mozilla.org/show_bug.cgi?id=96463#c27:
border-collapse: | separate | collapse |
--------------+ | |
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.
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 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.
mass reassign to default owner
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
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.
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
(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.
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?
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