Closed
Bug 118318
Opened 23 years ago
Closed 21 years ago
Text overwrite in a table - one table on top of another
Categories
(Core :: Layout, defect)
Core
Layout
Tracking
()
mozilla1.1alpha
People
(Reporter: jesup, Assigned: attinasi)
References
()
Details
(Keywords: access, testcase)
Attachments
(1 file)
|
572 bytes,
text/html
|
Details |
Mozilla 2002010103 WinXP
The page shows a text overwrite (and other problems) where the footer-table for
the bottom of the page ends up on top of the header for an article in the middle.
The footer is a separate table after the main one, not enclosed in anything.
One note: the HTML for the page has some evil in it:
<html><head>...</head><form>...<body> in the _middle_ of the page.
|
||
Comment 1•23 years ago
|
||
the above URL
http://www.hardwareoc.com/optical.php
is not valid, marking as invalid. If you can point to a valid URL, please reopen
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
|
Reporter | |
Comment 2•23 years ago
|
||
Reopening. The site in question seems to have a problem showing _any_ page
today; hopefully they'll fix it soon. (looks like a mysql error)
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
|
||
Updated•23 years ago
|
Target Milestone: --- → mozilla1.1
|
|
||
Comment 3•23 years ago
|
||
Getting a reduced test case -- but, basically it is just really bad html.
Target Milestone: mozilla1.1 → ---
|
|
||
Updated•23 years ago
|
Target Milestone: --- → mozilla1.1
|
|
Reporter | |
Comment 4•23 years ago
|
||
True, it's weird HTML - but there's weird HTML all over the web. At the minimum
we shouldn't barf and overwrite on it. With (true) oddball HTML perhaps we
won't display it as others do, but we should do something reasonable. For
example, <html>, <head> and <body> in the middle of a page should probably be
simply ignored.
Overwriting should only occur if we were told (as best we can determine) to do
so. I don't think the case mentioned is a good reason. It may be that that
isn't the root cause of of the overwrite; I may play with it more tomorrow.
|
|
||
Comment 5•23 years ago
|
||
I have the content reduced down to the minimum, the overwrite is based on the
width assignment for both nested tables and the align right for the first nested
table. Removing any one of those values causes the content of the second nested
table to fall to the next line. Both tables have been instructed to consume most
of the cell space (97% and 100%), which would account for the overwrite, in
addition the first nested table has been instructed to be aligned right, which
adds confusion to the placement.
It still seems like this should be invalid.
|
|
||
Comment 6•23 years ago
|
||
reduced test case with overlapping nested tables
|
|
Reporter | |
Comment 7•23 years ago
|
||
I think that's a bug, albeit one shared by most browsers. If the main-flow
table can't fit to the left of the right-aligned table, then it should be below
it; or if you prefer, the main content can be flowed to the left of the
right-aligned content, and if that causes the right-aligned content to be pushed
out, so be it.
Now, your example (as coded) causes overwrites in all browsers I tested:
IE5.0, ns4.75, and a spyglass-based browser (which tried to make the main flow
as narrow as possible to sneak it to the left of the right-aligned table, but
still failed and overwrote).
The algorithm we should use (more-or-less) is:
1. Find the min width of the main flow.
2. Reserve that much space to be between the left-aligned (if any) and
right-aligned (if any) elements.
3. If there's not enough space, you're done, and you may be wider than the
requested size. Set the left-most edge of the right-aligned item to be lmargin
+ width-of-left-aligned + min width of main flow, and min width of the cell/etc
to be the above plus width-of-right-aligned plus rmargin. (More or less).
4. If there's extra space, allocate between the left, right, and main flows
proportionally to the amount of space they'd like to use (difference between min
and max flow widths).
My algorithm is pretty irrelevant here other than the issue that side-aligned
tables & objects (images) should not reduce the space for the main flow below
the point where the main flow fits between them. Here, the right-aligned table
reduced the space for the main flow to almost nothing but still insisted on
putting it there; thus an overwrite.
However, for the test case you created, I don't see that this bug is a _major_
problem since all browsers fail on it. However, do all browsers fail on the
original page? (Sorry, it went away again - it showed up again yesterday, it's
gone now. I hear it should be back up on a new server 'shortly'.) However:
Solving this problem is somewhat important for accessibility reasons. Let's
say someone has a page with a large width=90% align=right table and some text
going past it, and that happens to work on normal systems because the longest
word in the main flow fits in the 10% in the normal font on a 1Kx768 display.
Now think of the case of a visually impaired viewer who uses a
larger-than-normal font. It may not fit in 10%, and will overwrite. Even
worse, what if that person uses 800x600 or 640x480 in order to (effectively)
magnify the screen (larger pixels)? Now it may not fit even in the default font.
This is also of direct interest to me since I need to configure browsers to use
small resolutions (648x500) and larger than normal fonts to be used by hundreds
of thousands of people.
|
||
Comment 8•21 years ago
|
||
*** This bug has been marked as a duplicate of 14984 ***
Status: REOPENED → RESOLVED
Closed: 23 years ago → 21 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•