The infamous Mozilla core editor

Bron Gondwana brong at
Mon Mar 9 12:00:19 UTC 2015

On Mon, Mar 9, 2015, at 09:04 PM, Axel Grude wrote:
> Dear Bron,

      yeah I think that is (the start of) a good solution, one question
      is obviously when to do this? On inserting the style (and keep a
      track of UUID / or use messageid in Composer), when sending or
      (like so many email clients) on receiving?
      From the point of view of reusing the old layouts in an email
      thread (so when I reply to a reply), should it be possible to
      reuse my own layouts as a starting point?

So I see where we're diverging here a bit. You're thinking of the
composer UI as basically a word processor and the HTML email as
interoperable (to some degree) documents.

I agree on the concept of a word processor feel when composing emails,
but I believe that quoted parts of email should be (apart from some
splitting to insert inline responses) pretty much unedited.

Which then gets us to the issue of "purity" in the content. Even if
the editor is using styles internally, you can still "render" the
resulting HTML.

      Or at least we should be able to pre-define our styles (which we
      currently already have a drop-down for) in a "Style template"
      sheet. This might just be a simple HTML file with a style block in
      the <head> section and some preview examples for each style. Also
      semantic as such as <h1> would probably need a new attribute
      "styleBase" that could be used for inheriting certain parts such
      as font-family and margins. In Word processors you usually also
      have a rule of what tag follows next (e.g. if you hit enter after
      h1,h2,h3 etc you expect a <p>, <li> expects another <li>) so I
      wonder if this is something that should/could be built in as well,
      or is the current (hard-coded) way good enough.

Predictable behaviour everywhere vs fully customisable. There's a rabbit
hole for us!

      Another tool that is BADLY needed is the format painter which can
      be used to apply an ad-hoc format of one section to another.
      Finally I think it would be great if block and line level outlines
      of the currently focused elements could be made visible in order
      to see where a style definition starts and ends. Nested Font tags
      seem to be especially designed to endlessly confuse the users, as
      they add a huge amount of unpredictability when you are using the
      cursor to navigate between different parts of the text. I think
      all of this needs a big amount of conceptual work before we even
      think of implementing any of this.

This I definitely agree with.

      If you have an archive of the list, you can also see my
      suggestions in
      "Google Summer of Code 2014 - Proposal to Improve Composer UI"
      where I did some ground work on what could be done to improve
      Thunderbird's Email Editor, so I don't want to repeat a lot of
      things I have mentioned there. Particularly an email I wrote on
      07/Feb/2014 which has a ton of screenshots and ideas, if you want
         a copy of it please email me off-list... at that stage I still
         "abused" the <head> section of the email to carry my styles but
         I now think
> this is a bad idea is it often discarded.

I'm pretty sure I already have it.

I think that CSS is generally a bad idea where your content is likely to
be embedded somewhere else (webmail or even just a UI which uses HTML
itself on a desktop).

The problem with CSS can be spelled out in two words: global variables.
Styles are global variables, and even if you prefix them with something
unique, anybody consuming your content is required to validate all your
names to make sure they don't tread on not only anything in the
surrounding code, but also any other messages which are being rendered
in the same context. It's a horror.

If only there was a way to specify styles as being lexically namespaced
to a DIV - you could just wrap your email in a DIV, set styles on it,
and use them inside to your heart's content, with simple short names or
just style the existing semantic tags.


Bron Gondwana brong at

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

More information about the tb-planning mailing list