Papercuts discussion - Composer related enhancements

Axel axel.grude at
Thu Jul 19 11:16:10 UTC 2012

*To: *"tb-planning"<tb-planning at>
*From: *"Joshua Cranmer"<pidgeot18 at>
*Sent: *Thursday, 19/07/12 03:56:39 03:56 GMT +0100 [Week 29]
*Subject:*Re: Papercuts discussion - Composer related enhancements
> On 7/18/2012 6:15 PM, Axel wrote:
> Microsoft is in the very unenviable position that backwards-compatibility is 
> absolutely vital to significant segments of its userbase; whatever their press 
> releases about what they want to do in the future say, the fact remains that it's 
> not really an option for them.
>> I would really like a similar level of "ease of use"  when creating emails that are 
>> sent between Thunderbird users, and whether we think this is a good or bad thing, 
>> we should agree that HTML is the platform, and CSS is the way to do the layout - 
>> why stick to deprecated standards?
> Outlook isn't the only problematic email client. Gmail support is also surprisingly 
> abysmal--it only supports inline CSS, nothing in a <style> tag! 

Just to bring this back on topic, the "style scoping issue" is something we should be 
aware of as lot of other mail clients strip out style tags - [I actually thought 
Outlook 2003 did the same, although your link below says otherwise] - often, <head> 
tags (and even body <style>s) are stripped out when quoting, so your quoted emails may 
loose their fidelity as original <head> tags may be stripped completely on reply.

However as a first constructive step, we could certainly support inline CSS styling of 
mail elements better, and make it easier to roll out a tag based change to the 
remainder of the document via this mechanism; it would certainly not be worse than 
using HTML attributes, and could be consolidated later towards classes once CSS in 
Mail has been more widely accepted.

So my plan would be to focus on inline styling (but with CSS) and to make this easy 
for the average user. One could probably create a prioritized list of attributes that 
should be supported; on the top would be margin, padding and display properties for 
proper layout support. Personally I would also like to see support for border-radius, 
box-shadow, text-shadow and background / gradients even if a lot of mail clients strip 
them out.

All this good stuff is supported out of the box, so I am only advocating exposing this 
to the user - let them decide whether they are going to use it or stick with "no styling".

> Here's a page which gives you an idea of who supports what: 
> <>. Executive summary: webmail clients are 
> moderately crappy (which is probably due to the fact that they really have to 
> sanitize everything), anything Outlook-based is crappy, most mobile clients 
> (excluding Windows Mobile and the Android gmail client) appear to be very good, and 
> desktop clients are in between.
Hmm, that link is interesting; if it is to be believed, then Outlook isn't all that 
bad: supporting <style> in <head> has been on my wish-list for a long time. Rule 
scoping in Email is a tricky subject, which I only realized fully since I started 
taking over smartTemplate4 development <>. It seems 
Outlook is worse when it comes to "/breaking/" our legacy tags (such as 
<blockquote>)... it's biggest problem is that it doesn't have the /bendiness /of our 
Add-On model (plus a /userContent.css/).

> Also, according to that, it seems the Outlook 2013 preview doesn't improve on 
> Outlook 2010 or Outlook 2007. So your claims of "Outlook is working on this" are 
> just not true.
well, not my claim, actually. Just a quote from M$ :)

> Desktop clients have it easy: we can just take our favorite rendering engine and 
> bolt some content security controls onto it, which means advanced CSS/HTML support 
> is very cheap. Webmail clients can't leverage that fact, because the needs of the 
> legacy web are such that the content security policy they get is way too loose. 
> Sandboxed iframes might be able to solve the problem, but I don't think they're 
> powerful enough to disable access to external resources, which makes it a bit weak. 
> Even if they are, it's not a sufficiently widely supported to be usable yet, which 
> means it's a solution that's a few years away at best.
I think webmail clients just need more intelligent parsers, if they chose to format 
emails. GMail goes the other way, by going "rich text", which is an understandable 
shortcut. However, this wouldn't really change my opinions on improving Thunderbird's 
HTML editor, as  this topic is more in the plain-text / multipart message area.
> True HTML/CSS support is not a simple task; we're spoiled in that we get this for 
> free, but a large number of email clients don't.
Yep. spoiled (for rendering) and cursed (for having to edit it) :)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the tb-planning mailing list