Papercuts discussion - Composer related enhancements
joesab2005 at gmail.com
Wed Jul 18 23:34:12 UTC 2012
+1 on all of Axel's comment below.
BTW if you are using google groups, or viewing in plaintext, you can't
really get a handle on what Axel is talking about.
bug 671320 <https://bugzilla.mozilla.org/attachment.cgi?id=545685> has a
nice demo as well.
You might ask yourself why folks try to send these kinds of mail.
For me, it is a matter of expressionism, and an outlet for
creativity.(such as it is)
I have no idea about the user base for incredimail, but I imagine they
use it for the same reasons.
(It generates about as much crap as using msword as an html editor)
We could do much better, given an enhanced editor.
On 7/18/2012 18:15, Axel wrote:
> Hello Kent,
> *Axel Grude*
> Software Developer
> Thunderbird Add-ons Developer (QuickFolders, quickFilters,
> QuickPasswords, Zombie Keys, SmartTemplate4)
> AMO Editor
> *To: *"tb-planning"<tb-planning at mozilla.org>
> *From: *"Kent James"<kent at caspia.com>
> *Sent: *Mittwoch, 18/07/12 18:30:26 18:30 GMT +0100 [Week 29]
> *Subject:*Re: Papercuts discussion - Composer related enhancements
>> On 7/17/2012 3:01 PM, Axel wrote:
>>> 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). :)
>> This is an issue where lack of clarity of our core product
>> positioning makes it hard to choose.
>> I doubt if many of our users would want us to be "lead by example"
>> and sacrifice "major compatibility (with) ... outlook" in the process.
> I don't think that this "sacrifice compatibility" is something we need
> to actively /drive.
> In fact this process of eroding "major compatibility" is already an
> ongoing one, but actively and instigated "from the other side". Since
> Microsoft has decided to drop Triton and use Word as HTML rendering
> engine in Outlook 2007; please have a read at this:
>> *Q: "Are there any plans to add support for the other HTML and CSS
>> standards to Word’s engine?"*
>> *A:* "The Word team is continually examining HTML and CSS support
>> based on customer feedback."
> so here is the deal and my thought process behind this - if we add
> simplified editing support for CSS3 features like gradients,
> border-radius and box-shadow, this won't "break compatibility" with
> word, but you get *better usability and high fidelity *within
> *Thunderbird corporate environments and with private Thunderbird
> users*; for the web based email clients it wouldn't be hard to
> gradually add support for these features (they would just have to be a
> bit more cautious "ripping out" "undesired" layout) [- also, have a
> look at what they make of emails authored with Outlook.]
> At the same time, Word as text editor integrated within Outlook is
> doubtless "A Neat Thing" which enables outlook users to very simply
> generate highly complex layouts that can be truthfully transmitted
> within the boundaries of the platform (basically, Exchange networks).
> I would really like a similar level of "ease of use" when creating
> emails that are sent between Thunderbird users, and whether we think
> this is a good or bad thing, we should agree that HTML is the
> platform, and CSS is the way to do the layout - why stick to
> deprecated standards?
> So I ask, should we really put in word-specific artifacts in order to
> render more truthfully on Microsoft's current Word/HTML engine (and
> remember, there web pages that are authored with Word, and they had
> some of the most atrocious, standards-defying HTML out there, creating
> the impression that standards compliant /browsers /were "broken", when
> in fact, the /standards/ were) Sound familiar?
> In my opinion, if the layout of a Thunderbird Email is impacted when
> displayed on the outlook engine, because it doesn't know all the CSS
> (yet) should we really spend precious development cycles on rectifying
> this situation? Although Microsoft themselves have pledged to "examine
> /(and one would hope, improve)/ HTML and CSS support based on customer
> feedback"; don't forget there are other mail clients out there (Lotus
> Notes?) and CSS is an open / documented standard. Not so sure about
> the rules of "Word"-HTML rendering... not even sure if I would want to
> know, as they seem to be in constant flux.
> Don't get me wrong I am not bashing Microsoft, and their E-Mail
> /Composition /Module (read: Word2007+) runs rings around our Composer
> at the moment, but the /markup /that it creates (at least when in
> Word-HTML mode) and their /Rendering Engine/ surely doesn't.
> To give you an example, I had a user complaining about quote levels
> being pushed in on both sides of the email to the point were only a
> few words were visible. This is because outlook dropped proper support
> for the<blockquote> tag (or least you cannot configure Word out of the
> box to make this less than 12 em or so). The question is, should
> Thunderbird consequently drop (or replace) the <blockquote> tag?
> Obviously, that would be a workaround (although it wouldn't fix any
> emails that have already been written), but I would say the time spent
> to develop this would be better spent by making it easier to create a
> layout in Composer, and leave the fixing of this particular annoyance
> to the owners of the defunct Software (Outlook).
> Sure, we can stay within the confines of HTML attributes, like we did
> in the nineties, and like we did in the last decade; but I think this
> approach is short-sighted, when we have a pure-bred HTML client at our
> hands which is capable of displaying HTML5 and highly modernized web
> sites (yes, we do support opacity, yes, we do support transitions!).
> Once you start editing the HTML source in Thunderbird's composer, the
> possibilities are ridiculous. In a good way.
> My point is, let's harness that power and show people what is possible
> (while sticking to the HTML standards); the trick is to build a good
> user interface to make that power easy to use; I think this will take
> some vision and some braveness, but I do not think for a minute that
> it will alienate any Outlooks users (I am one myself, in my bread job,
> so I know what I am talking about); but rather attract them. If you're
> stuck with outlook in you job, then "Hey look what you can do with
> that, in your private email!"
> Just to close, there is one more example where Composer is actually
> better than Outlook: you can drag images from the file system in-line
> and very quickly create a narrative with screenshots. This is
> something which at least outlook2007 (and Winword) still hasn't
> managed. You still have to through the painful insert > object or
> insert > file menus for this.
> I wish we had 5 usability features like that one, which would make
> life easier for composing emails; this is where I would set the focus.
> Examples would be
> * simple adding of shadows / borders to boxes / images / paragraphs
> * automatic paragraph refactoring (get away from <BR><BR><BR> for
> formatting, by replacing them intelligently)
> * creation of Table of Contents (with anchor jumps within the email)
> * easier color choices (remember last color without opening a
> dialog, like in Word)
> * format painter
> * "Make all paragraphs / headers / lists look like this" - if not
> with CSS classes, then by copying CSS inline styles
> * deprecate font and introduce @fontface support (not sure if that
> one's already there)
> So I would like people to pick a few out of these before they even
> think about making Composer's HTML output "more palatable for outlook
> (WinWord)". Hope we can discuss this one in more detail on the
> Thunderbird Summit.
> PS: Magnus I have cc'ed you, but your email address shows up "red"? is
> it legit?
> PPS: Vincent - the users do not necessarily have to "Know" CSS to be
> able to use it. We just build an intuitive interface that encapsulates
> it, and they can use it. People also do not know about the internal
> XML structure of modern word documents, yet they manage to layout
> their images and paint their tables. I still think this discussion is
> all about the UI, not about the technology.
> tb-planning mailing list
> tb-planning at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tb-planning