ESC: (possible) conflict resolution #1 - bug 690644, was: Engineering Council or Engineering Steering Committee (ESC) - where art thou?
On 31/08/2018 19:27, Ben Bucksch wrote:
Colors are not part of HTML. (they were at one point in time, but they
were neither originally, nor are now)
HTML is about structure, not presentation. the reader software can
present the structure in a way that is pleasant to the reader user.
i think this is very appropriate for the email context.
Oh come on, you're joking aren't you? ;-) As you know, when people talk
about "HTML emails" they are not being literal. HTML emails today can
(and do) include CSS if you feel that HTML alone should not include
presentation attributes.
Out there in the real world, HTML emails (both with or without CSS)
include colour. It doesn't really matter whether the colour information
is done directly in HTML elements or via CSS, but the fact remains that
HTML emails can and do include coloured text and backgrounds and it is
necessary for Thunderbird to be part of this world.
In an ideal world, sure, it would be nice if the recipients of emails
could choose exactly how they were presented but that's a job for their
own mail client. It is ultimately up to their mail client to parse
incoming emails and show only those elements or attributes (either HTML
and/or CSS) that the user wishes to see.
In the context under discussion here, like it or not, if we want TB to
be competitive in the modern world then it does need to give users the
chance to compose HTML-encoded emails either with colour or without, as
they prefer. Exactly how their colour preferences are encoded in actual
emails (e.g. old fashioned HTML tags and attributes or funky up to date
embedded CSS) is largely a separate question.
--
Mark Rousell
On 31/08/2018 18:40, Onno Ekker wrote:
What I miss every timr when people say that recipients don’t see formatting is that a lot of (company) users use Outlook and they /do/ see formatting! I’m not in favor of html mail myself, but I think that if you deny this and strip formatting options from Thunderbird, you’ll only lose more users to other clients.
This. I totally agree with you.
I also used to not be in favour of HTML email but I switched over to it
permanently a few years ago when many of my end users clients started
asking me why my emails looked so terrible. At first I didn't understand
what they meant but I came to realise that they meant that it was all
plain text! I came to realise that I simply had to move to using HTML to
keep up with the times, like it or not.
--
Mark Rousell
On 31/08/2018 21:20, Ryan Sipes wrote:
Man, this thread has a lot going on! I think having the two issues being
discussed in this thread doesn't make either single discussion as
effective as it could be. It makes sense to bring up the HTML editor
issue insofar as you are pointing out a decision that the module owner
could make in opposition to what some contributors may want.
But I think it would be worthwhile to focus on just one of these issues
in the thread. I'd like to see the conversation around the HTML editor
play out and see what Magnus, as the module's owner, ultimately makes as
a decision (if he hasn't already made it). And then move on to a thread
focused on the ESC and whether or not it is necessary. I think the
former helps inform the latter conversation.
Just to add that the bug originally under discussion is just one tiny
aspect of the HTML composing capability. Issues in general with HTML
composing in TB are somewhat wider (and should definitely come under the
auspices of a strategic roadmap, in my opinion).
--
Mark Rousell
On 31/08/2018 18:37, Jörg Knobloch wrote:
Well, you realise that Magnus wants to get rid of the colour options and
you want to make them even more discoverable ;-)
Quite! This does seem to me to be a fundamental difference of expectation.
Allowing users to choose text and background colours if they want may
well result in tasteless colour choices (or not, as the case may be) but
it is nevertheless an entirely reasonable expectation if Thunderbird is
to support HTML email[1] in the modern world. There is no future for TB
if it can't provide full featured HTML email support, and that does mean
it has to support text and background colours.
That said, the
current colour pickers aren't really good since the only offer the
limited basic HTML colours. None of them are actually really suitable as
a background, I've tried. You want something more subtle, like some very
light colour, and the colour picker doesn't allow that. But you can
enter it as the preference and at least the picker will show it. The
problem is that some mail services don't or only partly honour those
colours, so using a template with CSS is certainly a more sophisticated
approach.
As for HTML editing: Yes, that's sadly missed, that's why I offer the
add-on ThunderHTMLedit (mostly forked from Stationery, with improvements
and bug fixes) and Stationery also has a HTML editor, these days even
more modern by switching to Ace (https://ace.c9.io/).
Our friends from Postbox have an inbuilt HTML editor, they use "Code
View" (https://www.postbox-inc.com/features/html-editor).
Yup, there are many ways in which HTML composing could be improved in
TB. I recall that modernising the compose window was discussed some time
back.
Your HTML source editor extension is very useful for sorting out issues
when the built in wysiwg editor seems to make odd choices about what to
do (especially when editing replies with quoted text).
Footnote:-
1: Which, as I observed in my reply to Ben just now, can perfectly well
include CSS nowadays.
--
Mark Rousell
On 31/08/2018 22:20, Ryan Sipes wrote:
Man, this thread has a lot going on! I think having the two issues being
discussed in this thread doesn't make either single discussion as
effective as it could be. It makes sense to bring up the HTML editor
issue insofar as you are pointing out a decision that the module owner
could make in opposition to what some contributors may want.
But I think it would be worthwhile to focus on just one of these issues
in the thread. I'd like to see the conversation around the HTML editor
play out and see what Magnus, as the module's owner, ultimately makes as
a decision (if he hasn't already made it). And then move on to a thread
focused on the ESC and whether or not it is necessary. I think the
former helps inform the latter conversation.
I started the thread in its many variations on Maildev and tb-planning.
The intent was to discuss the ESC on tb-planning and to given an example
here why conflict resolution is necessary.
In general, the module owner model is the one of a ruling tyrant, even
if they get "buy-in" from others. That's why Kent started a plan to
introduce more decision makers, in fact in a Council meeting it was
voted that four people, technical directors, should become decision
makers for mail/ and mailnews/ issues. The plan was also to establish an
ESC of some form. And that still hasn't happened. You an read it again here:
https://mail.mozilla.org/pipermail/tb-planning/2017-July/005610.html
Currently the situation is that the patch Magnus wants to land is
opposed by Richard, UX submodule peer, and myself, Thunderbird module
and compose submodule peer. So frankly I don't see how, even under the
current rules, the module owner can decide to land something without
sufficient peer review and approval.
For the future I'd like to see a duly empowered panel/committee which
will simply vote, in fact, on any issue, big or small. If in this case
there are more HTML friends than foes, HTML wins, otherwise it loses.
Jörg.
Well, Outlook can't quote properly. (Just like K9 mail can't.... sigh...sorry!) so, if outlook users need to respond to specific sentences, instead of using proper standard > quotes (which outlook can't do properly), they often use color to separate quote and reply. color only. the problem is... i don't see these colors. so, on my end, i see a complete mess of an email, because i can't tell who says what. ... that's just one concrete example of what's wrong with colors in email.
there are many reasons why people might not see colors. I'll just list a few of them:
- color blind (a large percentage of males are red/green color blind)
- text only email client
- corporate firewall that down-converts everything to plaintext (i've seen these in large orgs, for security reasons)
- e.g. Simple HTML feature in thunderbird, for security, or because our user needs his own font, to be able to read emails properly and quickly.
any of the above will mean that the recipient will not see the color. so, it's a bad idea to use them for semantic.
if it was my decision, i would not allow senders to set color or fonts. i concur with Magnus here. but i could see many users opposing that, so if that's considered to drastic, then ...
at least the color UI should be specific, never the default, and the UI should be fairly hidden (e.g menu item only, no toolbar buttons), and come with warnings that educate the user.
i would trust Richard to find a nice UI solution, considering these concerns.
Ben
Am 31. August 2018 22:23:01 MESZ schrieb Mark Rousell mark.rousell@signal100.com:
On 31/08/2018 19:27, Ben Bucksch wrote:
Colors are not part of HTML. (they were at one point in time, but
they
were neither originally, nor are now)
HTML is about structure, not presentation. the reader software can
present the structure in a way that is pleasant to the reader user.
i think this is very appropriate for the email context.
Oh come on, you're joking aren't you? ;-) As you know, when people talk
about "HTML emails" they are not being literal. HTML emails today can
(and do) include CSS if you feel that HTML alone should not include
presentation attributes.
Out there in the real world, HTML emails (both with or without CSS)
include colour. It doesn't really matter whether the colour information
is done directly in HTML elements or via CSS, but the fact remains that
HTML emails can and do include coloured text and backgrounds and it is
necessary for Thunderbird to be part of this world.
In an ideal world, sure, it would be nice if the recipients of emails
could choose exactly how they were presented but that's a job for their
own mail client. It is ultimately up to their mail client to parse
incoming emails and show only those elements or attributes (either HTML
and/or CSS) that the user wishes to see.
In the context under discussion here, like it or not, if we want TB to
be competitive in the modern world then it does need to give users the
chance to compose HTML-encoded emails either with colour or without, as
they prefer. Exactly how their colour preferences are encoded in actual
emails (e.g. old fashioned HTML tags and attributes or funky up to date
embedded CSS) is largely a separate question.
--
Mark Rousell
--
Sent from my phone. Please excuse the brevity.
On 31-Aug-18 5:44 PM, Magnus Melin wrote:
On 31-08-2018 09:55, Jörg Knobloch wrote:
On 31/08/2018 01:30, Ben Bucksch wrote:
The ESC is not in charge of the UI, only of technical aspects.
The larger technical aspect is: How much of an HTML editor do we want
Thunderbird to be.
Yes there are larger technical aspects that can be discussed.
Thunderbird is an email client, and aspiring personal information
manager supporting various communication protocols. It is not, and was
never designed to be used as an HTML editor though it has HTML email
editing capabilities.
/Our users want a Microsoft word like capability of control the
appearance of their content. The want and expect something with the
capabilities and ease of use of Outlook. (Which uses Word as an
editor.) A decade ago there were bug marked Outlook Parity because it
is a good place to look at user pointing features.
The reality is the Mozilla editor is rubbish. Carets just disappear,
Text hightlighting with the Mouse gets out of control (and refuses to
stop without the escape key). These "features" of the editor are
obvious on the SUMO web site, so they are not just Thunderbird
implementation issues. This is an area requiring a lot of work to bring
it up to a standard our users expect.
So my engineering question is to we persist with the Mozilla editor
(which Mozilla have expressed the view they are not intending to work on
it, it is good enough) or get with the rewrite so we can have a
plug-able editor. Then the user can have a choice and we do not run the
risk it will join XUL on the cutting room floor.
-Matt
/
On 01/09/2018 01:14, Ben Bucksch wrote:
at least the color UI should be specific, never the default, and the
UI should be fairly hidden (e.g menu item only, no toolbar buttons),
and come with warnings that educate the user.
i would trust Richard to find a nice UI solution, considering these
concerns.
That's pretty much the current proposal. We can add tooltips to increase
the warning level :-)
Other than that, thanks for all the cases from the field.
Jörg.
P.S.: Anecdote: You're saying that some corporate firewalls strip HTML
down to plaintext. I had a case/bug once where a mail server replaced
anything 8bit with a ?, effectively only allowing ASCII. In fact, all of
Yahoo Mail is still treating all 8bit encoding as UTF-8, hence messing
up completely messages in windows-1252/ISO-8859-1, see:
https://forums.yahoo.net/t5/Sending/Yahoo-SMTP-server-advertising-8bit-capability-incorrectly-and/td-p/449275
But that wouldn't mean that we dumb down to ASCII too, right?
On 01/09/2018 09:53, Jörg Knobloch wrote:
In fact, all of Yahoo Mail is still treating all 8bit encoding as
UTF-8, hence messing up completely messages in
windows-1252/ISO-8859-1, see:
https://forums.yahoo.net/t5/Sending/Yahoo-SMTP-server-advertising-8bit-capability-incorrectly-and/td-p/449275
But that wouldn't mean that we dumb down to ASCII too, right?
On 01/09/2018 10:14, Jörg Knobloch wrote:
On 01/09/2018 09:53, Jörg Knobloch wrote:
In fact, all of Yahoo Mail is still treating all 8bit encoding as
UTF-8, hence messing up completely messages in
windows-1252/ISO-8859-1, see:
https://forums.yahoo.net/t5/Sending/Yahoo-SMTP-server-advertising-8bit-capability-incorrectly-and/td-p/449275
But that wouldn't mean that we dumb down to ASCII too, right?
OK, I can hear Magnus' answer: "Use UTF-8". But in an attempt to fix the
issue, Yahoo had UTF-8 stuffed up as well for a while (read through the
first thread).
Jörg.