Long words (such as URLs) overflow columns

Awwww. It didn't work because it wasn't the first sentence in this bug. Anyway, bug 351 is a good enough example.

Note also bug 628, which talks about URL display.

Is this also one of the things you were working on kiko?

I posted some options for how to break words on one of the duplicate bugs. Since they are useful, I'll repeat them here:

1. use the non-standard <wbr> tag (word break). This is supported by all major web browsers (apparently includes Opera if used with some special CSS). Has the side effect that double click select won't select the entire word if it contains a word break.

2. use the zero width space character (&#8203;). Apparently causes some display issues in IE.

3. use the soft hyphen character (&shy; or &#173;). This character is supposed to only display when at the end of a line, and act as a word break. Unfortunately, it isn't properly supported by Mozilla (doesn't break words).
  http://www.w3.org/TR/REC-html40/struct/text.html#h-9.3.3
  https://bugzilla.mozilla.org/show_bug.cgi?id=9101

4. use actual space characters. Works with every browser, but looks ugly and can change the meaning of the text.

A rundown of the compatibility for the various word breaking methods can be found here:
  http://www.quirksmode.org/oddsandends/wbr.html

In both cases, we'd need to make some decisions about where to place such breaks. How long can a word get before we break it? Do we just break words at a particular number of characters, or try to inteligently hyphenate the text?

The only option that does not break copy-pasting is the <wbr> tag. But it's not valid HTML by any measure.

Any other option is not acceptable for url, which are commonly copy-pasted. Of course you can right-click-copyurl, but people just do not do that.

I witnessed one employee being badly surprised by copy-pasting a URL that contained zero-width space in the prototype of the branch registration code. That's why I removed the feature.

My preferred solution to this bug is:

    * Do not try being smart, don't arbitrarily insert tags or special characters.
    * Remove the right column, and use a layout that lets the browser handle overfull lines gracefully.

It is not a problem if scrolling is only required to view those veryverylongwords, and if they do not prevent other UI elements from being usable.

I am pretty sure that any other solution is bound to be diffult to implement and annoying in one way or another.

May I suggest addressing this problem with input validation? I can think of no valid use case for the user to enter this type of data when submitting a bug description or comment.

What do you mean by "this type of data"? If you mean long URLs in general, then it's perfectly reasonable for a user to file a Firefox bug report saying "this URL made my browser explode: ...".

On Fri, Sep 08, 2006 at 07:30:39PM -0000, Colin Watson wrote:
> What do you mean by "this type of data"? If you mean long URLs in
> general, then it's perfectly reasonable for a user to file a Firefox bug
> report saying "this URL made my browser explode: ...".

In my case the data was not a URL. I would argue that URLs which make the
browser explode shouldn't be displayed on the page for users to click. ;-)

--
 - mdz

Taking.

Put a branch to fix this up for review. It fixes both long URLs and long words outside of URLs.

Merged to rocketfuel as r4201

fix included in today's rollout