Open Bug 1179741 Opened 9 years ago Updated 2 years ago

incorrect side margins (due to bad containing block) on orthogonal table

Categories

(Core :: Layout: Block and Inline, defect)

Product:
Core
Component:
Layout: Block and Inline
Type:
defect

Tracking

()

People

(Reporter: jfkthame, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: testcase)

Attachments

(2 files)

testcase, left margin on orthogonal <table> vs <div>
(deleted), text/html
Details
floated orthogonal table margins incorrect
(deleted), text/html
Details
See testcase. Click the radio buttons to switch the left-margin value between "0px", "100px", and "auto". The <div> (cyan) and the <table> (yellow) would be expected to behave the same at all these settings, but in fact the table disappears when left-margin is auto. The problem seems to arise from the use of an unconstrained containing block width (because it's the block-size of a vertical block) when setting up the side margins during nsHTMLReflowState initialization. Also note the unexpected horizontal scrollbar on the window. This is because of the unconstrained-width scrollable overflow area generated by the table, and is another aspect of the same bug, I believe.
Quick draft test: Table with 'margin-left: auto' and 'margin-right: auto' in orthogonal context http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/table-with-wm-vrl-002-draft.html Actual results in Firefox 42.0a1 buildID=20150705030216: green square is left aligned in <body> and not centered in <body> ---- Quick draft test: Table with percentage width in orthogonal context http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/table-with-wm-vrl-004-draft.html Actual results in Firefox 42.0a1 buildID=20150705030216: no red but horizontal scrollbar generated
Keywords: testcase
OS: Unspecified → All
Hardware: Unspecified → All
Version: unspecified → Trunk
Possibly related testcase: floated orthogonal tables have margins that don't match their computed styles. Have no idea what's happening here.
(In reply to fantasai from comment #2) > Created attachment 8957480 [details] > floated orthogonal table margins incorrect > > Possibly related testcase: floated orthogonal tables have margins that don't > match their computed styles. Have no idea what's happening here. You say margins between adjacent floated [vrl | vlr] tables should collapse. Then I must revisit bug 1185430 comment 2 because I believed the opposite.
In your attachment 8957480 [details], the margins between the 4 <div>s of the reference block should not collapse. Assuming a font-size of 16px, there should be 32px separating the 4 <div>s of the reference block. If margins between adjacent floated [vrl | vlr] tables should collapse, then the margins between the 4 <table>s should be 16px, not 32px. - - - - - - - - - > Have no idea what's happening here. I can explain the math followed by Firefox. In your attachment 8957480 [details], the margins between adjacent floated [vrl | vlr] tables are substracted by the total of table borders. Instead of being 16px (margins collapse, so: max(16px, 16px), they are 16px + 16px - (2 * 3px) = 26px.
> You say margins between adjacent floated [vrl | vlr] tables should collapse. I am not sure what you were saying or if you were saying the above; I now doubt this. I examined again tests in bug 1185430 and your attachment 8957480 [details] and I believe horizontal margins of floated (containing block is horizontal-tb) blocks should not collapse. The writing mode of the containing block is horizontal-tb; so those horizontal margins should not collapse. > floated orthogonal tables have margins that don't match their computed styles Firefox incorrectly substracts (or rather ignores or does not consider) the borders of adjacent floated blocks. This affects the gap we see in, for example, this test http://test.csswg.org/harness/test/css-writing-modes-3_dev/single/table-progression-vrl-002/ The thicker the borders (also if table cells have a padding), the more the horizontal gap is reduced: http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/adjacent-floated-vrl-tables-in-htb-cb.html Chrome 64: 100px + 100px separate both tables Firefox 52.6.0 ESR: 100px + 100px - 70px - 70px = 60px separate both tables.
I've run more tests with Firefox 60.0a1 buildID=20180309220137: http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/adjacent-floated-vrl-tables-in-htb-cb-002.html Expected: 200px; Actual in Firefox 60: 160px http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/adjacent-floated-vrl-tables-in-htb-cb-003.html Expected: 200px; Actual in Firefox 60: -40px The expected gap (200px; sum of horizontal margins separating the 2 <table>s) between squares is reduced by twice the width of border-right of first table.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: