39854 - Want plain text edit mode in mail compose

Status: RESOLVED WONTFIX

(MailNews Core :: Composition, enhancement)

Description

[[e-mail]]

It would be nice to have the editor's edit modes in composer,
plus a plain text preview.

Better still would be to have an editable plain text mode.
This would effectively replace the plain text editor.
Plus, it would allow plain text lists etc. to be created.

Comment 1

[lchiang]

enhancement.

Comment 2

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Marking helpwanted since I think that's what was meant.

Comment 3

[Kathleen :Brade]

not sure who should get this bug...

Comment 4

[Akkana Peck]

Cool idea!  I don't mind owning it (though if someone else wants to, feel free
to take it away).  Of course, this doesn't guarantee that I'll have time to work
on it actively any time soon, so it's still helpwanted.

The biggest problem is this: we only have one DOM tree at a time.  If we switch
from html mode to plaintext mode, that means we'll lose the html dom tree: so
you won't be able to go back to the original html mode.

We might be able to go through the mime path that mail/news follows for
displaying messages, to turn plaintext back into html (though it won't be
exactly the same html that was there before); but that might be hard.

If you didn't require that, i.e. if you switch from plaintext mode back to
normal mode you still see basically plaintext with no html markup, that wouldn't
be too hard to implement.

Comment 5

[[e-mail]]

Can't you do some trick with stylesheets to turn the HTML into "plain text"? The 
plain text should wrap at the outgoing text column given in mail preferences. If 
you have to run the text through the HTML to plain text converter, only do it 
when the HTML formatting changes; normal typing would just insert into both the 
HTML and plain text versions of the document.

Comment 6

[Akkana Peck]

You might be right -- we might be able to do it with style sheets.  This would
be a lot of work, though; and it wouldn't be a true preview, because it wouldn't
be using the same code path that we're going to use when we send the plaintext
message, which is probably what the user is most concerned about.

If someone wants to contribute a stylesheet that implements this, I'm all ears
and if it's close enough to what we actually do send out, and people like it,
I'd certainly have no objection to championing adding it as a new editor mode.

Comment 7

[basic]

ns4 had this feature

Comment 8

[basic]

oops, mis-read the bug, sorry for the spam

Comment 9

[Joachim Noreiko]

it would be nice just to able to switch off (at the Preferences level) the
pasting of formatting + text in email compose windows.

Even if not sending plaintext mail, it is infuriating when quotes text from a
webpage to have to remove the formatting every time

Comment 10

[Max Kanat-Alexander]

Attachment: Basic CSS for "Preview"

Well, here's at least a stylesheet to start with. I did some pretty basic
testing on it. I checked it against some rather complex webpages, and it turned
them into what I would consider to be "plain text."

It requires that you also switch off JavaScript, of course.

I'm actually not too sure what the HTML->plaintext converter does, having not
used it extensively, but I'll bet this is a good guess.

If anybody else wants to work on it, feel free!

-M

Comment 11

[Thomas D. (:thomas8)]

This bug isn't actionable, lacking a lot of necessary detail.

Neil, can you comment on your intentions for this bug, and if this is still feasible at all?

I'm having a hard time trying to imagine a practical implementation of this vague idea. It's certainly wontfix in terms of our current resources; but I'm still hesitant to just shoot down the idea as a whole because I can understand that when sending Both (plaintext and HTML flavor of the same message), users might want more control to check or change the plaintext part.
The main problem here would be editing complex HTML vs. plaintext at the same time and syncing in both directions, which seems impossible without losses and perturbations, and very complex if not impossible to implement (E.g. currently, View as plain text of a simple HTML table does not even try to recreate/mimic the table structure...)

Btw does viewing a saved HTML draft as plaintext use the same code path which we use to auto-convert HTML to plaintext upon sending? In that case, we'd already have a way of previewing the plaintext part at least.

Comment 12

[Thomas D. (:thomas8)]

(In reply to Thomas D. (needinfo?me) from comment #11)
> This bug isn't actionable, lacking a lot of necessary detail.
> 
> Neil, can you comment on your intentions for this bug, and if this is still
> feasible at all?
> 
> I'm having a hard time trying to imagine a practical implementation of this
> vague idea. It's certainly wontfix in terms of our current resources; but
> I'm still hesitant to just shoot down the idea as a whole because I can
> understand that when sending Both (plaintext and HTML flavor of the same
> message), users might want more control to check or change the plaintext
> part.
> The main problem here would be editing complex HTML vs. plaintext at the
> same time and syncing in both directions, which seems impossible without
> losses and perturbations, and very complex if not impossible to implement
> (E.g. currently, View as plain text of a simple HTML table does not even try
> to recreate/mimic the table structure...)
> 
> Btw does viewing a saved HTML draft as plaintext use the same code path
> which we use to auto-convert HTML to plaintext upon sending? In that case,
> we'd already have a way of previewing the plaintext part at least.

Comment 13

[Thomas D. (:thomas8)]

No reply from reporter...

I don't have very strong opinions about this, but realistically I think whatever this bug wants (which is far from clear) is not going to happen, and also, given 10 comments since this was filed 17 years ago, and no comments since 14 years ago, nobody seems to care, not even reporter.

Let's assume for the sake of the argument that we'd try to implement a preview of the plaintext part of emails sent in "both" formats (HTML + plaintext). There's no point in previewing the plaintext part without an option to edit it. However, editing the plaintext part of a "both" type email is a can of worms which we'll never get right, even if we had the manpower to do it, which we don't. Basically, since keeping the HTML part in sync when editing the plain text part is pretty much impossible, editing the plaintext part would imply de-coupling the two parts. Which is very dubious in terms of ux-wysiwyg and ux-error-prevention. If this is really wanted, I guess it needs a new bug or an addon implementation.

So ultimately, this looks "wontfix" to me.

Comment 14

[Jorg K (CEST = GMT+2)]

(In reply to [e-mail] from comment #0)
> It would be nice to have the editor's edit modes in composer,
> plus a plain text preview.
I think it's pretty clear what the idea is here. In the old Netscape and now in SM they have an HTML *editor* called composer that has four tabs:

- Normal, which is normal "rich text" entry,
- HTML tags, which additionally shows the tags in little yellow boxes,
- HTML source and
- Preview.
Additionally this bug calls for a plain text preview for when you ship your HTML e-mail as text.

Usually the definition if "WONTFIX" is that we won't fix it at all since the feature is not desirable, so we wouldn't even accept a patch. Strictly speaking, we might accept a patch here, but it would turn composition upside down. In the long run, we're looking at replacing the home grown editor in TB, but that's also years down the track.

So whatever the state of the bug is, I won't live to see it implemented ;-(

Note that there is also bug 275968 (which I reported) which calls at least for an HTML tab. If anything, that bug might get implemented. But then there is an add-on which does a semi-decent job, so again, there is no pressure.

Comment 15

[Thomas D. (:thomas8)]

(In reply to Jorg K (GMT+1) from comment #14)

Thanks for linking this up with bug 275968, which is indeed a much more useful and realistic related candidate.

> (In reply to [e-mail] from comment #0)
> > It would be nice to have the editor's edit modes in composer,
> > plus a plain text preview.
> I think it's pretty clear what the idea is here. In the old Netscape and now
> in SM they have an HTML *editor* called composer that has four tabs:

Imho implicit references to unnamed or outdated other applications to describe a desired feature addition in TB is NOT very clear, so in terms of RFE protocol and actual substance, this bug was looking pretty incomplete to me. After Jörg's explanation, it becomes a bit clearer, but still no complete UX analysis/design plan (UI & behaviour).

> - Normal, which is normal "rich text" entry,
> - HTML tags, which additionally shows the tags in little yellow boxes,
> - HTML source and
> - Preview.
> Additionally this bug calls for a plain text preview for when you ship your
> HTML e-mail as text.

It's interesting that comment 0 is so very pretty clear that comment 14 does not even mention what seems to form an essential part of this RFE according to comment 0 and current summary ("Want plain text *edit mode* in mail compose"): Yet another tab to edit the plain text flavor of a both-formats message. Which gives us a total of 6 flavors / tabs, the UX of which is unfortunately not analysed here at all, so both UI and behaviour remain pretty vague. And imho 6 tabs would most certainly qualify for a solid wontfix-rejected, not just wontfix-too-much-work. Not to mention the practical problems I mentioned about syncing the editable plaintext part with its HTML counterpart.

> Usually the definition if "WONTFIX" is that we won't fix it at all since the
> feature is not desirable, so we wouldn't even accept a patch.

Really? Can you point to documentation where that understanding of "wontfix" is laid down?
BMO definition remains vague:
https://wiki.mozilla.org/BMO/UserGuide/BugStatuses

I have seen plenty of bugs (e.g. those of bug 577944) which were wontfixed not because we'd never accept a patch, but because it was thought that it should be tried in an addon first, or we will never have time to do it, etc.
I think wontfix resolution comes with a de-facto structural ambiguity which could easily be disambiguated (see bug 522873).

> Strictly
> speaking, we might accept a patch here,

I offered that sentiment for discussion in my comment 11, but didn't get a response to ni?reporter.

> but it would turn composition upside
> down. In the long run, we're looking at replacing the home grown editor in
> TB, but that's also years down the track.
> 
> So whatever the state of the bug is, I won't live to see it implemented ;-(

So after all is said and done, somehow Jörg seems to agree with my analysis and conclusion...

> Note that there is also bug 275968 (which I reported) which calls at least
> for an HTML tab. If anything, that bug might get implemented. But then there
> is an add-on which does a semi-decent job, so again, there is no pressure.

Agreed. HTML source tab looks much more useful and realistic than an "edit plaintext" tab in HTML composition.

Comment 16

[Jorg K (CEST = GMT+2)]

(In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #15)
> > Usually the definition if "WONTFIX" is that we won't fix it at all since the
> > feature is not desirable, so we wouldn't even accept a patch.
> Really? Can you point to documentation where that understanding of "wontfix"
> is laid down?
No. Got it from bug 1332834 comment #3.

> So after all is said and done, somehow Jörg seems to agree with my analysis
> and conclusion...
Yes. I don't think it's worth having. Commercial HTML editors offer "rich text" + HTML source. That's what we should be aiming for.