After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 782470 - Style <blockquote> in HTML replies
Style <blockquote> in HTML replies
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Composer
3.24.x (obsolete)
Other All
: Normal normal
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2017-05-10 18:44 UTC by Martin Dietze
Modified: 2017-07-25 11:16 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Proposed patch (2.87 KB, patch)
2017-05-31 18:18 UTC, Martin Dietze
reviewed Details | Review

Description Martin Dietze 2017-05-10 18:44:36 UTC
When replying to HTML emails quoted text is indented using a 'blockquote' element. Since Outlook started using a different backend for rendering HTML mails those simple blockquotes are displayed simply as indented text, hence for Outlook users the quote is difficult to identify as such.

Other mailers, such as google mail, use additional style elements to the blockquote to make sure that on the receiving side the quote element is displayed well, e.g.:

   <blockquote style="margin:0 0 0 .8ex; border-left:1px #ccc solid;padding-left:1ex">

Since Evolution is often used in Exchange/Outlook-environments, the current behaviour can be considered quite problematic. Since it looks like rather easy to implement, this would be quite worthwhile effort.
Comment 1 Milan Crha 2017-05-11 06:29:16 UTC
Thanks for a bug report. From the related mail list thread [1]:

Evolution currently uses:
   <blockquote type="cite">
while that 'type="cite"' is not referenced in HTML 4.01 [2] neither 5.1 [3] and is not understood by other clients as expected. As I mentioned in the thread [1], I always thought that type="cite" is a standard way of the attribution for the blockquote, thus it was a surprise to me that I failed to find a reference for it.

Gmail uses:
   <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;
   border-left:1px #ccc solid;padding-left:1ex">

Outlook 2016 uses:
   <div style="border:none;border-left: solid blue 1.5pt; padding:0cm 0cm 0cm 4.0pt">

Evolution should also use something standard, hence style the blockquote element, either in addition to type="cite" or as a replacement. The blockquote colorizer should be adopted to any such change.

[1] https://mail.gnome.org/archives/evolution-list/2017-May/msg00035.html
[2] https://www.w3.org/TR/1999/REC-html401-19991224/struct/text.html#edef-BLOCKQUOTE
[3] https://www.w3.org/TR/2016/REC-html51-20161101/grouping-content.html#the-blockquote-element
Comment 2 Martin Dietze 2017-05-31 18:18:06 UTC
Created attachment 352962 [details] [review]
Proposed patch

This patch works with version 3.20.
Comment 3 Milan Crha 2017-06-01 08:18:57 UTC
Review of attachment 352962 [details] [review]:

Thanks for the patch. I adapted it to current sources and it has a downside, it influences the look-and-feel in the composer window, especially in Plain Text mode you get something like:

|> some quoted text
|>
|> > some sub-quoted text
|>

where the vertical line is the added styling. HTML quotations loose their correct colors, thus the top-level quotation is dark blue on the left and light-blue on the right.

