Closed Bug 217520 Opened 21 years ago Closed 21 years ago

text cell rendered wider than window when "word" longer than window width

Categories

(Core :: Layout: Tables, defect)

x86
Windows 98
defect
Not set
major

Tracking

()

RESOLVED DUPLICATE of bug 95067

People

(Reporter: andr55, Unassigned)

Details

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Win98; fr-FR; rv:1.3.1) Gecko/20030425
Build Identifier: Mozilla/5.0 (Windows; U; Win98; fr-FR; rv:1.3.1) Gecko/20030425

*** Note: this bug occurs in Mozilla mail as well as the navigator ***
+
When a very long word (often a visual form of a URL) is wider than its
containing cell, the cell is re-rendered wide enough to contain the very long
word.  This occurs even if the new width passes the current window width, which
makes the text virtually unreadable.  (One must then scroll right/left to read
each line.)
The tables/cells in which the cell is nested are similarly widened, which is
appropriate.
+
My suggestion is that:
A very long word should be split if it would cause its cell to pass the window
width. (Except possibly where an image causes a greater width.)
It would be a good idea to maintain a much narrower width (according to table
definitions) if feasable.
This would maybe require keeping track of text/word widths separately from other
minimum widths in the first pass? (See W3C recommendations.)
+
Please note that:
1) Both Netscape 4.75 and MSIE 5+ render pages with very long words correctly,
as I never had this problem before user Mozilla (1.01 fr and 1.3.1 fr), and I
often go to microsoft correction pages, which show very long URLs which cause
the problem
2) sample enclosed.  If necessary, make your window narrower to see the
difficulty reading text.

Reproducible: Always

Steps to Reproduce:
1. Make an html file with 2 identically defined tables, one after the other,
less that window width, with a border (for easy visualation of problem).
Ensure that each table contains at least 2 blocks of text to display over
serveral lines (separated by at least one <br>).
2. Put at very long word (string with no white space) in one table, wider than
the table definition.
3. Ensure that the other table contains no such very long word.

Actual Results:  
The table with the very long word scrolls out of the window, so one has to
scroll right/left to read each line.
The other table retains its original width, and the text is readable without
horizontal scrolling.

Expected Results:  
The very long word should have been split, to a length not exceeding the window
width.  However, often it is better to split it even shorter, in order to
maintain the defined layout of the page.
MSIE 5.x does the latter, as I believe does Netscape 4.75.
W3C recommendations recommend splitting long words to maintaint readability.

There is no crash, however this is a serious text readability problem.
As well, the pages affected are often bug fix pages, which require editing the
(often very large) html file for readability.
Dupe of bug 95067 "Very long words in table cells do not wrap (such as hyphens)"

*** This bug has been marked as a duplicate of 95067 ***
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
Reopening.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---

*** This bug has been marked as a duplicate of 218580 ***
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago21 years ago
Resolution: --- → DUPLICATE
I'm not sure if that duplicate is correct.  The attachment in this bug shows a 
problem with backslash (\, 005C, "reverse solidus"), which per UAX14 should be 
treated as a numeric prefix; not the same as slash (/, 002C, "solidus") which is 
bug 218580.  (See my comment there as well.)

UAX14 specifically acknowledges the slash's use as a path concatenator; 
backslash is not so acknowledged.  For what it's worth, Opera and IE both break 
the text in the attachment at the first hyphen, rather than at the backslash.
ok
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---

*** This bug has been marked as a duplicate of 95067 ***
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago21 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: