1.70 KB, text/html
1.73 KB, text/html
452 bytes, text/html
372 bytes, text/html
1.57 KB, text/html
6.30 KB, patch
|Details | Diff | Splinter Review|
1.70 KB, text/html
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.
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
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)
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 71141 [details] [diff] [review] 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
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 obsolete.
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.
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?
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: 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?
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 | 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.
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: 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
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 my testcase.
(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?
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