<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=windows-1252">
</head>
<body smarttemplateinserted="true" bgcolor="#FFFFFF" text="#000000">
<div id="smartTemplate4-template"><img style="margin-top: 1em;
float: right; box-shadow: 1px 1px 2px rgba(20, 20, 20, 0.4);"
moz-do-not-send="false" class="myLogo"
src="cid:part1.E41B7040.DF5A9509@gmail.com" alt="Get
Thunderbird!" height="15" width="94">
</div>
<div id="smartTemplate4-quoteHeader">
<style type="text/css" scoped="">
#newHeaderAG1 b { font-weight:bold; color: #990033; min-width: 4.5em; max-width:none; display:inline-block;}
</style>
<blockquote type="cite" style="margin-bottom: -20px !important;
padding-bottom:20px !important;">
<div id="newHeaderAG1" style="font-size: x-small; padding:1em;
background-color:rgba(220,220,240,0.4); border-radius:3px;"> <b>Subject:</b>Re:
What happened to hiring an architect?<br>
<b>From:</b>Matt Harris <a
href="mailto:unicorn.consulting@gmail.com"><unicorn.consulting@gmail.com></a><br>
<b>To:</b>Tb-planning <br>
<b>Sent: </b>Tuesday, 20/12/2016 08:38:55 08:38 GMT ST +0000
[Week 51]<br>
</div>
</blockquote>
</div>
<blockquote class=" cite"
id="mid_16b876eb_2a9f_c410_05be_c4816de0ff63_gmail_com"
cite="mid:16b876eb-2a9f-c410-05be-c4816de0ff63@gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div class="moz-cite-prefix">On 17-Dec-16 1:54 AM, Disaster Master
wrote:<br>
</div>
<blockquote class=" cite"
id="mid_f2273f62_0389_ab8e_7b21_2990cb9aee97_gmail_com"
type="cite"
cite="mid:f2273f62-0389-ab8e-7b21-2990cb9aee97@gmail.com">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<br>
Again, if certain parts become too great of a risk (ie, Gecko
security issues too difficult to fix), reduce HTML rendering
capability as is necessary to minimize/eliminate the risks.<br>
</blockquote>
<i>I think this is really a bit of a bad idea from a champion of
user choice in user interface and customization. You want the
program flexible in the area that of customization that
interests you, but in the area of HTML rendering you want to
"lock it down".<br>
<br>
I am looking forward to a time when we can see the full impact
of HTML5 in email. Thunderbird currently supports much more of
it that some other providers and therefore it is not getting the
traction that it deserves. </i></blockquote>
<p>In order to make that more obvious, the Composer must make the
HTML5 feature set more accessable. As a minimum this would mean
including an HTML source editor, possibly also a separate style
editor.</p>
<p>Only being able to display HTML5 is hardly worth discovering to
the average user without being able to craft such features easily.
I know this is an old chestnut but if we could have an HTML
Addon-Editor as a starting point (or a HTML toolbar that is as
easy to use as a Word Ribbon for advanced layout such as
text-shadow, building and storing CSS classes in order to have
re-usable layout templates, etc.) then Thunderbird's superiority
would actually become apparent.<br>
</p>
<blockquote class=" cite"
id="mid_16b876eb_2a9f_c410_05be_c4816de0ff63_gmail_com"
cite="mid:16b876eb-2a9f-c410-05be-c4816de0ff63@gmail.com"
type="cite"><i>But I am dead against locking things down to a
small subset as Gmail has done, holding up non text email up as
a result. All in the name of security. </i></blockquote>
<p>Gmail to me is a web-mail client and doesn't really compete (just
yet) as it's got different paradigms. I must say that I find it
handy for the mobile platform when I am away from my desktop and
have been known to answer the odd urgent email from there. On the
browser I usually find it a terrible experience, because of the
bad navigation. There are friends who have embraced their tabbed
interface (which forces some pre-made categories of emails) but
there is always a problem with web interfaces that you have to
follow their paradigm and hope it is still around in 2 years time.
<br>
</p>
<p>Stability and Predictability of UX and paradigms is actually one
of the huge advantages of Addons, as they usually stick to their
initial idea and may expand it, but don't capaciously introduce
huge changes into the workflow.<br>
</p>
<blockquote class=" cite"
id="mid_16b876eb_2a9f_c410_05be_c4816de0ff63_gmail_com"
cite="mid:16b876eb-2a9f-c410-05be-c4816de0ff63@gmail.com"
type="cite"><i>Not supporting scripting languages I accept and
understand, as I support no Flash. But Thunderbird must support
the HTML specification as it stands now and into the future.<br>
</i></blockquote>
<p>I agree - HTML (5) is the bedrock standard that Thunderbird
should stick to. <br>
</p>
<p>With things like the flex box model and media queries there is
also a lot of nice layout capabilities for the future - provided
we can build UI to make this easily accessible.</p>
<p>Axel</p>
</body>
</html>