This is a good start, I just think that the styling should be added to all quotations in pre-processing when sending/saving an HTML message. What color to pick is a question, the "rainbow" colors for different deep level might also be nice to have, but not necessarily.
Comment 4 Berend De Schouwer 2017-06-01 08:23:33 UTC
(In reply to Milan Crha from comment #3)
> 
> This is a good start, I just think that the styling should be added to all
> quotations in pre-processing when sending/saving an HTML message. What color
> to pick is a question, the "rainbow" colors for different deep level might
> also be nice to have, but not necessarily.

Any chance for a "no color" or "high contrast" option for visibility impaired persons?  Or honouring the GTK theme?
Comment 5 Martin Dietze 2017-06-01 08:29:23 UTC
OK, some side effect like this one had to be expected. Unfortunately I don't know the code base at all, so this was merely by trial and error. 

However I urgently need a fix for this since everybody in my organisation has upgraded to one of the Outlook versions that don't style BLOCKQUOTEs properly themselves, and I'm getting more and more negative feedback when communicating with them. 

If somebody has a hint on where to start I may go and try it out. Better of course would be somebody familiar with the code adding this. It does not seem to be a big deal. 

By the way, google mail isn't any better either. In fact I used my google mail account for testing my patch.
Comment 6 Milan Crha 2017-06-01 09:37:04 UTC
(In reply to Berend De Schouwer from comment #4)
> Any chance for a "no color" or "high contrast" option for visibility
> impaired persons?  Or honouring the GTK theme?

See the comment #0 and #1 for what Gmail and Outlook do. They both hard-code to blue. Whether it's derived from some UI theme or just "always blue" I cannot tell.

The thing is that what we are trying to fix here is an interoperability problem. Evolution itself will do its own tweaks to show the colors the users may expect. That you use dark theme doesn't mean that the receiving side also uses dark there, thus colors you see locally may be invisible for the receiving part (that's one of the many reasons why HTML emails are bad).

(In reply to Martin Dietze from comment #5)
> OK, some side effect like this one had to be expected. Unfortunately I don't
> know the code base at all, so this was merely by trial and error. 

Yes, that's fine.

> However I urgently need a fix for this since everybody in my organisation
> has upgraded to one of the Outlook versions that don't style BLOCKQUOTEs
> properly themselves, and I'm getting more and more negative feedback when
> communicating with them. 

Correct me if I'm wrong here, but if I got it right, then you already have patched evolution with your change and as you are basically the only one using it and you are aware of the side-effects, then these visual side-effects are no problem for you, right?

As you also provided the patch for 3.20.x, I'm sorry to say that, but there is not planned any other release of 3.20.x, it's basically dead for upstream. The changes, once fully done, will be part of the development version (3.25.x) and the current stable version (3.24.x), if not postponed (but I hope it'll make it to these version series). The code changes between 3.24.x and 3.20.x are significant, it doesn't make much sense to try to update your patch for it, especially if you are fine with the change you proposed.

By the way, the previous Evolution, the one which uses GtkHTML as its composer, is also "affected", because GtkHTML generates unstyled elements as well (GtkHTML is completely unaware of CSS):
   <BLOCKQUOTE TYPE=CITE>
      quoted text<BR>
   </BLOCKQUOTE>
Comment 7 Martin Dietze 2017-06-01 11:50:29 UTC
[Milan Crha, commet 6]
> Correct me if I'm wrong here, but if I got it right, then you already 
> have patched evolution with your change and as you are basically the 
> only one using it and you are aware of the side-effects, then these 
> visual side-effects are no problem for you, right?

As a temporary solution this is OK for me. I probably would not want to share this though. In our organisation there's a couple of other Evolution users for who I provide rpm builds.

> As you also provided the patch for 3.20.x, I'm sorry to say that, 
> but there is not planned any other release of 3.20.x, it's basically
> dead for upstream. 

I am aware of that. However I - like others - have to use an RHEL7-based system based on not really up-to-date GNOME and GTK versions. Since Evolution's build depends a lot on the GNOME/GTK ecosystem's dev tools I have to stick to this older version. The version I am using now is my own backport. Being able to build the upstream version on a system like mine would help a lot (nudge, nudge, winkle, winkle).

> The changes, once fully done, will be part of the development version
> (3.25.x) and the current stable version (3.24.x), if not postponed 
> (but I hope it'll make it to these version series). The code changes 
> between 3.24.x and 3.20.x are significant, it doesn't make much sense 
> to try to update your patch for it, especially if you are fine with 
> the change you proposed.

If there is a *real* solution to the problem without the mentioned side effects, I'll surely take a look at the patch and try to find out whether I can create a semantically-identical patch for my legacy version that can be used by distro package maintainers.  

Even better would be, of course, a significant update of the GNOME/GTK ecosystem on my distribution or changes to Evolution's build dependencies that would make building it on my system realistic. Unfortunately based on my experience so far neither of them seems very realistic now.
Comment 8 Milan Crha 2017-06-08 16:42:14 UTC
I tried to make the code smart, thus it pre-processes the HTML code before showing it in the message preview (and newly styles even blockquote-s which didn't have type=cite set), but it also removes the 'style' attribute, thus the blockquote-s are consistently styled in the preview.

The other part is that the composer also removes styling and preprocesses blockquote-s, and it styles them only when the HTML content is extracted from the composer. That makes it behave pretty well. I verified what Gmail thinks about such messages and they look properly, from my point of view.

Created commit 13ebd78 in evo master (3.25.3+)
Created commit 229e11d in evo gnome-3-24 (3.24.3+)