From: Stefan Sterz <s.sterz@proxmox.com>
To: Dominik Csapak <d.csapak@proxmox.com>,
Proxmox Backup Server development discussion
<pbs-devel@lists.proxmox.com>
Subject: Re: [pbs-devel] [PATCH proxmox-backup] email_notifications: make html template more valid
Date: Wed, 30 Nov 2022 16:19:16 +0100 [thread overview]
Message-ID: <a94d0dcf-e1bc-a621-6a42-8b29f1552ee2@proxmox.com> (raw)
In-Reply-To: <f0567912-df1d-0a53-d294-0eaaeba3d3a2@proxmox.com>
On 11/30/22 16:14, Dominik Csapak wrote:
> On 11/30/22 16:02, Stefan Sterz wrote:
>> On 11/30/22 15:26, Dominik Csapak wrote:
>>> some thoughts:
>>>
>>> i don't think 'more valid' is possible, either the markup is valid or
>>> not
>>>
>>
>> fair, but entirely valid html in emails is .. interesting. for example,
>> it would be nice to add a doctype, but from what i found i am not 100%
>> certain that all email clients can handle it well (e.g. outlook 2019
>> can't handle the html 5 doctype apparently and ignores it [1]).
>>
>> it seems that a common practice is to use an older html 4 doctype,
>> though [2].
>
> i checked my personal inbox for html mails, and i found everything from
> html4/5 doctype, to no doctype, and even many mails that do not even
> declare <html> or <body> but start direct with e.g. <p>
>
> so maybe just dropping that and directly using the <pre> here
> would also be ok?
>
maybe, i can't tell you what will happen though, html emails are weird,
at least to me ^^'
i'll go with what you prefer :)
>>
>> [1]: https://www.caniemail.com/search/?s=doctype
>> [2]: https://stackoverflow.com/questions/34319889/doctype-for-html-email
>>
>>> On 11/29/22 17:40, Stefan Sterz wrote:
>>>> some webmail interfaces may behave unexpectedly if the html is
>>>> invalid. thus, close tags and declare a language.
>>>
>>> which webmail interfaces? and according to whom is the old invalid and
>>> the new valid?
>>>
>>
>> well i checked it against w3's nu validator [3]. i started out with
>> something the validator was happy with and then slowly removed things i
>> wasn't certain would render correctly due to html mail weirdness. lost
>> the doctype, because see above. lost the title, because apparently
>> android 4.4 used it in notifications. so if you used it for e.g. the
>> subject, in notifications the subject would display twice? couldn't
>> confirm that, but i thought it would be inconvenient.
>
> yeah in the html spec it says that when there is a seperate
> 'title' in the document (e.g. in mails) one can omit the title
>
> as for the doctype, i also could not really find any resource
> that would confirm the need for it in mails. when it renders
> correctly on (most) clients without though, it's fine to omit imo
>
>>
>> the last part that valid html requires is a character encoding, but that
>> should be set in emails via the `Content-Type` header. so i wasn't sure
>> if it makes sense to add it to the html too.
>>
>> [3]: https://validator.w3.org/nu/#file
>>
>>> i checked the html spec of the whatwg[0] and it seems to me that
>>> empty tags ('head' too) can be omitted
>>>
>>
>> true, sorry, should have removed it when removing the title.
>>
>>> also the 'lang' attribute is only recommended, not required
>>>
>> yes, however, why not follow the recommendation? sorry maybe i am
>> missing something super obvious but is there are good reason? the
>> reasoning behind the recommendation is accessibility, making it easier
>> for speech synthesis to pick up the right intonation.
>
> true, but it has nothing to do with validity, so it would
> at least deserve a sentences in the commit message ;)
ill add it if we go with the "keep the full html structure" option
instead of the "<pre>-only" one :)
>
>>
>>> the correct closing of the tags good though
>>>
>>> 0: https://html.spec.whatwg.org/multipage/semantics.html
>>>
>>>>
>>>> Signed-off-by: Stefan Sterz <s.sterz@proxmox.com>
>>>> ---
>>>> src/server/email_notifications.rs | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/src/server/email_notifications.rs
>>>> b/src/server/email_notifications.rs
>>>> index b3298cf9..378e805e 100644
>>>> --- a/src/server/email_notifications.rs
>>>> +++ b/src/server/email_notifications.rs
>>>> @@ -294,7 +294,7 @@ fn send_job_status_mail(email: &str, subject:
>>>> &str, text: &str) -> Result<(), Er
>>>> // Note: OX has serious problems displaying text mails,
>>>> // so we include html as well
>>>> let html = format!(
>>>> - "<html><body><pre>\n{}\n<pre>",
>>>> + "<html
>>>> lang=\"en\"><head></head><body><pre>\n{}\n</pre></body></html>",
>>>> handlebars::html_escape(text)
>>>> );
>>>>
>>>
>>>
>>
>
>
next prev parent reply other threads:[~2022-11-30 15:19 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-29 16:40 Stefan Sterz
2022-11-30 14:26 ` Dominik Csapak
2022-11-30 15:02 ` Stefan Sterz
2022-11-30 15:14 ` Dominik Csapak
2022-11-30 15:19 ` Stefan Sterz [this message]
2022-11-30 16:09 ` Thomas Lamprecht
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a94d0dcf-e1bc-a621-6a42-8b29f1552ee2@proxmox.com \
--to=s.sterz@proxmox.com \
--cc=d.csapak@proxmox.com \
--cc=pbs-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox