The infamous Mozilla core editor

Axel Grude axel.grude at gmail.com
Mon Mar 9 12:22:22 UTC 2015


> *Subject:* Re: The infamous Mozilla core editor
> *To:* axel.grude at gmail.com, tb-planning at mozilla.org
> *From: *Bron Gondwana
> *Sent: *Monday, 09/03/2015 12:00:19 12:00 GMT ST +0000 [Week 10]
> 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.
definitely, that is exactly one of the reasons I was lamenting the global CSS 
namespace. You should have full control on your own level without affecting quoted 
material.
> 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.
Again, I agree 100% . Which brings up whether we should implement a "compatibility 
mode" that copies styles in-line when we hit send (for those mail clients that ignore 
CSS class definitions)

>> 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!
Yep. I am volunteering for building a UI, that's my speciality. Whatever it will be, 
there will be modeless windows involved so people can try out styles and move the 
layout definition around while trying.
>> 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.
Unfortunatele that is also one of the most difficult things to implement as you always 
have to make decisions which of the "resulting styles" shall actually be copied 
(pulled from inner span / font level, paragraph, cell, row levels etc.) - lot's of 
work in this one. but also one of the most rewarding areas from the UI experience POV.
>> 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.
well there is the child selector (>) so maybe this could be used to somewhat alleviate 
this. But another problem is that if you quote and your style definitions happen to be 
in an area you "snip out" you have the added problem of potentially losing your 
styles. So Composer needs to keep track of these and move them around.

> 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.
Do we need a new

"inherit = none;"

rule? Isn't the direct child selector ">" sufficient?

Axel


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20150309/ef1746c6/attachment.html>


More information about the tb-planning mailing list