Closed Bug 155724 Opened 21 years ago Closed 21 years ago

"\n" (two characters) in attribute not interpreted as new line


(Core :: DOM: HTML Parser, defect)

Not set





(Reporter: bogdan, Assigned: karnaze)




When creating a TD tag in a table one can add an attribute title="String" That
String is displayed as a tooltip correctly if it is one line only. Long lines
are not wrapped and even if a \n is added in the string the multiline tooltip
does not appear,
This works with IE6.
Long tooltips not wrapping is a dupe of bug 45375
Maybe the \n thing warrants keeping this bug open (or finding something else to
dupe against or invalidate.)
the \n issue is bug 67127

*** This bug has been marked as a duplicate of 45375 ***
Closed: 21 years ago
Resolution: --- → DUPLICATE
verified dupe of bug# 45375
You are wrong, please read the descrioption again , what I am saying is that
the "\n" does not work as it should i.e breaking the line. Wrapping is similar,
but it is happenning when you run out of space i.e at the edge of a window,
etc.. Here I am forcing multiline with "\n" and it does not work. 
IMO it is not the same thing.

Resolution: DUPLICATE → ---
I think a bug involving "\n" (two characters) will be invalid as "\n" is not a
valid character reference (is it?). 
If you want to embed a new line you should presumably use an entity or numeric
character reference, much like in the testcase (which works here) linked from
bug 67127 (which Alfonso pointed out).
If treatment of the two characters "\n" as 
 is desirable for legacy reasons
it should probably be filed as an enhancement request.
Closed: 21 years ago21 years ago
Resolution: --- → INVALID
The other problem with breaking tooltips is the ambiguity between an intentional
and unintentional newline:

blah blah blah really long end of line <a title="start
oops end of line continue tooltip" ...

If this is turned into a tooltip it will look something like:

oops end of line continue tooltip

which would not be desireable behavior, the same thing would happen with &#0xA;,
I think, as mozilla can't tell the difference between the two.
The bug is not a duplicate and far from being resolved.
Even if you put &#10; or &#0xa as you suggest it still does not create 
multiline tooltip.
The only thing it does is displaying the first line. 

Ex:  "Some string &#0xa Second line" 

the tooltip will print "Some String"

Resolution: INVALID → ---
The use of &#10; (which seems to work in Mozilla 1.0 but not current nightlies)
is covered by bug 67127, any further comments relating to it should be made there.
Automatic wrapping of long tooltips is covered by bug 45375.

The sole remaining issue seems to be whether including the two characters "\n"
in a title attribute should be interpreted as a new line. As far as I can tell
there is no specification saying it should. HTML uses entities to represent
special characters not C style format controls. As such I think the request to
have them treated as a new line is invalid and I'll mark this as such.

If you want to push the bug back to unconfirmed please try and:
a) Include a testcase that demonstrates exactly what you are talking about, so
we can be sure we are talking about the same issue.
b) If there is a spec that backs you up please refer to it.
c) If the desired behaviour is outside spec but still desirable then say so, and
probably change the severity to enhancement

Please note that I'm not just marking this invalid on a whim. I've expended 
effort and time searching bugzilla for dupes, reading specs and talking this
over on irc.
If you are going to push the bug back to unconfirmed please be prepared to
justify that move and supply as much specific information as you can, simply
saying "The bug is not a duplicate and far from being resolved" does not help me
or anyone else understand why.
Closed: 21 years ago21 years ago
Component: HTMLTables → Parser
Resolution: --- → INVALID
Summary: cannot create multiline tooltips → "\n" (two characters) in attribute not interpreted as new line
You need to log in before you can comment on or make changes to this bug.