ESC: (possible) conflict resolution #1 - bug 690644, was: Engineering Council or Engineering Steering Committee (ESC) - where art thou?
On 31-08-2018 23:46, Mark Rousell wrote:
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.
Since I feel I'm being misquoted here, let me just clarify:
I'm not out to "cut html support", or even the manual setting of color
and bgcolor. What is discussed is not having UI to set those up as a
default for every single message you write. Setting them on a
per-message basis would work like it always did.
-Magnus
On 01/09/2018 13:21, Magnus Melin wrote:
On 31-08-2018 23:46, Mark Rousell wrote:
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.
Since I feel I'm being misquoted here, let me just clarify:
I'm not out to "cut html support", or even the manual setting of color
and bgcolor. What is discussed is not having UI to set those up as a
default for every single message you write. Setting them on a
per-message basis would work like it always did.
Thanks for the clarification and I have taken it on board. It seems to
me that :
(a) If the ability to set a per-message option like this is present then
it is inconsistent and nonsensical to not be able to set a program
default for it. If a user likes a particular set of colours (tasteless
though this may be) then he will naturally want and expect to be able to
set them as a program default, rather than have to set them manually
each time. There really is no clear and overriding reason that I have
seen to remove the default setting ability for this.
(Note, I can certainly accept that there might be things that don't have
or need a settable program default but to not have something as basic as
colour settable as a program default seems bizarre to me).
(b) I would say that the desire to remove this feature from defaults is
very much an example of "cut[ting] html support". I accept that it is
certainly not cutting out HTML support entirely but it is, nonetheless,
cutting out what seems to be to be an obvious and rather basis feature:
To set a default preference for colours. Yes, this can result in
tasteless choices but that's up to the user. And what any human
recipient actually sees is of course entirely up to their mail client.
(c) I do understand that you (understandably) dislike people setting
text and background colours and want to discourage it slightly by
removing the default so that people might forget to do it on a
per-message basis but, quite fundamentally, I do not think it is the
place of an application to 'influence' the user in this way. It is the
place of the application to, as far as possible, serve the user's
preferences, as they define them.
(d) However, because setting text and background colours is not totally
reliable due to recipient mail client differences, I favour Jörg's patch
at https://bugzilla.mozilla.org/show_bug.cgi?id=690644#c70. This still
allows program defaults to be set for text and background colour but it
(a) makes it clear that there are possible issues with it, and (b) the
default is for setting of colours to be disabled. This approach, surely,
is the best of both worlds. I'd still like even more user-education
information to be available in or linked very closely to the UI, though,
as per my comments at
https://bugzilla.mozilla.org/show_bug.cgi?id=690644#c72 and
http://lists.thunderbird.net/pipermail/maildev_lists.thunderbird.net/2018-August/001283.html.
--
Mark Rousell
On 01/09/2018 00:36, Matt Harris wrote:
/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./
I seem to recall that the issue of fundamentally updating the compose
window (including a new editor component, both wysiwg and for source)
was discussed some time back but the discussions did not result in
actions. There was, if I remember correctly, some support for finding or
writing a new JS component to do the job. There are, of course, various
up to date HTML editors (both wysiwg and source) implemented in JS that
could be suitable as a modern email editor.
Pluggable editors is a step further and it's an appealing idea, isn't it.
--
Mark Rousell
On 01/09/2018 00:36, Matt Harris wrote:
/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./
And I should add (with apologies to our moderator for the number of my
messages) that discussion of this sort of thing is probably something
that should go in a new thread (since this thread was originally
supposed to be about a specific, single feature).
This is also the kind of subject that I think should be part of a
discussed and, as far as possible, agreed strategic roadmap (alongside
UI/UX guidelines for tactical implementation of individual features) so
that both users and devs know where the program is headed and what its
feature set and usability style should be.
--
Mark Rousell
On 01/09/2018 14:21, Magnus Melin wrote:
I'm not out to "cut html support", or even the manual setting of color and bgcolor. What is discussed is not having UI to set those up as a default for *every single message* you write. Setting them on a per-message basis would work like it always did.
As Mark said, if it's supported on a per-message basis, it makes no sense not to allow it being set for all messages.
Sadly the word "default" is being used with two meanings here. The system *default* for colours for all messages should undisputedly be "no colours". No one wants to change that planned new default value (currently the defaults are black/white with no option to disable colours other than on a per-message basis).
The UI should however let you change the preference value for the colours for all messages globally away from that default.
Jörg.
On 01/09/2018 22:28, Jörg Knobloch wrote:
The system default for colours for all messages should undisputedly
be "no colours". No one wants to change that planned new default value
(currently the defaults are black/white with no option to disable
colours other than on a per-message basis).
The UI should however let you change the preference value for the
colours for all messages globally away from that default.
I agree.
Sadly the word "default" is being used with two meanings here.
It's a common problem, I find. People lose track of whether they are
speaking about the default defaults, the current defaults, or what... ;-)
On some projects I've worked on, the term "oob" is used to refer to
program defaults as they are set 'out of the box', "current" refers to
whatever the current program defaults are set to, and "user-set" refers
to program defaults set by the user that override oob defaults.
(It can perhaps help in some projects if there is a 'shared
nomenclature' document for a project, kind of like 'microspeak' at
Microsoft).
--
Mark Rousell