Open
Bug 96463
Opened 23 years ago
Updated 2 years ago
border widths are subtracted from table's intrinsic width.
Categories
(Core :: Layout: Tables, defect, P5)
Tracking
()
NEW
Future
People
(Reporter: alexeyc2003, Unassigned)
References
Details
(Keywords: testcase, Whiteboard: [awd:tbl][p5])
Attachments
(7 files, 1 obsolete file)
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.
Reporter | ||
Comment 1•23 years ago
|
||
Reporter | ||
Updated•23 years ago
|
Keywords: testcase
Summary: border widths are subtracted from fixed table width. → border widths are subtracted from table's fixed width.
Reporter | ||
Comment 2•23 years ago
|
||
This *might* be what is causing bug 15248, but I haven't looked at it closely enough, so maybe they are unrelated.
Summary: border widths are subtracted from table's fixed width. → border widths are subtracted from table's intrinsic width.
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
Reporter | ||
Comment 5•23 years ago
|
||
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)
Reporter | ||
Comment 7•23 years ago
|
||
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•23 years ago
|
||
*** Bug 109780 has been marked as a duplicate of this bug. ***
Comment 9•23 years ago
|
||
*** Bug 113849 has been marked as a duplicate of this bug. ***
Comment 10•23 years ago
|
||
so.. what is the resolution for this bug then?
Reporter | ||
Comment 11•23 years ago
|
||
I think this should be fixed at least for strict mode.
Comment 13•23 years ago
|
||
*** Bug 111691 has been marked as a duplicate of this bug. ***
Comment 14•23 years ago
|
||
*** Bug 127027 has been marked as a duplicate of this bug. ***
Comment 15•23 years ago
|
||
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.
Reporter | ||
Comment 16•23 years ago
|
||
Reporter | ||
Comment 17•23 years ago
|
||
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
Reporter | ||
Updated•23 years ago
|
Reporter | ||
Comment 18•23 years ago
|
||
Comment 19•23 years ago
|
||
Alexey, how did you test your patch?
Reporter | ||
Comment 20•23 years ago
|
||
run Mozilla with these modified files and looked at the above testcases in strict and quirks mode.
Comment 21•23 years ago
|
||
Alexey, if only the last patch is to be considered, please mark the previous one obsolete.
Reporter | ||
Comment 22•23 years ago
|
||
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.
Reporter | ||
Updated•23 years ago
|
Attachment #71172 -
Attachment description: patch without whitespace changes → same patch without whitespace changes
Attachment #71172 -
Attachment is obsolete: true
Comment 23•23 years ago
|
||
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.
Reporter | ||
Comment 24•23 years ago
|
||
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•23 years ago
|
||
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
Reporter | ||
Comment 26•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
>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.
Reporter | ||
Comment 29•23 years ago
|
||
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).
Reporter | ||
Comment 30•23 years ago
|
||
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•23 years ago
|
||
karnaze: That's good to hear! Excellent news. Given what karnaze said, I don't see the point of this patch.
Comment 32•23 years ago
|
||
I think the point is that the box sizing in standard mode should be content-box rather than border-box.
Reporter | ||
Comment 33•23 years ago
|
||
bingo :o)
Comment 34•23 years ago
|
||
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•22 years ago
|
||
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?
Reporter | ||
Comment 36•22 years ago
|
||
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•21 years ago
|
||
mass reassign to default owner
Assignee: karnaze → table
Status: ASSIGNED → NEW
QA Contact: amar → madhur
Target Milestone: Future → ---
Updated•21 years ago
|
Priority: -- → P5
Target Milestone: --- → Future
Comment 38•19 years ago
|
||
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•19 years ago
|
||
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•19 years ago
|
||
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.
Reporter | ||
Comment 41•19 years ago
|
||
(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•17 years ago
|
||
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?
Updated•15 years ago
|
Assignee: layout.tables → nobody
QA Contact: madhur → layout.tables
Comment 43•11 years ago
|
||
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
Updated•2 years ago
|
Severity: normal → S3
Comment 44•2 years ago
|
||
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.
Flags: needinfo?(dholbert)
Comment 45•2 years ago
|
||
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.
Flags: needinfo?(dholbert)
You need to log in
before you can comment on or make changes to this bug.
Description
•