<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 12/20/2016 3:38 AM, Matt Harris <a
        class="moz-txt-link-rfc2396E"
        href="mailto:unicorn.consulting@gmail.com"><unicorn.consulting@gmail.com></a>
      wrote:<br>
    </div>
    <blockquote
      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 type="cite"
        cite="mid:f2273f62-0389-ab8e-7b21-2990cb9aee97@gmail.com">
        <meta content="text/html; charset=windows-1252"
          http-equiv="Content-Type">
        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>
      </i></blockquote>
    <br>
    Hi Matt,<br>
    <br>
    I think you are misunderstanding.<br>
    <br>
    Neither I nor Kent *want* to lock it down. As I just said in another
    email, this is only a contingency plan for if (or apparently *when*)
    we are forced to a decision between being able to build a working
    Thunderbird or not, without forking to a working version of Gecko.<br>
    <br>
    So, please read what is actually being said, no need to create FUD
    where there is none.<i><br>
    </i><i><br>
    </i>
    <blockquote
      cite="mid:16b876eb-2a9f-c410-05be-c4816de0ff63@gmail.com"
      type="cite"><i> I am looking forward to a time when we can see the
        full impact of HTML5 in email.</i></blockquote>
    <br>
    As I'm sure are many (or all?) of us - especially for the composer.
    But that is beside the point.<br>
    <br>
    Thunderbird right now has a very serious resource deficit problem,
    so resources must be prioritized and directed at the most pressing
    problem(s), and right now, our reliance on Gecko is the biggest
    problem due to Mozilla's deprecating core parts (XUL/XBL/XPCOM) that
    we rely on to function.<i><br>
      <br>
    </i>
    <blockquote
      cite="mid:16b876eb-2a9f-c410-05be-c4816de0ff63@gmail.com"
      type="cite"><i>Thunderbird currently supports much more of it that
        some other providers and therefore it is not getting the
        traction that it deserves.  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.  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.</i><br>
    </blockquote>
    <br>
    I hate it when people resort to this, but sometimes it is
    appropriate:<br>
    <br>
    "We await with baited breath your contribution of a rewrite of the
    core rendering engine (currently Gecko) that will fully support the
    components needed by Thunderbird to function - or, a rewrite of the
    UI that will replace all of the current functionality currently used
    by XUL/XBL/XPCOM - or a donation large enough to cover these costs
    by developers that can do the work."<br>
    <br>
    This is the real world, and these things will not happen without the
    necessary resources.<br>
  </body>
</html>