378620 - Figure out tooltip whitespace stripping behavior for Firefox 3

Status: RESOLVED INVALID

(Firefox :: General, defect)

Description

[:Gavin Sharp [email: [e-mail]]]

I know some people (Steuard being one of them) have strong opinions about what we should be doing with regard to whitespace stripping. This bug will hopefully be a good place to discuss pros/cons of each approach and ultimately decide whether we want to keep the block of code at http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/browser/base/content/browser.js&rev=1.778&mark=2690-2696#2690, without resorting to baseless advocacy.

Here is the list of pros/cons that I know of for our current behavior (strip out whitespace):

Pros:
- In accordance with HTML spec (not sure how relevant this really is)
- Better behavior in some cases where markup includes unintentional whitespace
- No change in behavior if we ever fix bug 322270 (other than for whitespace entities)

Cons:
- Doesn't match behavior of either SeaMonkey or IE
- Doesn't gives authors a way to explicitly add line breaks (at least not until bug 322270 is fixed)

I might be forgetting something here, but I think those are the salient points. Thoughts?

Comment 1

[:Gavin Sharp [email: [e-mail]]]

The discussion in bug 358452 is probably also relevant.

Comment 2

[Jesse Ruderman]

Will bug 322270 be fixed for 1.9?  If so, maybe we don't need to have this confusing discussion.

Comment 3

[:Gavin Sharp [email: [e-mail]]]

I don't think it will be fixed for Firefox 3, which is why I filed this bug. I'm not sure that it's ever going to be "fixed", since it might lead to incompatibilities with the web. You're right that if it is, our decision here would be simpler :)

Comment 4

[Steuard Jensen]

I think that my main position boils down to two points (which you've pretty much summarized already):

1) I have a personal distaste for seeing incidental whitespace in my HTML source mysteriously turned into formatting data (or scripting data, for that matter).  Whitespace in HTML, SGML, XML, etc. is supposed to be entirely independent of the meaning of the code: I should be able to shift it around any way I'd like (for code readability, for example).  To violate that expectation even though the standards provide a perfectly reasonable way to insert the desired formatting (i.e. 
, etc.) would be very frustrating.

2) If at any point Mozilla does release a Firefox version that follows the IE behavior by treating title attributes as preformatted text, I believe that it will be sociologically impossible to go back.  (Web authors will see Firefox as endorsing a de facto web standard, and howl if we later drop that support.)  If the community decides to take that route, I'll live with it, but we must make that decision with our eyes open: do so with the expectation that returning to "proper" HTML whitespace handling will never be an option.

For me, the clear conclusion from those two points is that our eventual aim should be to fix bug 322270 and implement a standards-compliant way to format tooltips.  In the meantime, therefore, we must not implement the IE behavior.  I do understand that others may put a high enough value on the ability to format tooltips that they're willing to give up on code readability and the standards in exchange, but hey, I'll let them defend their own point of view.

One final note: there are still lots of good reasons to fix bug 322270 apart from tooltips!  (Hard-to-trace problems with JavaScript and annoying behavior of INPUT (type=text) elements are already mentioned in that bug.)  I would find it painfully ironic if we eventually fixed that bug but had to hack in tooltips as a special exception to the desired behavior!  (The only other required special exception that I know of is the <INPUT value="..."> attribute.)  I do recognize that fixing bug 322270 would require serious effort (or even major changes to the parser); if fixing it within the next few years is hopeless, maybe it's not reasonable to hold out for "proper" whitespace behavior.  But I don't have to like it. :)

Comment 5

[Mike Connor [:mconnor]]

Not blocking on this, though if we can come up with a good answer we should do this.

Comment 6

[Steuard Jensen]

As discussed in bug 322270 over a year ago, HTML5 seems to have made this issue moot. It seems clear that this bug should be closed, but I'm not entirely sure what the resolution should be. (WONTFIX? FIXED? WORKSFORME?) Hopefully someone more knowledgeable than I am will decide; otherwise the next time I think of it I'll take my best guess and close it myself.

Comment 7

[:Gavin Sharp [email: [e-mail]]]

We fixed bug 358452 in Firefox 12. This bug isn't useful anymore!