tables overlapping due to align: right

RESOLVED DUPLICATE of bug 14984

Status

()

Core
Layout: Floats
P3
normal
RESOLVED DUPLICATE of bug 14984
17 years ago
15 years ago

People

(Reporter: [not reading bugmail], Unassigned)

Tracking

({helpwanted, qawanted, testcase})

Trunk
Future
x86
Windows 2000
helpwanted, qawanted, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [awd:tbl][p:3])

Attachments

(2 attachments)

(Reporter)

Description

17 years ago
from:n.p.m.general

Why does the html below render the alignment of these three sets of tables
differently?  More importantly, though, is that it seems to me that _none_ of
them would be what a designer would want to happen (which would be having
'table two' take up all the space that table one hasn't...on the same
line...all within the browser window).  

Mark, Chris, 
    testcase here in table layout.. 

-dennis

possibly blocking 104012 and 102800? or other layout issues?
(Reporter)

Comment 1

17 years ago
Created attachment 54031 [details]
testcase 1
(Reporter)

Comment 2

17 years ago
Am I missing an obvious way to get the desired layout?   Regardless, at least
one of these layouts below seems like a bug, would y'all agree?


dan.

(Reporter)

Comment 3

17 years ago
anyway if you diagree if this is a valid bug or not, please let me know.. on
first glance this looks to be buggy.. I've done some reading on alignment/table
stuff not sure exactly if the output is correct.  

-Dennis
Keywords: helpwanted, qawanted, testcase

Comment 4

17 years ago
There are 3 cases in this bug.. but I think only the first case is buggy.
In the other two cases NS6.2 is rendering correct..
(Reporter)

Comment 5

17 years ago
thanks.
Yeah, first case is buggy. Confirming.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: tables are not rendered the same: using different syntax. → tables overlapping due to align: right

Updated

17 years ago
Whiteboard: [awd:tbl][p:3]

Updated

16 years ago
Target Milestone: --- → mozilla1.2
(Reporter)

Comment 7

16 years ago
just updating:  haven't seen anything fix the first table, nor regress the
botton two.  Still the same in a latest nightly. 2002-3-17-08.

Comment 8

16 years ago
Probably a block floater problem. Reassigning to alexsavulov. If someone can 
produce a url, we can raise the priority.
Assignee: karnaze → alexsavulov
Component: HTMLTables → Layout
Priority: -- → P3
Target Milestone: mozilla1.2 → Future

Comment 9

16 years ago
***********************

reference to bug 122200

***********************

I know this problem. IE does not deal properly with this too. I did a patch for
the align=left problem but I didn't wanted to repair the align=right problem
because this would complicate the code a lot. As long as there are no real world
pages that use this (and i doubt that since IE does not work too), we won't
uselesly complicate the nsBlockReflowState code. Correct me if I'm wrong.  

->Layout:Floats
Assignee: alexsavulov → float
Component: Layout → Layout: Floats
QA Contact: amar → ian

Comment 11

15 years ago
I think the only reason that there are no real world examples of this is
precisely because of the bugs in both cases.  I'd like to add another example of
the bug that is present in the attachment above, but not visible due to all of
the BR elements he uses.

When you build a table with it's width set to 100%, and it's alignment set to
100%, following elements do not respect the table space, and render directly on
top of it.  IE is broke in the same way.

-doug@metrixsystems.com

Comment 12

15 years ago
Created attachment 125889 [details]
Test case two...

This is the same bug, I believe, but a clearer test case...

Comment 13

15 years ago
In the above comment, I meant width of 100%, and alignment set to right.  That's
what the new attachment shows...
-doug@metrixsystems.com
dup

*** This bug has been marked as a duplicate of 14984 ***
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.