Open Bug 43047 Opened 24 years ago Updated 2 years ago

Underlined text looks bad in 4.x's editor

Categories

(MailNews Core :: Composition, defect, P3)

Product:
MailNews Core
Component:
Composition
Type:
defect

Tracking

(Not tracked)

Milestone:
Future

People

(Reporter: akkzilla, Unassigned)

Details

(Whiteboard: Waiting for solution (alternative to <span>))

Attachments

(1 file)

Changing default pref for HTML->HTML conversion durinh msg send
667 bytes, patch
Details | Diff | Splinter Review 
When Joe Francis sent out this week's status report using mozilla mail, he had
an underlined word in it.  On send as html, this apparently got turned into
<span class=txt-underscore><span class=txt-tag>_</span>not<span
class=txt-tag>_</span></span>, and when I try to reply in 4.72, I see a whole
bunch of yellow tags: if <Y> is a yellow tag icon and </Y> is one with a slash
in it, I see <Y><Y>_</Y>not<Y>_</Y></Y>.

This seems wrong, especially if all Joe was doing was underlining a word (Joe,
do you remember what you did?)  We should produce output that's simple enough
that it can be replied to effectively in older mailers.
Keywords: 4xp
akk,
all he did propabaly was to type " _not_ ".

What problem does 4.x have with spans (and divs BTW)?

Do you have any suggestion, other than removing features or information?

Explanation for the current state: I used the first span, because <u> is
(rightfully) deprecated. I use the spans around the tags, so the recipient has
the choice to remove them (e.g. I do that in my user stylesheet).
Status: NEW → ASSIGNED
OS: Linux → All
Hardware: PC → All
i didnt underline.  I just typed underscores.  I know that there is no special 
code in the typing rules to do anything special with underscores.  Something 
somewhere down the food chain did that.  Perhaps 4.x did it when it read it?

I didn't notice Ben's comments until now.  Are you telling me that mozilla put in 
those spans somewhere?  What is the process by which that happened?  Why use 
spans?  As you've just seen, <u> is more backwards compatible.

jfrancis,
this a feature of Mozilla, currently exposed by the Pref
Mailnews|Composing|Convert structures phrases to HTML styles on Send. It is
planned to remove the pref UI and to default to off in Netscape 6. But we should
fix this bug nevertheless.

re <u>:
- It is deprecated. If I had the choice between deprecated stuff and breaking
older clients, I'd usually choose the latter.
- It is presentational HTML, which is IMO very bad.
- IMO, underlining on a computer is dumb.
Is there an alternative to span, for which 4.x won't produce hardly readable
output?
BTW: The last resort if of course to remove the feature completely, but this is
hardly a good solution. There are other places where I need something like divs
or spans. I'll post to .editor about it.
We have already made the decision on Messenger HTML: backwards compatibility 
overrides deprecation.  Dead snake.  And I must be dumb, because I underline in 
mail.  My message is what triggered this bug.  

>Is there an alternative to span, for which 4.x won't produce hardly readable
>output?

yes: <u>.  We are already using it when the user chooses underline from within 
the editor.  We shouldn't convert typed underlines to something else.  Why are we 
converting them at all?  It's ascii.  We should leave them alone. 

I understand wanting to be standards compliant, which is the right thing to do 
and we should strive to ensure that as much as possible. A deprecated element is 
still very legal and is still supported. An obsoleted element is one that should 
not be used at any cost.

How one chooses to construct their documents should not be an issue or part of 
the discussion. We should be flexible enough to allow a user to construct any 
type of document they wish to construct as long as it falls within the 
parameters of the standards.

We also need to be concerned with backwards compatibility, as aggrevating as 
that may be. My analogy to all of this is like driving a car (mozilla) at a fast 
speed on the freeway (rushing to completion) by focusing in the rearview mirror 
(backwards compatibility at all cost), which will eventually result in a crash 
of some sort in the future (current documents ending up being non-standard). It 
always seemed wiser to look through the windshield (staying standards compliant 
at all cost). However, we most not get blinded by that goal, we still have 
thousands of user who are still in the 4.x environment. Within the mail 
application, remaining standards compliant is not the most critical issue. 
Ensuring that the whatever number of millions of 4.x mail users is a more 
critical factor. It will take time for the 4.x user base to upgrade to the new 
world. So, we need to ensure that our solutions fit that model.

