Closed
Bug 24703
Opened 25 years ago
Closed 25 years ago
Text -> HTML conversion of underscores uses italics
Categories
(MailNews Core :: MIME, defect, P4)
Tracking
(Not tracked)
VERIFIED
FIXED
M16
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.
| Assignee | ||
Comment 1•25 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•25 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•25 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•25 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•25 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.
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
| Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Priority: P3 → P4
| Reporter | ||
Comment 9•25 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•25 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•25 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•25 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•25 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•25 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•25 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•25 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•25 years ago
|
Target Milestone: --- → M16
Comment 17•25 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•25 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•25 years ago
|
||
Note, that the underline will make the underscores (the original content)
invisible in Mozilla.
| Assignee | ||
Comment 20•25 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•25 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•25 years ago
|
||
*** Bug 39090 has been marked as a duplicate of this bug. ***
| Assignee | ||
Comment 24•25 years ago
|
||
checked in
| Assignee | ||
Comment 25•25 years ago
|
||
checked in
the style rule is not yet checked in. Speaking with rods.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Comment 26•25 years ago
|
||
hmm.... there is no item in the resolution field, but the status shows resolved.
Fixed, Ben? Just to make sure.
| Assignee | ||
Updated•25 years ago
|
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
| Assignee | ||
Comment 28•25 years ago
|
||
Must be a bugzilla bug or so.
Comment 29•25 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
Updated•21 years ago
|
Product: MailNews → Core
Updated•17 years ago
|
Product: Core → MailNews Core
| Comment hidden (collapsed) |
You need to log in
before you can comment on or make changes to this bug.
Description
•