Closed Bug 471168 Opened 17 years ago Closed 17 years ago

Webmail clients ignore text color specified on the body element

Categories

(MailNews Core :: Composition, defect)

Product:
MailNews Core
Component:
Composition
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: mister.wardrop, Unassigned)

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5 (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1b3pre) Gecko/20081204 Thunderbird/3.0b1 NOTE: I have specified that this is a major bug, because I think it is. Such a bug really makes users uncertain if they really want to trust Thunderbird with more critical functionality. My grandfather said he had a problem sending emails with coloured text to others; they looked fine for him, but for his recipients, it just appears as plain black text. This was occurring in Thunderbird 2.0.0.18 (and all previous, and all later). I only installed the Thunderbird 3.0 beta 1 on his computer to test if the bug had already been fixed.... it hasn't. When you select a colour in Thunderbird, say red (#ff0000), Thunderbird generates the following HTML: <div bgcolor="#ffffff" text="#3366ff"><font face="Comic Sans MS">TEST TEXT</font> </div> This is not valid html, nor does it render in Firefox, or Internet Explorer. It may render in other browsers for all I know. Gmail, and other compliant composers, generate: <font color="#ff0000">Test</font> Which does render properly in the browsers tested, and, indeed, within Thunderbird itself (fortunately; for it uses gecko - or so I think). Reproducible: Always Steps to Reproduce: 1.Change text colour 2.Send 3.Look at the message source Actual Results: Invalid HTML is produced. Expected Results: Generated HTML which correctly renders the text.
Could you provide a little more detail about how to wind up with that HTML? For example, when I (in a trunk build): 1. Compose an HTML message (by shift+clicking Write, though by default that would just be by clicking Write) 2. Type "Whatever" in the body 3. Click, hold, drag to select the whole word 4. Click the black part of the black/white color chooser on the formatting toolbar 5. Click the red block, then click OK 6. Send the email to myself I get "<font color="#ff0000">Whatever</font>" (and, to nobody's surprise, don't get any <font face="Comic Sans MS"> at all).
Hello, sorry if my information was a little sparse. After playing around a little more, I discovered the cause of the bug. My grandfather has selected a default font colour of blue (#3366ff), which caused the problems (but I believe it is still a bug in thunderbird). If you select your colour manually, it works fine, as in this method: Method 1: Process: 1. Click Write 2. Type "Test" in the email content 3. Click, hold and drag to select "Test" 4. Use the toolbar immediately above the text field to change font colour to red. 5. Send email to me (from my grandfather's computer) Doing so yields the following HTML code: <body bgcolor="#ffffff" text="#3366ff"> <font color="#3366ff" face="Comic Sans MS">Test</font> </body> But if you do not, and specify a DEFAULT colour in which to send emails (as my grandfather has), it generates this code: Method 2: Process: 1. Select default colour for composition as blue (#3366ff) [ Tools -> Options; Composition#HTML: Font->Text Color = #3366ff ] 2. Click Write 3. Type "Test" in the email content (which appears to be blue) 4. Send email to me (from my grandfather's computer) Doing so yields the following HTML code: <body bgcolor="#ffffff" text="#3366ff"> <font face="Comic Sans MS">Test</font> </body> I think what needs to be done is to specify the correct tag in the body tag for specifying the base text colour in the document: <body style='color: #3366ff;'> The text attribute in the body tag seems to have been deprecated < http://www.w3schools.com/tags/tag_body.asp >. Thank you for your prompt response, Matthew
You'll want to decide what it is you want, because you're now up to three separate incompatible things in this bug: "standards compliant", "default color comes through in Gmail" and "don't worry people by providing things that aren't seen by all recipients." If your grandfather mistrusts Tb because it lets him set a default color that other people using email client programs like Outlook Express or Evolution or Windows Live Mail or Mail.app see but you don't see in Gmail, then he'd really be worried by the way I have Tb set to only display plain text, since I wouldn't see his color or his font choice. The only way to fix that issue is to completely remove support for HTML, and only send plain text, which we aren't going to do. So, sorry, he'll have to live with the fact that what he sends may or may not be what someone else sees. That the body's text attribute was deprecated in HTML 4.01 does not mean it's invalid. Deprecated just means "we think there's a better way, and a future specification may drop it entirely" (as XHTML did). It does not mean that browsers will suddenly drop support for it despite it having been used in millions of web pages, nor have they: when you're talking about what browsers do and do not support, you're talking about what they do with what Gmail has mangled the HTML into, not what they would do with the original HTML. No browser has dropped support for <body text="">, and no browser will until HTML 4 is gone from the face of the earth, so we've got at least thirty or forty years before we have to worry about that. Then there's the Gmail issue. Webmail programs strip off the <body> as one part of their mangling of an HTML mail into something they can display safely, along with stripping script and style that might leak out of the message and attack their interface. If you were talking about Yahoo or whatever Hotmail is called this month, you'd be out of luck for anything on the <body>, since they strip it completely and unconditionally, but as is typical for Google ("Gmail, and other compliant composers", heh) they play fast and loose with the HTML, and although they strip <body text="red">, in the case of <body text="red" style="color:red"> they will wrap the message in a <div style="color:red" text="red"> (no, I have no idea why they think it reasonable to copy other attributes which do not belong on a div, and which they silently drop otherwise, only when there is a style attribute), so fixing this for Gmail only would "just" require rewriting the code that sets the default color and the code that backs Format - Page Colors and Background - Advanced Edit, which currently mirrors color changes that you make on the Inline Style tab back into the default colors (and into the text attribute), to also work in reverse, and mirror changes you make to text/link/vlink/alink into inline styles as well. Then it would work with Gmail, right up until they find a security issue with copying style off the body onto a wrapper div, or decide that having a wrapper div causes some other problem that's worse than the benefit of doing it, and drop it. Fixing it for Yahoo and Hotmail would require Thunderbird to stick a wrapper div around the whole body content, which would let us find the problem with a wrapper div instead of letting them find it, but because that would be likely to screw *something* up, and it would then be our fault for screwing something else up by trying to work around a bug in the way webmail programs work, I really doubt we want to do that. Or, as you say, we could do it the way other working (not "compliant") composers do. You can't say that we should do it like Gmail does, because it doesn't have this feature. You can set the color for individual text, just like you can with Thunderbird's toolbar, and just like Thunderbird's toolbar, it's very easy to wind up losing that color, by using the arrow keys to navigate or by inserting a numbered list or other block-level element. The only other composers I could find that actually offer a default color, not just "a color until I decide to change back on you", are Windows things like OE or Windows Live Mail wrapping the MSHTML editor widget, which apparently allows setting a default color which then fills the HTML with tons and tons of separate things like <font color="red"><br></font>, the sort of thing which has caused people to make fun of it for years. We *could* do that, but the odds that anyone will actually want to completely rewrite the editor widget to make it produce much uglier, more bloated, less modern, less standards-compliant HTML are pretty tiny.
Component: Message Compose Window → Composition
Product: Thunderbird → MailNews Core
QA Contact: message-compose → composition
Summary: Composer generates invalid HTML for text colour → Webmail clients ignore text color specified on the body element
Version: unspecified → Trunk
Firstly, my apologies for seeming so demanding, and for not looking more carefully into the issue. You are quite right about gmail, and I accede that I think it best not add all of these custom hacks to make it work in all of the different email clients. However, the issue is experienced beyond merely gmail; as you have suggested, since every client/service seems to strip the HTML out differently... perhaps, then, the best idea is to apply the default text colour into an encapsulating <font> tag, which would render correctly on all systems? [My aunt, who first divulged the problem to my grandfather, uses an entirely different system: tpg(Australian ISP)/outlook express.]
No worries, I just like to hear my own keyboard clack. I'm unable to reproduce your aunt's problem: default color from Thunderbird to Outlook Express works just fine for me. She could be reading in plain text only, or some of the settings that are shared between Internet Explorer and OE could be giving her different colors (for instance, in IE "Tools - Internet Options - Accessibility - Ignore colors specified on web pages" will then ignore colors in OE), or her ISP thinks mail should be black on white and strips out color, or... I'd be happy to fly over and see :) But you can't wrap a <font> around the whole thing, because font is an inline-level element, and thus can't contain block-level elements like lists, or divs or paragraphs, which is why MSHTML uses a billion <font>s, to avoid having to count on unspecified error recovery: the HTML spec says nothing about what to do with <font color="red">red<p>dunno</p></font>, so whether that's <font color="red">red</font><p>dunno</p><font></font> or <font color="red">red</font><p><font color="red">dunno</font></p><font></font> is completely up to the imagination of the author of any particular HTML renderer. The only two valid ways to specify a font color for every bit of text without using CSS are either to nest a font element inside every single block-level element in the whole document, or, use the text attribute on the body element.
Hmmm... Well... I have set my grandfather's default font colour as black, so that what he sends looks like what is received. Although it is possible to add this mess of <font> tags, I understand, from a coding point of view (being a programmer myself; for somewhat smaller projects), that it is VERY ungraceful. I suppose this has to just be sidelined; and worked around. Thank you for your prompt and detailed comments. Matthew
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.