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)

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

Tracking

()

Status:
RESOLVED DUPLICATE of bug 14984
Milestone:
mozilla1.1alpha

People

(Reporter: jesup, Assigned: attinasi)

References

(
URL
)

Details

(Keywords: access, testcase)

Attachments

(1 file)

reduced test case
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.
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
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 → ---
Target Milestone: --- → mozilla1.1
Getting a reduced test case -- but, basically it is just really bad html.
Target Milestone: mozilla1.1 → ---
Target Milestone: --- → mozilla1.1
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.
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.
Attached file reduced test case — 
reduced test case with overlapping nested tables
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.
Keywords: access, mozilla1.0, testcase
OS: Windows 2000 → All
Hardware: PC → All

*** 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.

Attachment

General

Creator:
Created:
Updated:
Size: