96463 - border widths are subtracted from table's intrinsic width.

Status: NEW

(Core :: Layout: Tables, defect, P5)

Description

[Alexey Chernyak]

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]

Attachment: testcase

Comment 2

[Alexey Chernyak]

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]

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]

Attachment: testcase proving Karnaze's claim

Comment 5

[Alexey Chernyak]

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
choice)

Comment 6

[Bernd]

Attachment: this is the reason why box-width is necessary for tables

Comment 7

[Alexey Chernyak]

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 [:bzbarsky]]

*** Bug 109780 has been marked as a duplicate of this bug. ***

Comment 9

[Boris Zbarsky [:bzbarsky]]

*** Bug 113849 has been marked as a duplicate of this bug. ***

Comment 10

[anthonyd]

so.. what is the resolution for this bug then?

Comment 11

[Alexey Chernyak]

I think this should be fixed at least for strict mode.

Comment 12

[karnaze (gone)]

-->future

Comment 13

[Boris Zbarsky [:bzbarsky]]

*** Bug 111691 has been marked as a duplicate of this bug. ***

Comment 14

[Bernd]

*** Bug 127027 has been marked as a duplicate of this bug. ***

Comment 15

[Robert Kieffer]

Attachment: 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]

Attachment: same testcase in quirks mode

Comment 17

[Alexey Chernyak]

Attachment: patch

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]

Attachment: same patch without whitespace changes

Comment 19

[Bernd]

Alexey, how did you test your patch?

Comment 20

[Alexey Chernyak]

run Mozilla with these modified files and looked at the above testcases in
strict and quirks mode.

Comment 21

[karnaze (gone)]

Alexey, if only the last patch is to be considered, please mark the previous one 
obsolete.

Comment 22

[Alexey Chernyak]

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]

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]

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 25

[Hixie (not reading bugmail)]

Why is this the right fix?
   http://www.w3.org/TR/REC-CSS2/tables.html#separated-borders
   http://www.w3.org/TR/REC-CSS2/tables.html#collapsing-borders

Comment 26

[Alexey Chernyak]

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)]

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]

>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]

Attachment: 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]

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:
http://www.w3.org/TR/REC-CSS2/tables.html#separated-borders

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)]

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)]

I think the point is that the box sizing in standard mode should be content-box 
rather than border-box.

Comment 33

[Alexey Chernyak]

bingo :o)

Comment 34

[Hixie (not reading bugmail)]

So to sumarise from http://bugzilla.mozilla.org/show_bug.cgi?id=96463#c27:

   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 [:bzbarsky]]

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]

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)]

mass reassign to default owner

Comment 38

[Gérard Talbot]

Testcase showing the problem marked as (*) in comment #34:
http://www.gtalbot.org/BrowserBugsSection/MozillaBugs/TableWidthBorderCollapse.html

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 -
100px

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 [:bzbarsky]]

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]

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]

(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]
[edit]
> 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]

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]

Hello,

"
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,
http://www.w3.org/TR/CSS21/tables.html#separated-borders

"
The width of the table wrapper box is the border-edge width of the table box inside it
"
CSS 2.1, § 17.4
http://www.w3.org/TR/CSS21/tables.html#model

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
http://lists.w3.org/Archives/Public/www-style/2010Sep/0186.html

Test:
http://test.csswg.org/suites/css2.1/nightly-unstable/html4/anonymous-table-box-width-001.htm

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

Comment 44

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 4 duplicates.
:dholbert, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 45

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.