Comment 183 for bug 19250

First, it's only just hit me that this bug was first reported in the context of
ALT text for images, but the current summary and the existing patches for the
problem apply only to tooltips. Given that newlines in ALT text are still
handled improperly (just tested with Firefox 1.0 on Win98), is there any bug
still dealing with that (and with newlines handled improperly in other
attributes), or should a new one be filed? It seems like many of the ideas
being implemented here should apply generally to all attributes (though bug
228099 comment 7 points out why quirks mode should avoid these replacements for
the "value" attribute, at least).

And second, in reply to comment #182:
> Feneric, it looks like you're confusing characters and character entities. See
> comment 131 for what everyone seems to agree is the correct behaviour. It's
> just a matter of getting the code patched to do that!

It looks to me like Feneric's point is essentially the same one that I made in
comment 166. This bug started life as a request to honor the HTML specification
by treating whitespace as whitespace rather than changing some of it into
visible characters. But at some point, it evolved into a worthy but rather
different enhancement request to enable pre-formatted (multi-line) tooltips
using explicit character entities.

I agree that this enhancement is a valid and useful reading of the
specification! But I'm not convinced that the two issues are related, either
conceptually or in the code. As I understand it, solving the original problem
should just be a matter of replacing every block of whitespace in a title
attribute with a single space ("s/\w+/ /g", I think), and there's probably
already code somewhere that does that ("white-space: normal" in CSS, for
instance). Even if it's not quite that easy, the original problem can't
possibly have anything to do with the current blocking bug 228673 (which
wouldn't arise here at all without patch v0.4's change to browser.js that
enables multi-line tooltips).

In short, it looks to me like the original bug could probably be fixed without
too much trouble by those who know the code. (Please correct me if that's
wrong!) But instead, that fix is being incorporated into a complicated
enhancement with a fairly low apparent priority. So why not spin off the
enhancement into its own bug (or if it's easier at this point, create a new bug
for the original issue and relabel this one), and in the meantime check in a fix
for the original problem?