Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inject contents of <head> tags into composer's head section. Also overwrite DOCTYPE and all <body> attributes #79

Closed
skm1980 opened this issue Jul 27, 2020 · 14 comments
Assignees

Comments

@skm1980
Copy link

skm1980 commented Jul 27, 2020

Involved are DOCTYPE, html, head and body Tags. If I delete the standard TB HTML Code and copy my own HTML Code in an new E-Mail in Thunderbird everything works perfekt. If I use ST4 im getting a really mess. Code Sample enclosed. Hope, this get solved :)
ST4.Code.Sample.txt

@RealRaven2000 RealRaven2000 self-assigned this Jul 28, 2020
@RealRaven2000 RealRaven2000 changed the title ST4/TB replace, add and make a mess out of my own HTML E-Mail Code Support the use of <head> tag contents, including DOCTYPE and including <body> attributes Jul 28, 2020
@RealRaven2000
Copy link
Owner

RealRaven2000 commented Jul 28, 2020

Thanks - I have made the issue title more specific trying to describe what you want to achieve,

At the moment the <body> tag is being discarded; the contents of <head> should actually be included (so if you have style tags there they should actually still be in the resulting email). Here are a couple if specifics

  • <body> is something that Thunderbird creates and I do not want to delete it, but I can try to parse the template for a body tag and transfer it's attributes to the main body. You can still affect the visual properties of body by adding some style rules for it.
  • The contents of the '' section could likewise be parsed out from the HTML template and stashed away somewhere to be reinjected. At the moment, SmartTemplate just simply injects the whole HTML template into Thundebird's <body> tag; it assumes the template to be a "HTML fragment" rather than a whole document - which is fine in the majority of applications.
  • DOCTYPE maybe another separate problem - as it needs to be at the very top of the document. I wonder if a global setting would be better suited in this case? Most people nowadays will probably wnat to have the most modern and compatible HTML5 doctype, so we could default this nicely to <!DOCTYPE html>.

@calrosario
Copy link

In deed, the contents of is included in body tag but that way, some css rules no longer works as it is suposed when the mail is opened in a browser rather than in TB. For example properties of the tag (class:hover effect) will no longer works how it is suposed because it must be inside head tag and not body tag. You only notice that if you open the mail directly from email web server account with a browser (like edge/firefox/chrome/opera/etc.). If you open in TB a:hover effect (somehow??) continues working as espected (sort of rall back/reinjection thing?? i dont know). This problem/issue (behaviors rules related) extends to overs tag properties when inserted in body rather than head tag.
I think/assume TB trys to preserve head content in body tag because most mail servers strip/remove/clear this tag and introduce defaults behaviors instead. But the result is broken behaviors in some interactivity/responsiveness of mail template.
Of course some properties/styling tags (like effect, opacity, transform, etc.) will never work in almost all majority email servers like gmail, yahoo, etc, when the mail is opened in a browser. But opened in TB (or others web mail aplications) some of this features/rules are still present (not all).
To get the "permited/possible" css rules running everywhere TB/Browsers you need to get the rules in head tag!!!
DOCTYPE is also important (for me) but not quite as the head tag problem when you write rich/interactive/responsivenes templates.
I am aware about diferences coding HTML and mailHTML (limitations) and some workarrounds you may get with inline CSS to minimize this limitations, but in some situations you need to get the rules in head tag if you want the desire effect in all browser and not only in TB!!
Of course you can get solved your issue editing the HTML code in TB editor (view HTML addon) rewrinting/positioning the head tag at is place, but this way you need to do it by hand, so you lost effectiveness with the load file template comand/button...

Sorry for my very bad english... Hope you understand what i mean/explain....
Thanks.

@RealRaven2000
Copy link
Owner

In deed, the contents of is included in body tag but that way, some css rules no longer works as it is suposed when the mail is opened in a browser rather than in TB. For example properties of the tag (class:hover effect) will no longer works how it is suposed because it must be inside head tag and not body tag. You only notice that if you open the mail directly from email web server account with a browser (like edge/firefox/chrome/opera/etc.).

If you are talking web mail interface: they routinely destroy a lot of the CSS rules so that it "fits" with their interface. You have to give a specific example (a html template / file) if you want me to test something!

If you open in TB a:hover effect (somehow??) continues working as espected (sort of rall back/reinjection thing?? i dont know).

It's because Thunderbird internally is just the Firefox browser, and that is very standards compliant. If you open the same email on Firefox but let's say on gmail.com, all bets are off, as they remove a lot of rules! You cannot expect web mail interfaces to be standard compliant as they won't easily then fit their advertisements.

