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

RESOLVED DUPLICATE of bug 95067

Status

()

defect
--
major
RESOLVED DUPLICATE of bug 95067
16 years ago
16 years ago

People

(Reporter: andr55, Unassigned)

Tracking

Trunk
x86
Windows 98
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Reporter

Description

16 years ago
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.

Comment 2

16 years ago
Dupe of bug 95067 "Very long words in table cells do not wrap (such as hyphens)"

Comment 3

16 years ago

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

*** This bug has been marked as a duplicate of 218580 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → DUPLICATE

Comment 6

16 years ago
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
Last Resolved: 16 years ago16 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.