To be backwards compliant, to be I9 sensitive, such characters as the underscore 
should be converted to their ascii equivalent, the underscore should be 
converted to &#95; (ampersand,pound,95,semi-colon). Invoking CSS within the mail 
client at this juncture is probably risky and if it is introduced, it must be 
thoroughlly tested with 4.x to ensure compatibility, if it isn't compatible, 
then it needs to be adjusted or removed.
beppe, I mostly agree with you, but I didn't understand the last sentence. What
do you mean with "invoking CSS"? I heavily use CSS within Mozilla, but don't
rely on it or even insert it in teh quoting case (i.e. the HTML that is inserted
inthe editor and later sent).

Posted to .editor <news://news.mozilla.org/394FAFEA.536FB355@bucksch.org>.
The CSS issue in regard to backward compatibility was the point that I was 
trying to make (which wasn't that clear,, sorry). The 4.x version did not 
support CSS well at all, 4.x also has issues with some HTML 4.0 elements and 
attributes. The DIV element for example is not used correctly, for example if 
you attempt to center a heading, a div element is wrapped around the heading 
with an align=center (why?). Many CSS objects are not recognized at all. So, 
from that perspective, if we need to make a choice between a deprecated element 
and the use of CSS (within mail compose), odds are we should probably stick with 
the deprecated element.
> if we need to make a choice between a deprecated element and the use of CSS
> (within mail compose), odds are we should probably stick with the deprecated
> element.

We don't and I don't intend to use CSS. The problem is the span itself (without
any CSS).
what i dont understand is why anything is happening at all.  It's just a "_" 
character.  It's a regular ascii character.  Why do anything unless you are 
converting to some charset that doesn't have "_"?

> It's just a "_" character.

What you meant was underlining, right? That's what I do - trying to move some of
the conventions to HTML markup - the reader might not know the convention but
can understand formatting. Some like it, others don't, that's why there's a
pref.

BTW: "_" is an expection in that it uses <span>: * -> strong, / -> em (or i), |
-> code.
I understand that if you compose in html, make something underlined (i.e. <u>),
and send as plaintext, we may convert to _foo_.  If you compose in plaintext,
write _foo_, and send as html, then you may get <u>foo</u> (though that one may
be more controversial).  But I believe what we have a case of here is Joe
composing in html, typing _foo_, then sending as html.  In the html-to-html or
text-to-text case, there should be no translation needed: if the user wanted
real underlining, he would have typed it that way, and if he typed underscores,
it's because that's what he wanted.  Even aside from the div issue, it seems
wrong to be translating the user's html to some html other than what he saw in
his compose window.
> it seems wrong to be translating the user's html to some html other than what
> he saw in his compose window.

We do this in 4.x for URLs as well. In fact, that's why this html-to-html
function |mozTXTToHTMLConv::ScanHTML| exists at all.

We could disable it by default, but I think, it does make some sense.
All I know is that I don't want any html-to-html translation of regular old ascii 
characters.  That seems a lot more evil than not preserving source formatting...

> All I know is that I don't want any html-to-html translation of regular old
> ascii characters.

Not even URLs? I guess, *a lot* of people will complain then.

Assuming you speak only about "structured phrases": What exactly do you mean?
- Do you personally don't want that? (Then just turn it off.)
- Do you think it is not a good idea in general? (Then we should maybe just
change the default pref.)
- Do you think it's so evil that we shouldn't even give the user an option to
enable it? (Then we would have to remove the code, which is 3 lines or so.)
>Assuming you speak only about "structured phrases": What exactly do you mean?
>- Do you think it is not a good idea in general? (Then we should maybe just
change the default pref.)

That option represents my view.

I'm confused -- if css isn't being used then what does class=txt-underscore & 
class=txt-tag do?
beppe,
txt-underscore: Mozilla has (should have) a rule for this to underline it
txt-underscore and txt-tag: the recipient can format it however he wants.
Somebody requested to give the option to remove the plain text tags (and I agrre).

then css is being used -- ie the 'rule'
Yes, but there is no CSS sent out (the CSS is "built into" Mozilla), so there is
no compatibility issue with CSS.
QA Contact: lchiang → pmock
why does this not have a milestone?  setting to m17.
Target Milestone: --- → M17
jfrancis, it has no milestone, because we have no reasonable solution. I'm still
waiting for a good solution for the problem I raised in my recent post to
.editor. Clearing MILESTONE.

Changing the default of pref "mail.send_struct"
<http://lxr.mozilla.org/seamonkey/source/modules/libpref/src/init/mailnews.js#415>
might decrease the visibility of this bug, but not solve it. It will certainly
not solve the other, similar occasions.

Also, I don't think, this "isn't replyable", you can simply ignore or remove the
additional formatting in 4.x (or disable the feature in Mozilla). Correct me, if
I'm wrong. Adjusting SUMMARY.
Summary: Underlined text isn't replyable in 4.x → Underlined text looks bad in 4.x's editor
Target Milestone: M17 → ---
I'm very confused.  Are you telling me that having a default behavior that in 
incompatible with 4.x mail is ok?  If that's not what you are telling me, then 
turn off the behavior.  This behavior is not needed at all, let alone if it 
causes problems in 4.x.  There is no reason to do additional markup for 
underscore characters when going from html to html.  And there are at least two 
big reasons not to.

> Are you telling me that having a default behavior that in 
> incompatible with 4.x mail is ok?

I don't see anything being "incompatible" with 4.x. It just *looks* bad, which
is 4.x' fault. <span>s are completely legitimate and usually non-intrusive
(that's why I chose them).

Apart from that, I am not saying, everything were OK. It's unfortunate. It
should be fixed. But without suffering in other places.

> If that's not what you are telling me, then turn off the behavior. 

Yes, we can do that, but that won't fix this bug. People can still turn it on.
It should work well in all cases.

> There is no reason to do additional markup for underscore characters when
> going from html to html. 

There is: It helps recipients understand you. Not everybody knows what
"_underscore_" or "*strong*" or "/italics/" (which all hang off the same pref)
means.
Whiteboard: Waiting for solution (alternative to <span>)
I don't want the lack of closure on this bug to distract us from two more central 
issues: the _foo_, *foo*, and /foo/ conversions should all be off by default (is 
that the case yet?) and they should be off for html->html totally, ie, if you 
turn on the pref it should not be active in this case.

Have those two things happened?  If not I'm going to open a new bug for them.

Could somebody review the patch please?

(Note: This patch doesn't fix this bug, the patch just makes the bug much less
bad.)
r=jfrancis

Bug 44446 about the default pref change.
OK, I changed the default and also removed the pref UI for the HTML->HTML struct
conversion feature. So, the "problem" only appears, if
- a Mozilla user enables the *hidden* pref and
- a 4.x HTML composer user replies to a msg with _underline_
So, what should I do with this bug? WONTFIX?
I don't know what to do with this bug.

Joe, you are still voting for this bug. You know the options (including the fact
that using <u> is no option for me), make a suggestion/call/whatever.
why isn't the underscore just converted to the ascii equivilant?
beppe, the underscore *is* ASCII!?! The HTML->HTML conversion feature is about
enhancing this with formatting, so _underscore_ gets displayed underlined.
so underscore gets displayed as underline? You want the <u> to be an underscore?
beppe,
_not_ -> <span class=txt-underscore><span class=txt-tag>_</span>not<span
class=txt-tag>_</span></span>
during send, if the pref is enabled. (While .txt-underscope { text-decoration:
underline (IIRC) }.)

Ben -- sorry to be so slow on understanding this one, but I still don't 
understand why it isn't sent as &#95;not&#95; -- what formatting needs to be 
done for an underscore
> what formatting needs to be done for an underscore

Nothing (it's off by default) - it's just fancy, if it's there. The underscore
usually means "underline", so I did underline it (if the pref is on). That's
all.
sorry, i was on vacation when Ben asked for my comments.  My view is the same as 
before: 
1) HTML-to-HTML formatting conversions should always be off.
2) When doing TEXT-to-HTML conversion, we should use <u> instead of spans+css

Making the default pref be off for HTML-to-HTML and having it be hidden is pretty 
darn near always having it off, so I think we are pretty much where I'd like us 
to be there.  

It would be nice to use <u> so we don't break our own 4.x mailer.  I'm aware that 
<u> is decremented, but as a practical matter, it is never, ever, going to be 
unsupported.  A distinction without difference, is no distinction....

Changing personal priorities. Giving away most of my bugs :-( (reassigning to
default owner).

I will still track these bugs closely. If you need my input, feel free to ask me.

New owner: Please do *not* close these bugs (as WONTFIX or whatever you may
find) unless they are fixed. Rather, reassign to <nobody@mozilla.org>, if you
don't want to work on them.
Assignee: mozilla → ducarroz
Status: ASSIGNED → NEW
QA Contact: pmock → esther
QA Contact: esther → pmock
Does this still a problem?
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.7
The biggest problem (adding extra html uneccessarily to messages that are already 
in html) is fixed, I believe.
Target Milestone: mozilla0.9.7 → Future
removing myself from the cc list
Product: MailNews → Core
Assignee: ducarroz → nobody
Status: ASSIGNED → NEW
QA Contact: pmock → composition
Product: Core → MailNews Core
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: