677171 - Format | Autodetect: If HTML text size is set to "medium" in the Composition/General Tools tab, a mail written entirely in Variable Width/Body Text is converted to a Fixed Width plain text message. No problem if HTML text size is set to "small" or "large"

Status: RESOLVED WONTFIX

(Thunderbird :: Message Compose Window, defect)

Description

[Jonathan Edwards]

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20100101 Firefox/5.0
Build ID: 20110615151330

Steps to reproduce:

HTML text size is set to "medium" in the Composition/General Tools tab.


Actual results:

If HTML text size is set to "medium" in the Composition/General Tools tab, a mail written entirely in Variable Width/Body Text is converted to a Fixed Width plain text message. No problem if HTML text size is set to "small" or "large". Also no problem if at least one character in the composed mail is set to a different font. The problem only happens if the ENTIRE mail is written in Variable Width/Body Text format with HTML Text Size set to "medium"


Expected results:

The composed mail should not be converted to Fixed/Width/plain text format. It should remain and be displayed as Variable width

Comment 1

[WADA:World Anti-bad-Duping Agency]

Draft source saved by Tb 5:
>Large:     <big>abc</big><br>
>Medium:    def<br>
>Small:     <small>ghi</small><br>
If <big> nor <small> is not used in HTML mail, Tb sends the mail in text/plain only, even when mail is composed in HTML.
It's current design/implementation of "Options->Format->Auto-Detect".
See bug 414299. See also bug 396395 and bug 136502.

Same problem as bug 414299?

Comment 2

[Thomas D. (:thomas8)]

(In reply to Jonathan Edwards from comment #0)
> The composed mail should not be converted to Fixed/Width/plain text format.
> It should remain and be displayed as Variable width

It is converted to text/plain, because fontsize "Medium" does not create an HTML tag, so there is no HTML tag from that, so Format:Auto-Detect chooses plaintext for sending.

It is *not* converted to fixed width - depends on recipient's settings for plaintext:

- If recipient's setting is "view plaintext as fixed width", then recipient will see plaintext/fixed-width.
- If recipient's setting is "view plaintext as variable width", then recipient will see plaintext/variable-width (this is default for TB and most other mailers).

Reporter is asking that "variable width" should trigger sending as HTML, because only HTML will ensure display as "variable width" for (practically all) recipients regardless of their individual setting for plaintext (assuming that nobody in their sane mind sets "fixed width" for displaying HTML, if that's even possible).

That's *very strongly* in the same line as bug 414299, where the request is to at least preserve *differences* between fixed and variable width by triggering HTML if *both* have been applied. This bug here wants *even more* control over sent message format than bug 414299. Given the current discussion in bug 414299, this *more control* (let "variable-width-only"-text trigger HTML) is unlikey to happen, but it's certainly in support of the much more moderate request of 414299 -> duplicate.

Comment 3

[Ben Bucksch (:BenB)]

Not a DUP, because this user wants the *exact opposite* of what you want.

The core problem here is that you disagree with how the receiver sees your message. We cannot and don't want to influence that. The receiver has the right to view messages as he pleases, the sender should not influence that (unless there is specific significant formatting). This is intentional, balancing interests.

WONTFIX

Comment 4

[Thomas D. (:thomas8)]

(In reply to Ben Bucksch (:BenB) from comment #3)
> Not a DUP, because this user wants the *exact opposite* of what you want.

Bug 414299 ("what I want"):
if message contains "variable width" AND "fixed width" <tt>, trigger sending as HTML (to trigger "HTML display" at recipient side, and preserving "variable width" AND "fixed width")

This bug 677171 ("what this user wants"):
if message contains "variable width", trigger sending as HTML (to trigger "HTML display" at recipient side, thus preserving "variable width", which is default for HTML display of most mailers)

How is that the opposite of what I want?

> The core problem here is that you disagree with how the receiver sees your
> message. We cannot and don't want to influence that.

That's simply not true:

1.) We (TB) *can* influence how the receiver sees our message:
- if we send plaintext, receiver will see our message as plaintext, i.e. without much formatting (and in most cases, that will be plaintext:variable width, which is default for TB and other mailers, notwithstanding different user preferences)
- if we send plaintext, we risk that some recipients pick display setting "variable width" or "fixed width" which might display our message badly
- if we send HTML, receiver will (by default) see our message as HTML (there won't be many users who force plaintext display for HTML messages), which will *for the majority of cases*, preserve "variable width" vs. "fixed width" predictably as expected.

So while we cannot "force" the correct display of our message, we can expect to "influence" the display significantly by choosing an appropriate format (HTML) where our message is *usually* rendered as we expect.

2.) We (many users) *want* to influence how the receiver sees our message:
- there is plenty evidence in all of these bugs, that users have a big interest that their message formatting should reach the receiver, and it should look as much as the original message as possible, following the ux-principle of wysiwyg.

> The receiver has the
> right to view messages as he pleases,

Ben, nobody questions that, but it's pretty irrelevant. We are talking about "default settings", which can be assumed for a big majority of senders and recipients, especially when we send HTML.

> the sender should not influence that

Says who? I don't agree, nor do the reporters of these bugs. The sender defines the message content, and the message format. Of course recipient is still *free* to display in any less suitable format. If recipient is stubborn enough to view HTML message as plaintext, we can't stop him. Most recipients view HTML messages as HTML, and that's what we want if there's formatting, so that's what we send, assuming that senders apply formatting *for a reason* and not accidentally (which is the only practically possible assumption to make, unless you have a crystal ball).

> (unless there is specific significant formatting). This is intentional,
> balancing interests.

I am mostly failing to see the balance.

> WONTFIX

For this particular case, I personally can live with that (because we don't lose any tags or styles on the way). For reporter it will still come as a surprise, because our UI explicitly says "Variable width" (vs. "plain text"), but we do nothing to preserve that (but we could do something to preserve it, namely send as HTML, which will *trigger* "Variable width" for *most* recipients).

And fwiw, especially after the discussion in bug 414299, I think we should listen a bit more and explain our position to reporter and allow reporter to answer before we wontfix.

Comment 5

[Ben Bucksch (:BenB)]

> How is that the opposite of what I want?

You want fixed width as result, he wants variable width as result.

> 2.) We (many users) *want* to influence how the receiver sees our message:

Yes, and that's exactly where you're wrong and why this is WONTFIX. Because the recipient has the right to choose how he reads mail.

Comment 6

[Jonathan Edwards]

I am in agreement with these comments from Thomas D.
I would like my recipients to read my mails in the format I intend them to see. Also, why treat "Medium" font size differently from "Small" or "Large"? I fail to see the consistency in this approach.
Of course I can live with this "bug", but further explanation for WONTFIX would be appreciated. Thank you.

Comment 7

[Thomas D. (:thomas8)]

(In reply to Ben Bucksch (:BenB) from comment #5)
> > How is that the opposite of what I want?
> You want fixed width as result, he wants variable width as result.

Sorry, but that's not true again.

Both of us (reporter and me) want to preserve message formatting for any of "variable width", "fixed width", or *both* in same HTML composition, as good as TB can. The safest way for TB to preserve (i.e. influence, not force) *both* of these formattings for *most* recipients (given widely used default settings of mailers) is to send as HTML: Because on /most/ mail readers, *default display* for unformatted body text of HTML is "variable width", and for <tt> and <pre> it is "fixed width".

If sending HTML is unwanted for other reasons, namely that some people prefer TB to send plaintext more often, and want TB to avoid sending HTML, that's a completely different story.

> > 2.) We (many users) *want* to influence how the receiver sees our message:
> 
> Yes, and that's exactly where you're wrong and why this is WONTFIX. Because
> the recipient has the right to choose how he reads mail.

If you want to imply that I am denying the recipient's "right to choose how he reads email", then you are misunderstanding me. I explicitly confirmed, in that very comment 4 you are replying to, that recipient has every right to choose any display that he pleases, even if that's nonsensical (like displaying HTML messages as plain text):

(In reply to Thomas D. from comment #4)
> (In reply to Ben Bucksch (:BenB) from comment #3)
> > The receiver has the
> > right to view messages as he pleases,
> 
> Ben, *nobody questions that*, but it's pretty irrelevant. We are talking about
> "default settings", which can be assumed for a big majority of senders and
> recipients, especially when we send HTML. [snip]
> Of course recipient is still *free* to display in any less suitable format.

Recipients are always free to change their display settings, but this is about *which format is /sent/ by TB*, and *probabilities of recipient's default display settings for /that/ format*.

I think we have good reason to assume the following probabilities:

- Most mailers have default display setting of "Variable width" to display unformatted text in body of HTML.
- Most users do not change that setting (almost nobody), because it doesn't make much sense to change it.
=> Unformatted text in HTML body is *very likely* to be rendered as "variable width".

- But for plaintext, most mailers offer a *choice* of displaying plaintext as "variable width" or "fixed width" (with "variable width" being the default, and both settings make sense for different use patterns).
- So for at least /some/ user's who have chosen "fixed width", they will not see font formatting "variable width" (offered in TB UI) if we send plaintext.
=> Unformatted text sent as plaintext is still *likely* to be rendered as "variable width", but *less likely* compared to sending unformatted text as HTML.

=> HTML format is the "safest" (most probable) way of causing "variable width" display on recipient's side (notwithstanding, recipient can always decide to view HTML part as "fixed width" or even plain text, but that doesn't make much sense, so there will be very few people who do that).

No recipient can stop a sender from sending HTML: If sender inserts just a single <b> tag, TB will send as HTML (with Format:Auto-Detect, and recpient's preferred format unknown or HTML). So a sender, if he so wishes, can always enforce *sending* of his preferred format (HTML). Recipient cannot choose the message format of received mail; recipient can only change his /display/ preferences.

So imo this is much less about protecting recipients than protecting the *expectations of senders using TB*, and rightly expecting their *formatting intentions to be preserved as good as possible*.

Fwiw, I believe the true reason for WONTFIX is that Ben wants to avoid sending HTML format and instead send plain text whereever possible (after so-called "lossless" conversion), which is still a noble motive, but much less relevant than in former times where HTML format used to cause all sorts of problems. That's why imho other objectives like "preserving sender's intended format(ting) as chosen from and seen in composition UI (wysiwyg)" might now be more relevant.

Comment 8

[Thomas D. (:thomas8)]

In short, I think the "balance of interests" has shifted, because sending or receiving of HTML messages is no longer a big problem for many users, but more and more users expect their HTML format to be preserved as well and exact as possible while sending, as confirmed by reporter's comment 6 and the duplicates and comments of bug 414299.

(In reply to Jonathan Edwards from comment #6)
> I am in agreement with these comments from Thomas D.
> I would like my recipients to read my mails in the format I intend them to
> see. Also, why treat "Medium" font size differently from "Small" or "Large"?
> I fail to see the consistency in this approach.

You are free to argue that an HTML composition should *never* be sent as plaintext (which is more or less Bug 136502).
The technical reason why "Medium" is treated differently from "Small" or "Large" is that "Medium" does not specify any font size, and does not create any <tags> in the source code, whill small and large are <small> and <big> tags in source.
So "Medium" relies on the default font size settings of the receiving browser/mail reader.
Same for "Variable width", which does not effect any formatting <tags> in the source, but if unformatted text in an HTML <body>, most browsers/mail readers will render as "Variable width".

> Of course I can live with this "bug", but further explanation for WONTFIX
> would be appreciated. Thank you.

+1.

Comment 9

[Thomas D. (:thomas8)]

Per user testimony of comment 0 and comment 6, and per my analysis in this bug, this violates the ux-principles of ux-consistency and ux-wysiwyg (in a somewhat format-datalossy way, but without real dataloss):

1) When user uses default setting of "HTML composition", "Variable width", Size=Medium, we display message accordingly with "Variable width" at composition time, but we incorrectly send out message as plaintext f-f; as a result, most recipients including Thunderbird users with default settings will see the message in "Fixed width", which is the opposite of user expectation and UI feedback.

2) But when user uses "HTML", "Variable width" with any *other* predefined size like "small" or "large", we correctly send as HTML, which conforms with ux-wysiwyg as it will usually preserve the same format seen in composition window for all HTML-compliant recipients (notwithstanding recipients' freedom to look at the HTML message in any reduced format they might wish, or reduced according to the capabilites of their mail reading device).

3) This violates ux-principles of ux-consistency and ux-wysiwyg because the delivery format unexpectedly differs depending on font sizes used (case 1 vs. cases of 2), and for cases of 1 what we display on screen (HTML with variable width) is different from what we send (plaintext which can't preserve the HTML default formatting, i.e. variable width for most recipients).

I'm not saying this is a screamingly bad bug, but I believe it should be openly discussed if this unexpected and somewhat datalossy behaviour is still wanted for Thunderbird:

  variable width HTML in composition -> vs. no HTML in sent message, instead plaintext, mostly rendered as fixed width

...because times have changed and sending HTML is no longer a problem for most users (which is why Text+HTML is the de-facto default on TB except for those cases where Delivery Format > Auto-Detect spoils the experience), on the contrary, many users have requested that their HTML-composed messages be preserved as exactly as possible when sending.

Imho, this bug was resolved wontfix a bit too quickly:

(In reply to Ben Bucksch (:BenB) from comment #3)
> Not a DUP, because this user wants the *exact opposite* of what you want.
> 
> The core problem here is that you disagree with how the receiver sees your
> message. We cannot and don't want to influence that. The receiver has the
> right to view messages as he pleases, the sender should not influence that
> (unless there is specific significant formatting). This is intentional,
> balancing interests.
> 
> WONTFIX

As laid out in comment 4 ff., these arguments are wrong and hence not applicable to support wontfix decision.

In view of all that, I think the current quick wontfix resolution of this bug should be re-evaluated, and user's polite request of comment 6, to explain wontfix resolution, should be answered by Ben or anybody who feels called to answer:

(In reply to Jonathan Edwards from comment #6)
> I am in agreement with these comments from Thomas D.
> I would like my recipients to read my mails in the format I intend them to
> see. Also, why treat "Medium" font size differently from "Small" or "Large"?
> I fail to see the consistency in this approach.
> Of course I can live with this "bug", but further explanation for WONTFIX
> would be appreciated. Thank you.

It's possible that this is considered a "feature" of Format > Auto-Detect; if so, this could be more appropriately resolved as a duplicate of bug 136502. However, the current big problem being that Format > Auto-Detect is forced upon everyone due to bug 136502, and at least until that's fixed, this is a real bug for which wontfix isn't appropriate. As a stop-gap, this could also be duped against bug 414299 which seeks to fix the more datalossy variant of this, namely combinations of fixed and variable width sections which are munged by Delivery Format > Auto-Detect into a single, flat, all-plaintext message, loosing the original formatting distinctions on the way.

FTR: This isn't part of a fictitious "crusade" against anyone, it's a matter of free discussion, cooperation and politeness to present different viewpoints and provide answers to reasonable points and requests made, with the common goal of finding the best possible UX for our appreciated users.

Comment 10

[Magnus Melin [:mkmelin]]

> It's possible that this is considered a "feature" of Format > Auto-Detect

I'd certainly say that's the case. Don't know if i'd call it a dupe, but bug 136502 would be the fix.

Comment 11

[Ben Bucksch (:BenB)]

As I've mentioned before, the philosophy of Thunderbird is very different from e.g. MS Outlook: Senders should not force a particular layout on the recipient. Rather, the recipient choses the layout that best fits them. Font sizes are maybe the best example of that: Some like small font sizes, others have big eyes and think small font sizes just hurt their eyes, so fonts should be big. Each of them is right - for them. Plus, there are system differences, a font size that looks OK on one machine is ridiculously large on another. Thus, you read (and write) your emails in the size that you like, and the recipient does the same, but they are different. Each is comfortable with different settings. If you set the font size in the email, all this breaks.

The same argument, more or less, applies to colors and similar layout. Some girls really fancy pink, and would like all their emails to be in pink. My eyes would fall out reading those. Email is not desktop publishing.

FWIW, I've explained that to you several times already. (This is why I used the term "crusade" in another bug.)

Comment 12

[Ben Bucksch (:BenB)]

Sorry, I misread the bug (too long bug summary, so I missed the point).

Yes, it is very deliberate that we convert to plaintext whenever possible.
If you specifically select a non-standard font, we send that (after confirmation that it's really that important), but the standard message should get sent as plaintext. That's the whole point of AutoDetect.