ESC: (possible) conflict resolution #1 - bug 690644, was: Engineering Council or Engineering Steering Committee (ESC) - where art thou?
On 18/08/2018 16:49, Ben Bucksch wrote:
i completely concur with the tasks that ESC should take care of. can
you post these questions individually on maildev, please? then we can
discuss them there and decide.
just one detail: UI questions are for Richard, not the ESC, which is
there for technical question and not competent in UI.
Hi Maildev,
Ben asked me to post "these questions individually on maildev", so here
goes.
Ben, please note that this is not about a UI question, but about which
HTML capabilities are desired when composing e-mail. So this makes an
issue for the ESC along with the fact that there are two conflicting
approaches, one with r+ from Magnus and r- from me along with ui-r- from
Richard, and one with ui-r+ from Richard but opposition from Magnus (r-
on the previous revision of the patch), currently awaiting Magnus'
review of the final version.
Since writing up the story with screenshots, argument pro and contra,
would take a considerable amount of time, I'll wait for Magnus' final
review decision before taking the matter further.
Those interested can head to
https://bugzilla.mozilla.org/show_bug.cgi?id=690644. In a nutshell:
We currently have two preferences, msgcompose.text_color and
msgcompose.background_color, which determine which colour tags the body
element will receive, like: <body text="#FF0000" bgcolor="#3333FF">.
Both preferences are exposed in the preferences UI with colour pickers.
Those body tag colours can be suppressed with a "per message" option
"Reader's default colors (Don't set colors in page)" in "Format > Page
Colors and Background".
Magnus proposal is to introduce a new hidden preference
msgcompose.default_colors (defaulting to true) which will enable the
"per message" option global whilst at the same time hiding the existing
preferences by removing the colour pickers from the UI.
Richard and I are proposing to add the new preference to the UI (also
defaulting to true) and disable the colour pickers when the "reader's
default colors" option is selected.
Magnus can best present his arguments himself. As far as I understand
them, he wants to remove HTML editor capabilities from the editor,
quote: "Yack(sic) - too many things inherited from Editor :(" and thinks
that users can mess up outgoing mail when choosing colours and default
font size, and they are made to believe that the e-mail is displayed as
the recipients end as it was sent.
It is true that Gmail ignores body colour tags, Hotmail ignores the text
colour while honouring the background colour, whereas European GMX is
honouring both. Richard's an my argument is that we shouldn't remove
existing functionality (or make it mostly hidden) since we have no
telemetry data on its use. Furthermore body colour tags are valid HTML
and we can't dumb down our rather sophisticated application to the
lowest common denominator. We also think that the proposed compromise to
remove those body colour tags by visible default is an acceptable
solution. As Magnus would ask: "What's not to like?".
Jörg.
I think what we need is two settings. One to specify the background
colour of that being composed and another for the actual UI. A number
of times I have seen folk wanting to modify the compose background for
aesthetic reasons, or just to make it less eye watering white. But they
do not want to specify a background colour for their email. At the
moment all of my compose window is a pale grey, until I get to the
compose part and it changes to bright white
Matt
On 19-Aug-18 5:14 AM, Jörg Knobloch wrote:
We currently have two preferences, msgcompose.text_color and
msgcompose.background_color, which determine which colour tags the
body element will receive, like: <body text="#FF0000"
bgcolor="#3333FF">. Both preferences are exposed in the preferences UI
with colour pickers. Those body tag colours can be suppressed with a
"per message" option "Reader's default colors (Don't set colors in
page)" in "Format > Page Colors and Background".
Magnus proposal is to introduce a new hidden preference
msgcompose.default_colors (defaulting to true) which will enable the
"per message" option global whilst at the same time hiding the
existing preferences by removing the colour pickers from the UI.
Richard and I are proposing to add the new preference to the UI (also
defaulting to true) and disable the colour pickers when the "reader's
default colors" option is selected.
Magnus can best present his arguments himself. As far as I understand
them, he wants to remove HTML editor capabilities from the editor,
quote: "Yack(sic) - too many things inherited from Editor :(" and
thinks that users can mess up outgoing mail when choosing colours and
default font size, and they are made to believe that the e-mail is
displayed as the recipients end as it was sent.
It is true that Gmail ignores body colour tags, Hotmail ignores the
text colour while honouring the background colour, whereas European
GMX is honouring both. Richard's an my argument is that we shouldn't
remove existing functionality (or make it mostly hidden) since we have
no telemetry data on its use. Furthermore body colour tags are valid
HTML and we can't dumb down our rather sophisticated application to
the lowest common denominator. We also think that the proposed
compromise to remove those body colour tags by visible default is an
acceptable solution. As Magnus would ask: "What's not to like?".
Jörg.
Maildev mailing list
Maildev@lists.thunderbird.net
http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net
--
“Against stupidity the gods themselves contend in vain.” /― Friedrich
von Schiller, Die Jungfrau von Orleans /
On 19/08/2018 02:00, Matt Harris wrote:
A number of times I have seen folk wanting to modify the compose
background for aesthetic reasons, or just to make it less eye
watering white.
Can't that be done in userChrome.css? Richard?
Jörg.
On 19.08.2018 10:13, Jörg Knobloch wrote:
On 19/08/2018 02:00, Matt Harris wrote:
A number of times I have seen folk wanting to modify the compose
background for aesthetic reasons, or just to make it less eye
watering white.
Can't that be done in userChrome.css? Richard?
Not userChrome.css but userContent.css. And only when bug 690644 is
applied and set to "Use reader's default colors". Then a
body {
background-color: #ccc;
}
would work also without.
Richard
On 19-08-2018 11:51, Richard Marti wrote:
Not userChrome.css but userContent.css. And only when bug 690644 is
applied and set to "Use reader's default colors". Then a
body {
background-color: #ccc;
}
would work also without
This is exactly the problem here. Let the reader decide what he wants
to see. That's way more important than letting the sender specify what
he wants to see.
If you want an analogy you can see all the major services. E.g. Twitter
used to let you easily republish tweets in your own styling, but (AFAIK)
don't anymore. This isn't all about branding but I bet they also don't
want tweets looking bad due to 3rd party fiddling - their users want a
consistent look. It's the same with Gmail, I bet that's why body
background isn't supported. Surely they could, but they don't want to
support it since consistency is important for the user experience.
Let's keep these discussions in the relevant bugs though.
-Magnus
On 20/08/2018 09:42, Magnus Melin wrote:
Let's keep these discussions in the relevant bugs though.
Well, no, since Ben asked me to post it here to inform anyone interested
in the technical discussion.
If no agreement can be reached by the people involved in the bug, a
decision has to be reached somehow, otherwise the issue remains in a
deadlock and the current situation which is bad - on which surprisingly
everyone agrees - will just be locked in forever.
Jörg.
Jörg Knobloch schrieb am 20.08.2018 um 21:26:
On 20/08/2018 09:42, Magnus Melin wrote:
Let's keep these discussions in the relevant bugs though.
Well, no, since Ben asked me to post it here to inform anyone
interested in the technical discussion.
If no agreement can be reached by the people involved in the bug, a
decision has to be reached somehow, otherwise the issue remains in a
deadlock and the current situation which is bad - on which
surprisingly everyone agrees - will just be locked in forever.
I'm in favor of not setting a background color by default. (Last time
I checked, we did set a background color by default, which I think is
wrong, but it's a long time ago that I checked).
I would even be in favor of not allowing the user to set any color.
(Note that if we allow the user to set a foreground color for some text,
we need to also set the background color at the same time.)
I don't care much about the UI, but "[ ] Set background color
[colorpicker]" makes sense to me. For the UI, I refer to Richard, who is
in charge of the UI. The ESC is not in charge of the UI, only of
technical aspects.
Ben
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.
There appear to be tendencies to deconstruct HTML capabilities for no
apparent reason, or perhaps with the argument, that you can do stupid
things with it. Some recent quotes:
https://bugzilla.mozilla.org/show_bug.cgi?id=690644#c44:
Yack (sic) - too many things inherited from Editor :(
https://bugzilla.mozilla.org/show_bug.cgi?id=1486051#c3
Falls into the category we-have-it-because-we-inherited-editor - there's
fairly little reason to have something like this in an email client.
So I just wanted to present the (perceived) tendency of the module owner
to a wider audience. However, since we follow the Mozilla module owner
system, the module owner makes the final call and all discussion is more
or less futile.
I reiterate that the so-called ESC as a larger group of developers, see
http://lists.thunderbird.net/pipermail/maildev_lists.thunderbird.net/2018-August/001254.html
for a proposed list of members, has not been established and even the
group of "technical directors" of Magnus, BenB, Kent and myself as per
Thunderbird Council decision of 2017-06-23 as decision makers is under
discussion of being abolished again. Certainly not all people in the
group are still available or their membership has been questioned
otherwise, see
https://mail.mozilla.org/pipermail/tb-planning/2018-August/006142.html.
So as I see it: During the course of the year we have achieved nothing
except the creation of the Maildev mailing list, and steps of getting
more people involved in the decision making, not only the discussion,
are even being wound back. So much for governance changes :-(
Jörg.
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.
There appear to be tendencies to deconstruct HTML capabilities for no
apparent reason, or perhaps with the argument, that you can do stupid
things with it.
I think you should look at these capabilities from the other side. If
you were to design it from scratch, is this feature something you would
include, and are there use cases where the feature comes in handy. If
you establish there's a use case, think about what the best way of
achieving it is.
Now, for bug 690644, you already acknowledged yourself you think the
feature is a footgun with few use good use cases, but you want to keep
it for the sake of... not knowing if anybody would be upset?
I think we have a responsibility to our users to make them look as good
as possible in their communication. Letting them by default compose
mails with font-size=+3 and body bgcolor=red doesn't seem like a good
idea. (They want to zoom instead.)
In general I don't think there is any point in trying to encourage users
to use extensive html formatting in their mails. Chances are pretty high
the recipients will see something fairly different from what the sender
expected. To have something that looks good, you need to put significant
time (and have the knowledge) into the composition. You can do that, but
if you put in the time, what you want is to make a fancy template that
you can reuse and improve over time. Doing it time and time again is
just not something to recommend to anyone.
Adding one-off formatting to emphasize certain information in your mails
is not what this discussion is about. That's a worth while use case.
We're discussing default values that apply to all the mails you send out.
So as I see it: During the course of the year we have achieved nothing
except the creation of the Maildev mailing list, and steps of getting
more people involved in the decision making, not only the discussion,
are even being wound back. So much for governance changes :-(
By being part of the discussion people are part of the decision making
process and can voice their opinions or alternative solutions. The idea
was to present ideas to a wider audience for feedback before going all
out. Now, the group of people is not easily definable... Clearly certain
ideas would be hard to pull through without buy-in from key people, and
that would be part of the decision on which direction to go (or not).
-Magnus
On 31/08/2018 10:14, Magnus Melin wrote:
I think we have a responsibility to our users to make them look as good as possible in their communication. Letting them *by default* compose mails with font-size=+3 and body bgcolor=red doesn't seem like a good idea. (They want to zoom instead.)
No. The proposed new default value is not to send any colours. Yes, the UI allows them to select an ugly background for all their e-mail, but the UI also allows them to select a font for all their e-mails which will in 50% of cases *not* display correctly at the recipients end.
The UI also allows users to accept any remote content by default, send outgoing mail encrypted in "Korean (EUC-KR)" and view stored passwords in plaintext.
100% fool-proof software doesn't exist and there are far worse traps than an ugly background, which, BTW, under the latest proposal would come with a warning unlike other dangerous options. The fact of the matter is: Blocking an improvement or compromise is just cementing-in the existing undesirable state. And that's not in anyone's interest.
So as I see it: During the course of the year we have achieved nothing except the creation of the Maildev mailing list, and steps of getting more people involved in the decision making, not only the discussion, are even being wound back. So much for governance changes :-(
By being part of the discussion people are part of the decision making process and can voice their opinions or alternative solutions. The idea was to present ideas to a wider audience for feedback before going all out. Now, the group of people is not easily definable... Clearly certain ideas would be hard to pull through without buy-in from key people, and that would be part of the decision on which direction to go (or not).
Sadly you're ignoring the fact that an attempt was made by Kent and others to move away from Mozilla's despotic module owner model to a more, dare I say, "democratic" or community-involved model where key contributors not only have a voice but also a vote. That effort has gone nowhere and it even being rolled back as I see it.
If you look at https://wiki.mozilla.org/Modules/All you can see the Mozilla have heaps of modules, Firefox, Toolkit and dozens of Core modules. Thunderbird appears to have four modules: TB itself, Mailnews (practically unowned), Chat and Calendar, and the TB module owner can decide the future of the product at their (in this case, his) sole discretion. As I mentioned before: A while ago "Thunderbird NextGeneration" was discussed. Due to lack of funds this didn't go ahead. But had there been funds, the TB module owner should not have had the power alone to decide to stick with the approach of TB as a desktop-centred stand-alone binary.
Given the feedback received in this thread, after Kent's departure, I seem to be the only person interested in a re-structure, so I might as well just shut up.
Jörg.