This problem/issue (behaviors rules related) extends to overs tag properties when inserted in body rather than head tag.

This is at least doubtful. It is possible that some web interfaces remove css only selectively, but I do not see the big difference between a rule in <head> vs <body> - they both have exactly the same validity. Maybe I need to do some more research on that front.

I think/assume TB trys to preserve head content in body tag because most mail servers strip/remove/clear this tag and introduce defaults behaviors instead.

It's not the servers that remove this information, it's "mail portals". The email will still be intact on any standards compliant mail client. People who use "mail portals" such as gmail.com do not really care much about the layout of their emails.

But the result is broken behaviors in some interactivity/responsiveness of mail template.
Of course some properties/styling tags (like effect, opacity, transform, etc.) will never work in almost all majority email servers like gmail, yahoo, etc, when the mail is opened in a browser. But opened in TB (or others web mail aplications) some of this features/rules are still present (not all).

If it is not present in Thunderbird, chances are it is not standards compliant. Or there is a rule that has higher specificity. Instead of second guessing you can use the built in tool "inspector" to see which rule overwrites which other rule. You can find it in the tools menu under

To get the "permited/possible" css rules running everywhere TB/Browsers you need to get the rules in head tag!!!

I need to test this

DOCTYPE is also important (for me) but not quite as the head tag problem when you write rich/interactive/responsivenes templates.

The best DOCTYPE is HTML. Which is HTML5 and the most standards compliant. If you still use transitional then all bets are off; I highly recommend not using these broken doc types as they are highly unpredictable due to many browser bugs.

I am aware about diferences coding HTML and mailHTML (limitations) and some workarrounds you may get with inline CSS to minimize this limitations, but in some situations you need to get the rules in head tag if you want the desire effect in all browser and not only in TB!!

the only main limitation in HTML in mails is that you cannot use script. Everything else is allowed - including flex model, float, animations etc. It's all allowed. But you cannot expect that every mail client will actually display it - many mail clients thing it's nicer to display mails as bare minimum so they modify the mail body. There is not much you can do about this as mail composer except guessing and testing and then coming up with something that "mostly works".

Of course you can get solved your issue editing the HTML code in TB editor (view HTML addon) rewrinting/positioning the head tag at is place, but this way you need to do it by hand, so you lost effectiveness with the load file template comand/button...

That's why it is important to write your email templates in an external text only editor (such as notepad++) with Syntax-highlighting and preview it in a browser. (Pretty much any browser will do).

Never use a WYSIWYG editor (such as frontpage or even the built in COmposert of Thunderbird - they create terrible, easily breaking markup). use text only and test.
You shouldn't see any difference when you move css rules from head to body.

@calrosario
Copy link

Thanks for your detailed info. I was quite understandable. I send you a file with a:hover tag.
try to open this simple example on TB after parsed by smartemplate and then in online mailbox frontend (such as gmail.com).
Thanks for your attention.
test.a.hover.zip

@calrosario
Copy link

I forgot to mention: The old stationery addon (no longer supported but i still use it because iam in use of TB59) has the ability to parse the template loaded from file preserving the content of head tag.
In migration to TB78 this addon no longer works and i am triyng for an alternative.
Thanks.

@RealRaven2000
Copy link
Owner

RealRaven2000 commented Oct 3, 2020

I forgot to mention: The old stationery addon (no longer supported but i still use it because iam in use of TB59) has the ability to parse the template loaded from file preserving the content of head tag.
In migration to TB78 this addon no longer works and i am triyng for an alternative.

I am aware of this. the author stopped last year so i had to integrate the functionality from version Tb68. i didn't want to copy all his code my own addon was already very complicated. i managed to integrate the external template feature into the settings dialog (making a separate tabbed option for configuring like stationery would have felt disjointed and hard to discover by existing users).

The SmartTemplate4 method was always dismantling the body part completely (only retaining the blockquote) and then rebuilding it with the contents of the stationery html file (or html fragment).

i will look into whether we have access to the head section or we can somehow preserve it or move it "up above the body". hopefully Thunderbird will not forbid experiments the full access to its internal functions too soon and eventually implement an equally powerful public API so we can rewrite the many 1000 lines of parsing logic in a web / mail extension. hopefully we can sell enough licenses to fund this work.

@calrosario
Copy link

Thanks for your attention and explanation.
I am aware of your hard work and contribution to TB comunity.
I hope this project keep alive and wish the best for your team.
Thanks!

