From: Dominik Csapak <d.csapak@proxmox.com>
To: Stefan Sterz <s.sterz@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:14:51 +0100 [thread overview]
Message-ID: <f0567912-df1d-0a53-d294-0eaaeba3d3a2@proxmox.com> (raw)
In-Reply-To: <798cf744-7051-8458-4a3e-67145e7741f8@proxmox.com>
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?
>
> [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 ;)
>
>> 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:15 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 [this message]
2022-11-30 15:19 ` Stefan Sterz
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=f0567912-df1d-0a53-d294-0eaaeba3d3a2@proxmox.com \
--to=d.csapak@proxmox.com \
--cc=pbs-devel@lists.proxmox.com \
--cc=s.sterz@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.