Closed Bug 254750 Opened 20 years ago Closed 17 years ago

Table with position: absolute and align="center" incorrectly creates horizontal scrollbar

Categories

(Core :: Layout: Tables, defect)

Product:
Core
Component:
Layout: Tables
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: jmccabe, Unassigned)

References

Details

(Keywords: testcase)

Attachments

(2 files)

Screen shot showing test case in Mozilla window
17.01 KB, image/png
Details
testcase
169 bytes, text/html
Details 
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040803
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040803

When a table is created using the position: absolute; top: 100px style and the
align="center" option a horizontal scrolblar is created with a mostly full thumb
(approx. 1/4" left on the right of the bar).

Test case is:

<html>
  <body>
    <table style="position: absolute; top: 100px" align="center">
	<tr>
	  <td>
	    <hr>
	    foobar
	  </td>
	</tr>
    </table>
  </body>
</html>

The "100px" can be replaced with any value. It has no effect on the scrollbar.

Reproducible: Always
Steps to Reproduce:
*** Bug 254751 has been marked as a duplicate of this bug. ***
Just a screen shot showing the test case in a Mozilla window. Note the
horizontal scroll bar along the bottom of the window.
Note that IE does not center the table in the testcase.
Neither does IE 5 on Mac OS X, Safari, or Konqueror.
Note that the problem can be reproduced after changing the test case a little to
get around the numerous browsers that seem compelled to not center the table:

     <table style="margin-left: auto; margin-right: auto; position: absolute;
top: 100px">

This will still produce a spurious horizontal scroll bar regardless of the
actual size of the Mozilla window.
And removal of 

position: absolute;

makes the scrollbar go away.
Also reproduced with Mozilla on MacOS X. Changing hardware and OS to All.
OS: Linux → All
Hardware: PC → All
Whiteboard: DUPEME
Attached file testcase — 
minimal testcase (based on reporter's, minus <hr> and top:100px).
Keywords: testcase
Confirming. Couldn't find a duplicate, despite extensive search.

This is NOT a duplicate of bug 252771 (which is fixed on the trunk; this one isn't).
Also apparently NOT a duplicate of bug 139155 (which requires a <br>).

Also note that either of "margin-left:auto" and "margin-right:auto" in the
testcase can be removed (causing the text to be left- or right-justified, not
centered), and the scrollbar will still be there.
Status: UNCONFIRMED → NEW
Component: Layout → Layout: Tables
Ever confirmed: true
QA Contact: core.layout → core.layout.tables
As far as I can see, the bug is no longer present. The table is taken out of normal flow and its top and left positions are auto. Margin-left and margin-right are computed as 0px (as reported by DOM inspector) in Seamonkey 1.5a rv:1.9a3 build 2007021310 under XP Pro SP2.

CSS 2.1, Section 10.3
10.3 Calculating widths and margins
"The values of an element's 'margin-left', 'margin-right' properties as used for layout depend on the type of box generated and on each other."
http://www.w3.org/TR/2006/WD-CSS21-20061106/visudet.html#Computing_widths_and_margins

Section 10.3.7
Absolutely positioned, non-replaced elements

"If all three of 'left', 'width', and 'right' are 'auto': First set any 'auto' values for 'margin-left' and 'margin-right' to 0."
http://www.w3.org/TR/2006/WD-CSS21-20061106/visudet.html#abs-non-replaced-width
which is the case here, in attachment 161492 [details]

Am I wrong? Did I miss something?

WORKSFORME
Yeah, this got fixed by the reflow branch landing.
Status: NEW → RESOLVED
Closed: 17 years ago
Depends on: reflow-refactor
Resolution: --- → FIXED
Whiteboard: DUPEME
Flags: in-testsuite?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: