Text -> HTML conversion of underscores uses italics

VERIFIED FIXED in M16

Status

P4
normal
VERIFIED FIXED
19 years ago
10 years ago

People

(Reporter: phil, Assigned: BenB)

Tracking

Trunk
x86
Windows NT

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: fixed. patch in bug 32420.)

(Reporter)

Description

19 years ago
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.
(Assignee)

Comment 1

19 years ago
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.
(Reporter)

Comment 2

19 years ago
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.
(Assignee)

Comment 3

19 years ago
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.
(Reporter)

Comment 4

19 years ago
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.
(Assignee)

Comment 5

19 years ago
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.

Comment 6

19 years ago
Actually -- <em> has less traditional support than <u>, but not by much.

Comment 7

19 years ago
cc: asj@ipa.net since he's helping write tests for this feature
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
Priority: P3 → P4
(Assignee)

Comment 8

19 years ago
Mass-LATER
Priority: P4 → P5
(Reporter)

Comment 9

19 years ago
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)
(Assignee)

Comment 10

19 years ago
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
(Reporter)

Comment 11

19 years ago
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.
(Assignee)

Comment 12

19 years ago
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.



(Reporter)

Comment 13

19 years ago
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>.
(Assignee)

Comment 14

19 years ago
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?

Comment 15

19 years ago
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.
(Reporter)

Comment 16

19 years ago
The <span> idea sounds fine to me. Not as good as using <u>, but at least it
doesn't look like a bug.
(Assignee)

Updated

19 years ago
Target Milestone: --- → M16
(Assignee)

Updated

19 years ago
Depends on: 33079

Comment 17

19 years ago
Since this bug is marked P4, moving to M17.  If you disagree, please let me know.
Target Milestone: M16 → M17
(Assignee)

Comment 18

19 years ago
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
(Assignee)

Comment 19

19 years ago
Note, that the underline will make the underscores (the original content)
invisible in Mozilla.
(Assignee)

Comment 20

19 years ago
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.
(Assignee)

Comment 21

19 years ago
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?
(Assignee)

Comment 22

19 years ago
*** Bug 39090 has been marked as a duplicate of this bug. ***

Comment 23

19 years ago
Changing qa assigned to pmock@netscape.com
QA Contact: lchiang → pmock
(Assignee)

Comment 24

19 years ago
checked in
(Assignee)

Comment 25

19 years ago
checked in

the style rule is not yet checked in. Speaking with rods.
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago

Comment 26

19 years ago
hmm.... there is no item in the resolution field, but the status shows resolved.  
Fixed, Ben?  Just to make sure.
(Assignee)

Comment 27

19 years ago
Yes, Lisa, tnx for noticing.
Status: RESOLVED → REOPENED
(Assignee)

Updated

19 years ago
Status: REOPENED → RESOLVED
Last Resolved: 19 years ago19 years ago
Resolution: --- → FIXED
(Assignee)

Comment 28

19 years ago
Must be a bugzilla bug or so.

Comment 29

18 years ago
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.