@RealRaven2000
Copy link
Owner

I hope you can drop DOCTYPE transitional at some stage as it is really is something that is designed to work in dead browsers (IE8 and earlier). <!DOCTYPE html> is the best way to and most standards compliant working with today's browsers (or all browsers that were updated in the last 5 years).

@RealRaven2000 RealRaven2000 changed the title Support the use of <head> tag contents, including DOCTYPE and including <body> attributes Support the use of <head> tag contents, including DOCTYPE and including <body> attributes Oct 18, 2021
@RealRaven2000
Copy link
Owner

RealRaven2000 commented Jul 30, 2023

So it turns out that some mail clients indeed ignore or drop <style> tags that are contained in <body>. This is highly counterproductive, especially if we include rules using the %style()% command from within our templates. I have therefore finally managed to at least "lift up" anything that is contained in a tag in a template into the actual head of the document.

Thunderbird 115 version: smartTemplate-fx-4.1pre2.zip

Thunderbird 91-102: smartTemplate-fx-3.18pre13.zip

This feature requires a SmartTemplates Pro license, and can be activated on the Advanced Settings page under the new group "Miscellaneus":

image

To do: translate the setting into the other 20 languages


To test the version above, download the zip file, drag the file into Thunderbird Add-ons Manager, do not extract contents or if won't install. You can rename it to quickfolders_6.0.xpi if it makes you feel better. It's the same thing, but github doesn't allow attaching that file format.

@RealRaven2000 RealRaven2000 changed the title Support the use of <head> tag contents, including DOCTYPE and including <body> attributes Inject contents of <head> tags into composer's head section. Also copy DOCTYPE and all <body> attributes Jul 30, 2023
@RealRaven2000 RealRaven2000 changed the title Inject contents of <head> tags into composer's head section. Also copy DOCTYPE and all <body> attributes Inject contents of <head> tags into composer's head section. Also overwrite DOCTYPE and all <body> attributes Jul 30, 2023
@RealRaven2000
Copy link
Owner

RealRaven2000 commented Jul 30, 2023

I am not sure if I am able to overwrite DOCTYPE, but I will definitely look into rescuing the <body> attributes as next step.

Personally I don't use the <body> tag within my templates as body is usually overwritten anyway when the mail is responded to or forwarded. It is much safer to use a <div> container for the template contents and then add attributes / styles on that level as it will also likely survive quoting or forwarding much better.

RealRaven2000 added a commit that referenced this issue Jul 30, 2023
RealRaven2000 added a commit that referenced this issue Jul 30, 2023
@MarkyMarkDE
Copy link
Collaborator

I am not sure if I am able to overwrite DOCTYPE, but I will definitely look into rescuing the <body> attributes as next step.

Personally I don't use the <body> tag within my templates as body is usually overwritten anyway when the mail is responded to or forwarded. It is much safer to use a <div> container for the template contents and then add attributes / styles on that level as it will also likely survive quoting or forwarding much better.

I personally would prefer not change the DOCTYPE for compatibility reasons.
The devs of TB know that html5 and utf-8 is Standard, but I think, the reason why they not change this are compatibility reasons.

Body tag: Sure, in a perfect world you do never format the body tag of an e-mail, but unfortunately some mailers have no manners. Here you need to overwrite indeed their styles with !important rules or your mail is in the same style as from sender.

@RealRaven2000
Copy link
Owner

I have implemented the body attribute merging as well. There is one minor caveat - basically the <body> tag(s) is/are converted into <div class="smartTemplateBody" (remaining attributes)>, then the attributes are all harvested into an array and removed from the original tag and injected into the composer body element. So far so good. However - the original div will not be removed (shouldn't matter too much unless you use direct descendant selectors).

Existing attributes of the body tag may be overwritten. You can include multiple body attributes, the last attribute parsed overwrites previous ones. I think any additional class attributes of the template <body> should be added to the main classList.

I include a test file with injected style sheet below:

issue 79-test-template.zip

Tb 91-102:
smartTemplate-fx-3.18pre15.zip

Tb 115:
smartTemplate-fx-4.1pre12.zip


The usual - to test the preview versions above, download the zip file, drag the file into Thunderbird Add-ons Manager, do not extract contents or if won't install.

@RealRaven2000
Copy link
Owner

For the topic of automatic CSS inlining, see my question at this repository. Apparently the juice library may be a possible solution for this topic.

@RealRaven2000
Copy link
Owner

Finally implemented in 4.1 - Published 09/08/2023

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants