Papercuts discussion - Composer related enhancements

Axel axel.grude at
Tue Jul 17 22:01:19 UTC 2012

Hi Joe thanks for the first feedback!
*From: *"JoeS"<joesab2005 at>
*Sent: *Tuesday, 17/07/12 20:06:28 20:06 GMT Daylight Time +0100

> On 7/17/2012 7:22 AM, Axel Grude wrote:
>> /Following up: /What's the status of papercuts?
>> /
>> /
>> Since replacing the complete composer is probably to big a task for the scope of 
>> papercuts I would like to discuss a number of enhancements to enhance the current 
>> (html) composer functionality:
>>       Color Selection
>> *Bug 453853* <> -Unable to set 
>> hex value for background color in the color picker
>> I would like to rename this to (upgrade color picker to allow more color 
>> selections). Unfortunately I do not have Thunderbird bugzilla admin rights, and 
>> maybe there is another bug on this elsewhere [I searched for Tb/Compose + {color 
>> picker} and for Tb/Compose + {colors} ]?
>> A quick way would probably be if we could include rainbowpicker into the core code 
>> (obviously after asking its author)?
> Well, you can edit the hex after you pick a basic color, but a better direct 
> selection would be nice. 
Ah yes - wouldn't that effectively close *Bug 453853* 
<> ? That widget is actually new to 
me! What I would actually really prefer would be a HSE color selection with a hue 
ribbon and a square of just one hue with variations on S and B (like photoshop) as 
this is a lot more exact:

along these lines:

this would still be useful after dropping CMYK and L,a,b support (and add alpha 
instead). Still my ideal for a color selection - this one makes it way easier to 
arrive at the correct color quickly.

>>       Format Painter
>> "A copy format" function is badly needed. One problem currently is that a lot of 
>> the built in formatting tools actually insert tags (such as <big> <b> <i>) rather 
>> than styles, so a more fundamental problem must be addressed first:
> A little background here;
> Back when the editor was modified for CSS (Daniel Glazman) it was decided that CSS 
> should not be used in mail
> due to interoperability problems with Yahoo,Gmail and others.
> In fact, I think there is just an editor flag that keeps html instead of css 
I think this needs to be re-evaluated. It is true that there is still a problem with 
webmail and outlook, but the mail clients keep catching up. One thing I did experience 
though is that inline styles are more reliable than <style> rules as they are often 
dropped because of scoping issues. I would be brave and walk forward (with the 20 
million users) and rather risk loss of fidelity for standards compliance. If you were 
going for major compatibility you (e.g. outlook fidelity) you would have to back pedal 
so far... I personally for HTML email CSS is the future (as it is for HTML5).

*If Thunderbird can lead by example, then this is the one area where I would like it 
to be brave: _

  * *_be CSS3 compliant_; *
  * *_encourage use of CSS_*;

it is not that hard. Just use a proper browser engine, there are plenty choices out 
there. Of course, composing is an entirely different kettle of fish (that's the hard 
bit). :)

>>       CSS Property Editor
>> Image > Advanced property editor Enhancements
>> I wonder if this could be generalized to apply CSS properties to all sorts of tags 
>> (not just img). Ideally I would like the possiblity to select a paragraph (which we 
>> should be able to turn from a <br>....section...<br>  into a <p>..</p> pair, and 
>> then select something like a "layout" option.
>> As a starting point we could use the "Inline Style" tab of the "Advanced Property 
>> Editor" and add a dropdown to the Attribute field. The tricky bit is to select the 
>> correct tag (probably the nearest enclosing tag) and to visually represent this  in 
>> the Editor window.
>> <screen snipped>
>> For this particular purpose (increasing style expressiveness in the WYSIWIG editor, 
>> via inline styles) I would chose to remove the tabs "HTML attributes" and 
>> "Javascript Events" and focus on css styles alone. ONe thing that Thunderbird does 
>> very badly at the moment is to expose the current expressive power it has via CSS3 
>> to the ordinary user. Most other rich editors have some sort of a "x-ray" mode 
>> where special (meta-)characters such as tabs, line feeds, section breaks etc. are 
>> displayed; what I would like to have is something generic that shows enclosing tag 
>> pairs (or an outline around html constructs) so that they can easily be spotted and 
>> manipulated. This is actually the hard part of this enhancement, but I think 
>> discussion of this would be fruitful.
>> Rationale:
>> Currently, the only way to create an email with  "clean markup" is by using 
>> extensions that expose HTML source, which works for me, but not most ordinary 
>> users. As /first step/ we could make it easier to add inline styling via the method 
>> above; this will make it easier for users to discover layout features of Composer. 
>> As a /second/ /step/ we might then later encapsulate the interface so it can be 
>> used by users who do not know CSS.
>> I would love to be involved in such composer improvements, but I would also like to 
>> assess as to what other ideas or maybe code fragments are already out there. 
>> Therefore I am currently holding off on filing new (or re-appropriating existing) 
>> bugs on this and adding them to the papercuts list, until I have a feel for what 
>> the opinions on the list on this are.
> I have been looking for better css composition for years.
> I think the dropdown idea is great. (auto-complete would be even better)
Yes I thought of adding some template strings for the value textbox, like
box-shadow - [h-shadow] [v-shadow] [blur] [spread] [color] [inset]
but that could all as well be added in version2.

A "default values memory effect" would be good though. There is always the issue 
(pain) with copying / pasting styles when you are dealing with inline styling. Of 
course, using CSS classes would be the real way forward here, but they are even less 
supported by other mail clients than CSS.

I think we will also need some sort of level inspection UI (ala FX inspector; showing 
a breadcrumb trail of enclosing HTML tags) in order for this to be efficient and 
easily understandable to the average user. I was even thinking maybe a HTML tree in a 
Composer sidebar might be a nice short-term fix.

Somehow the paradigm has to shift away from "text-selection" to "tag pairs". Do you 
think there is a way to take the ordinary users (who don't speak HTML) there?

> BTW, I think the advanced editor still drops margin-left/margin-right, if you make 
> any other changes there. 
eeek. What is quite amazing to me in current Composer (read: Netscape 4.0 - yes it 
didn't really change very much since then, I have been watching!) is that there is so 
much functionality built around formatting images, and so little around the lowly <p> 
tag. Is using <p> instead of <br> a [un]surmountable challenge?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: iejdhcaa.png
Type: image/png
Size: 135237 bytes
Desc: not available
URL: <>

More information about the tb-planning mailing list