The infamous Mozilla core editor

Axel Grude axel.grude at gmail.com
Mon Mar 9 10:04:58 UTC 2015


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?

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.

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.

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.


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

> *Subject:* Re: The infamous Mozilla core editor
> *To:* axel.grude at gmail.com, tb-planning at mozilla.org
> *From: *Bron Gondwana
> *Sent: *Sunday, 08/03/2015 23:06:37 23:06 GMT ST +0000 [Week 10]
> The "obvious" solution is to prepend a UUID to every class within a message, in the 
> same way that MIME part separators are generated.
> The downside is that everybody[tm] is not doing to trust that your classes aren't 
> going to leak outside your message, so they will defang your classes by adding more 
> to them as well.  That's what we do at FastMail to stop classes leaking.  It's a mess.
> The big advantage of just putting the font elements on everything is that it's 
> simple, and it works everywhere.  Sadly, that's sometimes better than perfect.
> Bron.
> On Sat, Mar 7, 2015, at 11:17 PM, Axel Grude wrote:
>> Dear Bron,
>> Of course I know these features all work via using <font> tags and other inline 
>> code, but the problem is if you want to define style (e.g. blue large headers) this 
>> is best implemented via CSS classes. One of the problems with CSS classes ist that 
>> they are in the global namespace which means that they may affect quotes material 
>> as well as follow on emails.
>> One of my users has defined his reply texts to be in blue, however this also now 
>> affects my replies to him to also show up in blue. SO this is not a trivial request.
>> on the other hand using font tags is not very efficient as you need to replicate 
>> your styles on each individual element / passage. The real trick is come up with a 
>> style / template strategy that is both robust (does not change its properties when 
>> quoted in another email) and easy to ise (such as predefined paragraph styles).
>> As regards building better frontend for CSS this is a relatively easy task that I 
>> want to look into in the future; however the "persistent paragraph styles surviving 
>> the global namespace" has to be solved first. Ideally the CSS should be scoped to 
>> one quote-level only (also, the bug about the encoded child selector ">" within 
>> style tags is still open).
>> regards,
>>   Axel
>> -- 
>> *Axel Grude <mailto:axel.grude at gmail.com>*
>> Software Developer
>> Thunderbird Add-ons Developer (QuickFolders, quickFilters, QuickPasswords, Zombie 
>> Keys, SmartTemplate4)
>> AMO Editor Get Thunderbird!
>>> *Subject:* Re: The infamous Mozilla core editor
>>> *To:* tb-planning at mozilla.org <mailto:tb-planning at mozilla.org>
>>> *From: *Bron Gondwana
>>> *Sent: *Saturday, 07/03/2015 04:25:29 04:25 GMT ST +0000 [Week 9]
>>> On Fri, Mar 6, 2015, at 07:24 PM, Aceman wrote:
>>> > Is this actually a full featured editor with equivalent features to the code 
>>> editor? At 11KB in size of JS, it looks to me it mainly allows text formatting.
>>> > But what about images, tables, lists, indents?
>>>
>>>  *
>>>     _Lists and indents work fine._
>>>  *
>>>     Image inclusion works
>>>
>>> You can even
>>>
>>>  *
>>>     create indented
>>>     1.
>>>         lists
>>>     2.
>>>         with numbers
>>>     3.
>>>         and stuff
>>>
>>> I'm not so sure about tables though...
>>> Certainly changing fonts is/definitely/ supported.
>>> > (Am sure somebody would like CSS insertion, but I am not sure that is in the 
>>> base TB editor now).
>>> I would have to ask Neil about that.  It's pretty good about taking existing HTML 
>>> and keeping it working in quoted messages too.
>>> --
>>> Bron Gondwana
>>> brong at fastmail.fm <mailto:brong at fastmail.fm>
>>> _______________________________________________
>>> tb-planning mailing list
>>> tb-planning at mozilla.org  <mailto:tb-planning at mozilla.org>  https://mail.mozilla.org/listinfo/tb-planning
>>
>> Email had 1 attachment:
>>
>>   * |thunderbird_blog2.png|
>>       1k (image/png)
>>
> --
> Bron Gondwana
> brong at fastmail.fm


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20150309/748c605c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: thunderbird_blog2.png
Type: image/png
Size: 846 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20150309/748c605c/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 846 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20150309/748c605c/attachment-0001.png>


More information about the tb-planning mailing list