Closed Bug 24703 Opened 25 years ago Closed 25 years ago

Text -> HTML conversion of underscores uses italics

Categories

(MailNews Core :: MIME, defect, P4)

x86
Windows NT
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: phil, Assigned: BenB)

References

Details

(Whiteboard: fixed. patch in bug 32420.)

I remember talking about this at one point, but I don't see any open bugs on it. When we convert plain text into HTML, I expect _foo_ to get converted to <u>_foo_</u> and right now it seems to get converted into <i>_foo_</i> I'm using today's M13 build on Windows NT.
It is converted to <em class=txt_underline>, because <u> is deprecated. When we have a mailnews stylesheet, the user can format it as underline by taking advantage of the class spec. There were some notes about it in bug #16507 or bug #16800, too.
Ok, but why does <em class=txt_underline> result in italic text? Is that the bug? Personally, I don't see what the big deal is about using <u>. Whether it's deprecated or not, Gecko is going to have to deal with it forever.
The tags are not just generated for display - we also send them out with "enhanced" HTML send. The only way to create an underline in correct HTML is to use a stylesheet. I used <em>, because it propably is nearest to the author's intend - to emphasize.
I think backward compatibility is more important than philosophy here. Which is why Ender puts <u> in messages it sends out. If the CSS code you generate is going to other browsers, that's an even more compelling reason to use the simplest, most interoperable construct. Since I'm paraphrasing a conversation I had with rickg from the Gecko group, I'll cc him just for fun.
I won't send a stylesheet to other MUAs! That's way I used <em>: It's propably one of the most "compatible" HTML tags in existance.
Actually -- <em> has less traditional support than <u>, but not by much.
cc: asj@ipa.net since he's helping write tests for this feature
Status: NEW → ASSIGNED
Priority: P3 → P4
Mass-LATER
Priority: P4 → P5
Ben, I hope you're not going to resolve these bugs LATER. If you don't have time/desire to work on them, put them on the helpwanted list (keyword = helpwanted, reassign to nobody@mozilla.org)
Phil, no, the comment was made in error during changing the priority, sorry. With bug #31907, we rely on a stylesheet for msg display anyway now, so I /could/ easily fix this bug. However, I'm still not sure, if we should. Personally, I think, underlines are a left-over from typewriter times and should be killed sooner than later. But that's just a matter of taste and I'm willing to be overruled in this case. So, what do you all think?
Priority: P5 → P4
My first choice would be to have _foo_ be converted into <u>foo</u>. My second choice would be to leave _foo_ alone. I would prefer not to have _foo_ and /foo/ mean the same thing.
Phil, I asked about option 3 :-) : make it into "<em class=txt_underscore>foo</em>", with a Mozilla Mailnews-internal stylesheet "em.txt_underscore { font-style: inherit; text-decoration: underline }". This would display with an underline (and /not/ italic, unless the parent is italic) in Mozilla Mailnews and italic (as fallback) in most other UAs.
I understood the question. I'm saying it will look like a bug if messages sent from mozilla and read in other MUAs force _foo_ and /foo/ to be italic. If you're less interested in that apparent bug than in using <em> with a style, go right ahead. If you're more interested in getting correct-looking results in any MUA, you'll swallow your philosophical disagreement and use <u>.
Ok, then we have option 4: make it into "<span class=txt_underscore>foo</span>", with a Mozilla-internal stylesheet "span.txt_underscore { text-decoration: underline }". This would display with an underline in Mozilla and with no (additional) style in most other UAs. Phil? Others?
Ben, my first preference would something where the user visually sees something underlined like phil described. As far as the exact styling used on the backend I am not sure I am qualified to answer that.
The <span> idea sounds fine to me. Not as good as using <u>, but at least it doesn't look like a bug.
Target Milestone: --- → M16
Depends on: 33079
Since this bug is marked P4, moving to M17. If you disagree, please let me know.
Target Milestone: M16 → M17
Selmer, this bug is very easy to fix. I'm not keen to fix it at all, that's why it's P4. But others consider it the right thing, that's why it was not WONTFIX, but M16.
Target Milestone: M17 → M16
Note, that the underline will make the underscores (the original content) invisible in Mozilla.
Removing dependency on bug 33079. Unfortunately, I'll have to add the rule to html.css, because the converter is not only used for msg display, but also by AIM and later hopefully by the browser.
No longer depends on: 33079
Whiteboard: fixed. patch in bug 32420.
I'm using "<span class=txt-underscore>" in the conversion plus "[u,] span.txt-underscore { display: inline; text-decoration: underline; }" in html.css now as discussed. > Note, that the underline will make the underscores (the original content) > invisible in Mozilla. Somebody not knowing the functions won't notice, that there's an underscore. Fixing this is easy - it's just CSS. But what exactly should we do?
*** Bug 39090 has been marked as a duplicate of this bug. ***
Changing qa assigned to pmock@netscape.com
QA Contact: lchiang → pmock
checked in
checked in the style rule is not yet checked in. Speaking with rods.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
hmm.... there is no item in the resolution field, but the status shows resolved. Fixed, Ben? Just to make sure.
Yes, Lisa, tnx for noticing.
Status: RESOLVED → REOPENED
Status: REOPENED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → FIXED
Must be a bugzilla bug or so.
Verified as fixed on win32, linux, and macos using the following mtrunk builds: win32 2000-120608-mtrunk installed on PIII 500 running Win98 linux 2000-120608-mtrunk installed on PII 200 running RedHat 6.2 macos 2000-120608-mtrunk installed on G3/400 running Mac OS 9.04
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.