Google Summer of Code 2014 - Proposal to Improve Composer UI

Axel Grude (Axel) axel.grude at
Fri Feb 7 21:06:16 UTC 2014


I think some UI work on composer would be great. Maybe a Ribbon-Style / extended 
Formatting Bar interface, plus fixing the bugs around [Enter], so that writing 
paragraphs would be more consistent.

So I am following up here to ask if this would be a good project to mentor. If I had 
time I would write this as an Addon, but sadly...


To make it easier to compose great looking emails and encourage users to use semantic 
tags for formatting.

  User Definable Styles

in particular I like these widgets as they are very easy to use (1 click) and show 
that styles can be expandable:

"normal" this is actually the style that is assigned to<p> and adds a <p> mark if the 
text is pure body. [Enter] should split the paragraph into 2. I would like to design 
an easy to use interface for defining the styles which would inject the css styles 
(either on class level or inline on send). The implementation should allow for some 
downwards compatibility but not too much (since we are using semantic styles such as p 
h1 h2 etc style deterioration on lesser mail clients would be something expected 
anyway. I would aim for being at least "Broad strokes" compatible with capable HTML 
clients such as outlook, so that largely font sizes, colors, and very important 
formats in quoted mails stay largely persistent. (This is not easy)

Each style should have a "follow on" rule, e.g. <h1> => <p>, <p> => <p>, etc. and a 
broad selection of typographical attributes, e.g.

Font specific

  * font family
  * font size
  * font weight
  * font decoration / formatting
  * color
  * background color
  * text shadow

Block specific

  * alignment
  * line distance
  * Spacing before & after (padding)
  * indentation
  * line width
  * border styles
  * box-shadow
  * gradients

Inline / Character Styles

  * these would be injected via <span> and would allow stuff like the html entities in
    this mail (I am using <tt> blocks which are defined as inline-block). the hardest
    thing with these is to come up with a non-technical description (or does one ues
    CSS terms). I think the benefit is pretty much visible instantly once you come up
    with some examples.

Most rich text editing users are familiar with the concept of user defined styles. One 
thing to solve would how to persist the style definitions, would the be only stored in 
the email and / or globally. It should also be extendable in the form of a style 
template so that a bunch of style definitions can be stored together under a common 
name. I wouldn't attempt to implement the template management as part of this project 
but make it extendable so that the overarching template structure already exists.

  A panel for table styles the moment the inclusion of tables in Composer is also somewhat lackluster (if 
you ever try to paste an Excel formatted table into a html mail you can see the sorry 
effects of this). So at least we should provide a tool to quickly format the table 
with a colored style and a heading.

As you can see there is support for odd and even rows (also columns) and especially 
the header row and first column, I think this pretty basic stuff and should be 
implementable via nth-row etc.

  List styles

should they be separate?

  Style Persistence

There are 3 levels of style persistance: In the mail client / profile, in the 
individual email and after sending on the recipient's system. With persistence I mean 
the answer to the question "where and how are these styles stored".

On the program level, of course we can (and probably should) persist the styles in the 
config database, so that they can be used again and again (Similar to Word's "Default 
template"). Then these styles could be copied into the composed emails using CSS 
classes, e.g. by injection into the <head> section. Of course the epxectation of the 
users is that if I modify my style while composing the email, it will automatically be 
updated (and stored) in my composed email. Likewise, if I re-open the email from my 
drafts folder (or via "Edit as New") i would expect my style selections to reflect 
these styles (provided I have created the mail with the same system = current 
Thunderbird); if I have chosen to make my headings blue, I want them to be blue again 
when I continue editing.

The next question is whether changes to for example the <p> style will then 
atuomatically affect all following emails, or how to create an easy to understand 

There should be an option to persist these styles down to the inline level for 
"lesser" mail clients. We need to have some clever way of optionally pushing down 
styles from the class level (maybe on send or save) but we should also be able to 
change the style on class level later. This means, in this mode, that inline styles 
must somehow be marked for deletion (or ignored) while composing.

I think using inline styles this is the biggest challenge for actually implementing a 
proper styling system, therefore I would be happy if we could implement CSS class (or 
element level) styling first so at least non mail-mangling clients display the html 
content in "Hi-Fidelity".

  Clipboard and Format Painter

a more helpful panel when dealing with pasting and can support things like

  * Paste
  * Paste without Formatting
  * Paste as Quote
  * Paste as Code Snippet  (if we can select a quickStyle when pasting this will be
    very handy for developers and other specialists)
  * Paste as <User defined Style 1>

Format Painter: can be used to transfer<span> or <block> level style depending on what 
is selected.

To make it easier for the user to understand the style application I would suggest a 
"x-ray" mode which shows paragraph and spanned outlines of the currently active element.

Also an Fx inspector style breadcrumb panel might be helpful:

interestingly in a standard email the nesting would typically not be very deep (maybe 
3 to 5 levels), clicking trhe container would tightly outline it on screen - also an 
advantage when troubleshooting <spanned> font attributes. do you think this might be a 
helpful tool for formatting HTML mail?


Well that's the one I am worried about. Might all be a bit much for a 3 months project...

PS: Ludovic, I am just watching the State_of_Thunderbird video from FOSDEM 
you just uploaded - good stuff. If you want somebody who is excited about UI, just 
look my way. I definitely think we should aim for a slice of the OUtlook market and I 
think Improving UI is the way to go. We HTML heads know that we can create awesome 
looking emails (using Source(HTML) view via plugins), but I want to make this 
accessible to all users.

PPS: For those of you who read this email in HTML, you might notice the relatively 
pleasant spacings between paragraphs, there were achieved by simply highlighting the 
text and choosing the Paragraph style. What is problematic that the default style is 
"Body text" which forces an over-abundant use of the <br> tag which is bad for layout. 
And I had to remove a bunch of them... I feel this is something Composer should do 
automatically -

I am hoping to address the issue soon by fixing the long-standing [Bug 330891] 
<>. The expectation in HTML mode 
(to our non HTML understanding users, more like Rich text, layout mode), the 
expectation is that [Enter] starts a new paragraph (see numerous Rich Text editors for 
this behavior). It think this (defaulting to <p> on Enter) would be a lot friendlier 
to most users. Hope it is not too difficult...

*Axel <mailto:axel.grude at>*
Software Developer
Thunderbird Add-ons Developer (QuickFolders, quickFilters, QuickPasswords, Zombie 
Keys, SmartTemplate4)
AMO Editor

*Subject:* Google Summer of Code 2014 *To:* tb-planning at - tb-planning 
[tb-planning at]
*From:* Patrick Cloke <clokep at> - Patrick Cloke clokep at 
<mailto:clokep at>
*Sent: *Friday, 07/02/2014 16:26:33 16:26 GMT Standard Time {GMT ST} +0000 [Week 6]
*Subject:* Re: Google Summer of Code 2014
> Not sure if people say Florian's post about GSoC 2014 [1], but we should put up some 
> ideas for ideas on the brainstorming page [2]. Thunderbird had a couple of students 
> last year (mconley had someone working on the address book stuff, I had a student 
> working on Yahoo! chat protocol support).
> So if there are people with interesting projects (i.e. 6 week projects that won't be 
> blocking the path ahead for Thunderbird) or if someone is willing to mentor, not 
> would be a great time to step forward! (I'm sure if someone is willing to mentor, 
> but doesn't have a specific project idea in mind...something will be found.)
> I think this is a good opportunity for us to try to get:
> 1. Some bugs fixed or new features added.
> 2. Some new blood into the community.
> Thanks,
> Patrick
> [1]
> [2]
> _______________________________________________
> tb-planning mailing list
> tb-planning at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gihdbceh.png
Type: image/png
Size: 8807 bytes
Desc: not available
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fcidccdj.png
Type: image/png
Size: 8155 bytes
Desc: not available
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fbgdabhd.png
Type: image/png
Size: 19507 bytes
Desc: not available
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ffiiddie.png
Type: image/png
Size: 4962 bytes
Desc: not available
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: efegfchg.png
Type: image/png
Size: 11489 bytes
Desc: not available
URL: <>

More information about the tb-planning mailing list