Many web authors make use of the MSIE behavior that translates newlines in title attributes into line breaks in the resulting tooltip. This has led to frequent requests for Mozilla to do the same thing; see for example the many votes, comments, and duplicates for bug 67127 (which was until recently listed as a Core bug rather than being specific to the Suite: this bug is being filed to fill the void due to that change). See that bug for several testcases, some attempted patches, and very lengthy discussion. Note that this bug is related to bug 218223, but that bug asks for automatic wrapping of tooltips to multiple lines while this one asks for explicit author-specified line breaks. Emulating MSIE's behavior is not ideal: it can easily lead to accidental line breaks if the HTML source is word-wrapped, and it is not compatible with web standards. The HTML 4.01 spec (http://www.w3.org/TR/html4/types.html#h-6.2) says that "User agents should interpret attribute values as follows: * Replace character entities with characters, * Ignore line feeds, * Replace each carriage return or tab with a single space." This rules out a direct mapping of source code newlines to tooltip line breaks. However, it could be consistent with the spec to allow character entities such as 
 to yield tooltip line breaks by delaying entity replacement until after explicit CRs and tabs have been replaced by spaces. (Technically, the spec does not say what order those steps must occur in.) The desired behavior is outlined in bug 67127 comment 131. Before any patch enabling this would work, two things would need to happen. First, the parsing behavior would need to change as outlined above: this would rely on the details of the eventual fix to bug 322270 (enabling the desired behavior may not be feasible). And second, my interim Firefox patch for bug 67127 would need to be reverted (see bug 67127 comment 214 for details: note that for most existing pages, the effect of my interim patch is identical to the effect of any eventual fix for bug 322270). A patch for this issue may in fact be in easy reach (subject to those two caveats): both bug 67127 and bug 45375 were recently fixed for the SeaMonkey suite by the patch in bug 356900, and it seems likely that it could be adapted for Firefox. (I haven't had the time to try yet myself.) Given that, it isn't clear that bug 228673 is actually a dependency for this bug, but I'm copying it over here from bug 67127 at least until a Firefox patch that works around it does appear. (Bug 356900 comment 15 indicates that the workaround won't be necessary once the reflow branch lands for Firefox 3; if we do get a workaround fix here before then, a Firefox analogue of bug 357337 would be necessary.)

