I'm using 2002101804. On the page listed in the URL field, on freshmeat, I find that the paragraphs are too wide. It's pretty much unreadable. I notice that it's just wide enough to fit the entire "Copyright Notice": " Copyright notice: All reader-contributed material on freshmeat.net is the property and responsibility of its author; for reprint rights, please contact the author directly. " on one line. That's suspicious.

Simon, does it look any differently in other browsers?

Actually this is what's causing the window to stretch (not the copyright notice): (http://searchwindowsmanageability.techtarget.com/originalContent/0,289142,sid33_gci844851,00.html) Internet Explorer breaks on slashes, Chimera does not. I'm not sure if Mozilla does or not. Would someone like to test this in Mozilla?

Yep, looks like Mozilla doesn't break on slashes either. This bug should either be marked invalid or the Product changed to Browser.

re: comment #1: It looked OK in IE 5.2 for OS X but I thought you wouldn't want to hear that ;-) I don't mind if you want to change the product or whatever so this gets fixed in gecko (i'm assuming that's where it probably should go).

I'm not sure breaking on slashes is such a hot idea. I think we should only break on whitespace or pseudo-whitespace characters such as soft hyphens.

gee, i was thinking the exact opposite -- that the browser should never have to widen the view to fit a long word. is there any guidance from the standards? also it might be useful to look to print publishing style guides (I think they usually break on slashes if they need to).

From the W3C HTML 4.0 Specification: "By convention, visual HTML user agents wrap text lines to fit within the available margins. Wrapping algorithms depend on the script being formatted. In Western scripts, for example, text should only be wrapped at white space." The specification goes on to define whitespace characters as: ASCII space ( ) ASCII tab (	) ASCII form feed () Zero-width space (​) Carriage Return (
) Line Feed (
) The specification then explains that there are two exceptions to this rule: the BR element and soft hyphens (­) No mention of slashes whatsoever. Apparently slashes are to be considered regular characters, in which case, Chimera and Mozilla are doing the right thing, and IE is not. Unless anyone knows differently, I suggest this bug be marked INVALID.

Resolving Invalid per comment 7.

Except that the citation you reference http://www.w3.org/TR/html40/struct/text.html#h-9.3.5 begins with the following: Note. The following section is an informative description of the behavior of some current visual user agents when formatting paragraphs. and just after what you quote it says: In Western scripts, for example, text should only be wrapped at white space. Early user agents incorrectly wrapped lines just after the start tag or just before the end tag of an element, which resulted in dangling punctuation. In other words, it's possible that this recommendation (which is informative not normative) about white space is made in order to highlight that wrapping should NOT be done just before a comma (see the example to see what they mean). This bug isn't invalid. Maybe it's wontfix, but that would be a different question: given that the spec doesn't require this, what should chimera do? Obviously I think it's more important to respect the window size and avoid scrolling than to avoid breaking after a slash. For those who think otherwise, why?

The real solution to this problem would be for Mozilla to implement support for soft hyphens. Soft hyphen support has been an outstanding bug in Mozilla for 3 years now, and unfortunately is still Futured indefinitely. Anyone interested in this issue should vote for bug 9101.

Simon: actually, you may have a good point. I've noticed that some print publications (such as O'Reilly books) DO break on slashes (and periods). If you can find some other good examples of this, especially in reputable publications, you may have a good case for reopening this bug. After all, who really defines Western script? The W3C or The New York Times? Of course the product will still need to be changed to Browser.

Updating product, summary, severity, and whiteboard.

re comment #11: I can do that (I worked for the student newspaper for a while). However bug 9101 refers to http://www.unicode.org/unicode/reports/tr14/ which at a quick first reading appears to define how line breaking should work in great detail (and not only for english). For example they have: SY Symbols Allowing Breaks / prevent a break before, and allow a break after I don't think HTML requires browsers to use the Unicode rules but it might be convenient to do so since it looks as if they've already done all the work and it would be just a matter of implementation. And it will work for all the other languages as well, and I can't hope to understand some of the esoteric stuff they talk about in there, about all kinds of languages.

This is probably a subset of the functionality requested by bug 56652. *** This bug has been marked as a duplicate of 56652 ***

Agreed. v.