The HTML specification itself isn't clear in regard to the order that those steps in attribute handling must occur (if they were ordered steps, the spec should have listed them as 1, 2, 3 rather than ul bullets), but it is assumed that, since HTML is an SGML implementation, the SGML specification should define more exactly how attributes should be parsed. I don't have a copy of the SGML specification and it apparently costs money to access it. XML is also an SGML implementation, designed to be completely compatible with fully compliant SGML parsers, and XML attribute parsing should therefore theoretically be compatible (although taking into account any differences in the corresponding SGML profile, which shouldn't matter in this case). Looking at the XML specification, it does say that 
 character references should result in a newline in the finished result. That in turn implies that, unless the XML specification is wrong and is incompatible with SGML, 
 character references in HTML attributes should also result in newlines in the finished result. XML attribute-value normalization: http://www.w3.org/TR/REC-xml/#AVNormalize

(In reply to comment #1) ... > Looking at the XML specification, it does say that 
 character references > should result in a newline in the finished result. That in turn implies that, > unless the XML specification is wrong and is incompatible with SGML, 
 > character references in HTML attributes should also result in newlines in the > finished result. Two comments. First, I don't think that the logic you've used to draw conclusions about the SGML spec is valid (though I don't have a copy, either). If the SGML spec were ambiguous in the same way that the HTML spec is, then it would be entirely consistent for a compatible specification like XML to mandate one particular way of resolving that ambiguity. That doesn't mean that the original must have been equally unambiguous. And second, your comment does make it clear that there is no standards compliant way to allow XML authors to control line breaks in tooltips (or at least, none that we've been able to come up with). If there is a clear statement that entities in HTML must be evaluated before getting rid of newline characters, then it seems likely that this bug should be resolved as WONTFIX despite the popular demand for the feature. For that matter, if there is no practical way to make the parser do that (see bug 322270) then this bug would probably be WONTFIX as well. (Personally, I'm not convinced that that would be a bad thing, but feelings seem to run strong on this topic.)

I'm confused by your comment. I definitely did not imply that XML authors can't specify newlines in attribute values -- quite the opposite. If you look at the section of the XML specification I linked to, it specifically says that 
 in the attribute value source should result in a newline after all of the parsing is done. From the XML specification: "Note that if the unnormalized attribute value contains a character reference to a white space character other than space (#x20), the normalized value contains the referenced character itself (#xD, #xA or #x9)." And again, the HTML specification does not say that character references should be replaced with characters before line feeds are ignored. The list is an unordered list, meaning it isn't defining a sequence of events (or if it is, it was likely intended to be read as the XML spec is written, where only one of the three operations is done on any given character or character reference). I assume that the SGML specification describes this in further detail because this is an area that needs to be unambiguous. The HTML spec likely means to simply restate a summarized description of the SGML parsing rules, and the SGML spec should be referenced for actual details. Assuming that the SGML specification isn't ambiguous on this and that XML is in fact completely compatible with fully compliant SGML parsers (which the XML specification says it is), the attribute value normalization rules in the XML specification must lead to the same result that you should get in HTML. If it turns out that the SGML specification *is* for some reason as ambiguous on this issue as the HTML specification, then it is still perfectly valid to follow the rules in the XML specification, which is what most web developers seem to want.

(In reply to comment #3) > Assuming that the SGML specification isn't ambiguous on this and that XML is in > fact completely compatible with fully compliant SGML parsers (which the XML > specification says it is), the attribute value normalization rules in the XML > specification must lead to the same result that you should get in HTML. And what about XHTML? Let us suppose that SGML unambiguously specifies that 
 should be parsed as whitespace. Since the XML spec differs here (by this supposition), in what way will it be parsed for documents served as application/xhtml+xml? The XML way or the HTML way? I would assume the XML way, since XHTML is meant to be an XML application. This is ignoring the issue of how tooltips are actually displayed, for a moment. That's more a matter of what is displayed if a newline finds its way into the attribute value (e.g. through DOM alteration.) -[Unknown]

(In reply to comment #3) > I'm confused by your comment. I definitely did not imply that XML authors can't > specify newlines in attribute values -- quite the opposite. If you look at the > section of the XML specification I linked to, it specifically says that 
 > in the attribute value source should result in a newline after all of the > parsing is done. Ah, thanks: my mistake. I looked at the part of the spec that you referenced, but I was clearly careless in doing so. It sounds like you're exactly right: the required XML parsing behavior is exactly what was described as ideal in bug 67127 comment 131. How had I not noticed that before? In any case, I agree that we should parse HTML the same way. (And that means that tooltips could allow author-specified line breaks for both.)

*** Bug 361908 has been marked as a duplicate of this bug. ***

It's hardly understandable that such a useful and baseline functionnality still lack while gecko now exists since years. So many Web applications have to use some Javascript Workarounds, creating faked tooltip while the TITLE tag is here for that... Is there a serious developer there that WILL FINALLY ADD this so we can, at last, focus on something else than a very basic functionality? Disappointing! If the standard does not say 'You must take care of carriage returns in tooltips' does it means that it's a useless functionality? While even browsers using Gecko as renderer implements it in their own interface (look at tooltips on WebPage shortcuts in Ffx, they are on two lines. Better user experience, isn't it?) Thanks for reading PS : I don't mind which character code should be used to indicate a carriage return, but give us a way to do it!

Isn't this a dupe of bug 322413?

(In reply to comment #8) > Isn't this a dupe of bug 322413? Alt attributes are for alternative content. Title attributes are for tooltips. They have different uses, different intentions, and could theoretically display entirely differently. So - whether you should have linebreaks in alt attributes is an entirely separate issue from whether they should be available in tooltips. That said, they would seem related (both being attributes) and the discussion on parsing in this bug is most likely relevant. -[Unknown]

If you look back at the initial reports for this bug and for bug 322413, you will see that they both trace their ancestry to bug 67127 (and that I filed both of them, as it happens). Bug 67127 started out as an ALT bug, got generalized to cover tooltips as well, and then narrowed back down to focus ONLY on tooltips. The parsing issues discussed here most certainly are relevant to both bugs; that's why they both depend on bug 322270.

This is going to be partially fixed by the patch for bug 218223, by allowing explicit newlines in the HTML markup (the IE behavior). Firefox will basically behave in exactly the same way as current trunk SeaMonkey.

Yikes. Assuming I understand you correctly, I don't think I consider that to be "partially fixed" at all, but rather "broken further". The whole reason that I got interested in bug 67127 and its kin was that word-wrapping my HTML source to make it legible led to bizarre formatting of tooltips (in violation of the HTML specification). Changing to the IE behavior would bring back a bug that I've spent rather a lot of time to fix. Also, I think that bug 322270 is an important one (the Javascript issues there alone make it worth fixing), but I expect that if Firefox goes ahead and endorses the IE tooltip behavior there would be strong opposition to ever undoing that. Sociologically, it seems much more reasonable to hold off on supporting this feature until we can do it right.

Long tooltips now wrap, which is sufficient for now. Not going to block on further tweaks, but will accept appropriate patches.

I would very much like to see support for multiple line tooltips.

(In reply to comment #15) > I would very much like to see support for multiple line tooltips. We already support multiple line tooltips in Firefox 3 betas - this bug is about supporting line breaking with explicit line breaks.

(In reply to comment #16) > We already support multiple line tooltips in Firefox 3 betas - this bug is > about supporting line breaking with explicit line breaks. > Ok, thats what I mean. It would be great if you could put newlines in a tooltip. Is there a way around this currently? Is there any way to manually start a new line in a tooltip?

No. That's what this bug requests should exist. We all want it to happen, which is why we've voted for or are otherwise watching the bug. No one has yet taken the time to write the code to make it happen, and it won't happen until someone does. There are 100,000+ outstanding bugs/feature requests waiting to be fixed, and they cannot all be fixed as quickly as everyone would like. Otherwise Mozilla would be perfect. :)

We should try to get something soon here. We are loosing some nice points from the standard compliance tables over this: http://www.webdevout.net/tidings/2008/06/16/firefox-3-css-and-html-support-information-available/

Seems to me that it's ignominious to agonize over standards regarding such a trivial thing as forcing a line break into tooltip text. I have a web page that's bilingual (USEN and NO), so I'd like to have a bilingual title="This is English
Dette er Norsk" produce a two-line, bilingual tooltip. It's quick, simple, intuitive, and very unlikely to cause problems, IMHO — and it works in MSIE.

This really should be in Core...

mconnor: this is actually handled in browser code: http://mxr.mozilla.org/seamonkey/source/browser/base/content/browser.js#2520

mconnor: To clarify, the Core dependency that you're thinking of is bug 322270 (which blocks progress on this bug unless we decide to switch from standards to the IE behavior). Should the "wanted-firefox3.1?" flag that was cleared here be restored, or perhaps transferred to a "wanted1.9.1?" flag on the Core bug? (I'm guessing it would be -'d in either case, but a formal decision couldn't hurt.)

HTML5 is very clear about this: "If the title attribute's value contains U+000A LINE FEED (LF) characters, the content is split into multiple lines. Each U+000A LINE FEED (LF) character represents a line break." http://www.whatwg.org/specs/web-apps/current-work/#the-title-attribute (The HTML5 parsing algorithm doesn't normalize white space like XML, so raw line feeds in the source end up in the DOM.)

What's the current status on this issue? I'd gotten the impression that the HTML5 parser was going to resolve the situation (and probably adopt the IE behavior, for better or worse), but as far as I can tell, Firefox 4 is still collapsing whitespace the same way that it used to. What is still required to match the new spec?

(In reply to comment #29) > What's the current status on this issue? I'd gotten the impression that the > HTML5 parser was going to resolve the situation (and probably adopt the IE > behavior, for better or worse), but as far as I can tell, Firefox 4 is still > collapsing whitespace the same way that it used to. The collapsing is not happening in the HTML parser. It happens somewhere higher up.

This patch seems to make tooltip newlines work for me. Though this is just a quick hack and I didn't consider any fallout from doing so. Also, there's a comment at the top of this function about keeping some embedding code in sync with this? Anyway, with the following test: data:text/html,<div title="foo$#x01;bar">hover me</div> I get a tooltip with two lines, whereas stock Firefox 4 shows a 1-line "foobar" tooltip. This is just a quick driveby proof-of-concept. It would be really helpful if someone could write up some HTML testcases of what's expected to work / not-work. And even just finish up this patch -- I'd be happy to review it! :)

Oops, typo. That should have been: data:text/html,<div title="foo&#x0a;bar">hover me</div>

(In reply to comment #29) > What is still required to match the new spec? HTML5 says to display breaks in the tooltip when LFs occur in the attribute value: http://www.whatwg.org/specs/web-apps/current-work/#the-title-attribute http://www.whatwg.org/specs/web-apps/current-work/#the-title-attribute-0

Test: http://hsivonen.iki.fi/test/moz/title-attribute.html I have no idea how to write mochitests for this. Any advice? The code part of the patch still needs a more compatible tab size. Firefox gives a tab size of 3. Chrome has 4. IE has 8. Since IE is the oldest, we should probably go with a tab size of 8 unless HTML5 changes to say 4.

(In reply to comment #34) > The code part of the patch still needs a more compatible tab size. Firefox > gives a tab size of 3. Chrome has 4. IE has 8. Since IE is the oldest, we > should probably go with a tab size of 8 unless HTML5 changes to say 4. Eight spaces for a tab sounds huge to me, though I suppose it would depend on how it looks with a given font. Given that it's apparently not explicit in the spec, I like the idea of compatibility with others, but aesthetics seems worth considering, too (especially when there seems to be no broad agreement among browsers). Would it be worth getting an opinion from some UI specialists? (My instinctive reaction is to go with Chrome on this.)

The spec now says the tab width is 8: http://html5.org/tools/web-apps-tracker?from=6120&to=6121

(In reply to comment #34) > Created attachment 519105 [details] [diff] [review] [review] > Patch v1 (WIP, need to fix tab width and add tests) > > Test: > http://hsivonen.iki.fi/test/moz/title-attribute.html > > I have no idea how to write mochitests for this. Any advice? > There's a test for SVG tooltips here: http://mxr.mozilla.org/mozilla-central/find?text=&string=browser_bug329212.js You could either extend this (using foreignObject in the testcase to generate a html toolip) or create your own just for html.

This enhancement doesn't seem to be in any release yet ? Will it only be implemented for html5 or for html4 as well ?

(In reply to linux from comment #39) > This enhancement doesn't seem to be in any release yet ? It's not in any release, yet. It would help if someone who knows front end testing better contributed unit tests to go along with my fix. > Will it only be implemented for html5 or for html4 as well ? Both. Browsers use the same code for both.

title_test.svg already has tooltips with line breaks so the test works as a test for this new feature too. The title_test.svg file could have tabs added if necessary to create a tab test.

Henri, do you want to do the tabs in this bug or just get it reviewed and landed and do the tabs in another bug?

(In reply to Robert Longson from comment #43) > Henri, do you want to do the tabs in this bug or just get it reviewed and > landed and do the tabs in another bug? Let's just get this landed and do the tab stops as a follow-up. What this is lacking is a unit test, because I'm not properly familiar with front end testing. (In reply to Robert Longson from comment #42) > The title_test.svg file could have tabs added > if necessary to create a tab test. This doesn't seem to test rendering, but if the module owner is OK with this level of testing, let's get this landed.

Comment on attachment 590559 [details] [diff] [review] Patch v1 (WIP, need to fix tab width) The spec doesn't say CR should be treated as a line break, does it?

(In reply to Dão Gottwald [:dao] from comment #45) > Comment on attachment 590559 [details] [diff] [review] > Patch v1 (WIP, need to fix tab width) > > The spec doesn't say CR should be treated as a line break, does it? The spec is wrong. IE9, Chrome and Opera treat CR and CRLF as line breaks: http://hsivonen.iki.fi/test/moz/title-attribute.html

Comment on attachment 590559 [details] [diff] [review] Patch v1 (WIP, need to fix tab width) t = t.replace(/\r\n?/g, '\n');?

Updated and retested per review comment. Looks like tab stops come out as 4 characters currently. Do we want to still convert them to single spaces till we implement the correct stop behaviour? We could try doubling all tab characters perhaps.

Comment on attachment 591062 [details] [diff] [review] Patch v2 (WIP, need to fix tab width) Please file a new bug for the tabs and leave them as-is for now.

pushed https://hg.mozilla.org/integration/mozilla-inbound/rev/fa01b899854a

Has somebody filed a bug on the tab width?

This capability was already documented, but it now includes a note that this is supported in Firefox starting in 11.0. Also mentioned on Firefox 12 for developers.

The previous comment makes it sound like the fix has been released. However, I have Firefox 11.0 and, unless I did something wrong, it appears to behave the same as before. Can someone clarify if this has been released to the general public? If so, could someone clarify the steps required to take advantage of this fix? I assumed '&#x0a;' in the 'title' attribute should result in a new line in the tooltip.

The HTML5 specification stipulates that linebreaks in the tooltip will result from literal linebreaks in the raw source. Entity substitution won't work: instead, just hit enter in the middle of a 'title' attribute and you'll get a linebreak in the resulting tooltip. You should be able to see this behavior in action at the URL link in the bug description: the "ignoring line breaks" and "forcing line breaks" there demonstrate the current behavior. (But ignore the explanatory comments on that page!) As you've found (and as you can see on that test page), the HTML5 behavior is quite close to the opposite of what seemed to be expected under the HTML 4.01 specification. But the IE behavior is simple and became widely used, and to my knowledge no browser ever implemented an HTML4-compatible solution. (Note that as a result, automatically word wrapping HTML source is now a Very Bad Idea.)

I would argue (not necessarily to you) following the spec for the sake of following the spec is just plain silly. Just as law enforcement often overlooks laws that are ridiculous, Mozilla does not have to succumb to every short-sighted detail of a spec. The goal of a spec is to align all participants into working in a predicable manner. If every other major browser deviates from the spec in a similar fashion using a superior implementation, then it makes sense to deviate along with them. That being said, I think most devs would prefer entity substitution over a literal line break, but I suppose I'll take it any way I can get it. However, I don't see the line breaks in the tooltips on the page you mentioned using Firefox 11.0. So I'm still unclear if I can expect to see the desired line break in any current or future Firefox release...

(In reply to daiei27 from comment #58) > I think most devs would prefer entity substitution over a > literal line break Agreed. > However, I don't see the line breaks in the tooltips on the page you > mentioned using Firefox 11.0. Target Milestone: Firefox 12

Thank you!