Add a functionality to not inline certain css rules ( with [dontInline] attribute )
Hello guys
It happened to me to have the necessity to not inline some particular rule of my css. A solution to this could to add a [dontInline] attribute in the selector name.
es.
.very-generic-selector[dontInline] {
padding:0;
}
In this way, in the style this would be translated in
<style>
.very-generic-selector {
padding:0;
}
</style>
and my <div class="very-generic-selector">content</div> would not get any inlined style from that css rule.
What do you think?
Cheers
You could more easily achieve the same result in most situations by just wrapping the CSS you don't want inlined into a media query like @media all { .very-generic-selector { padding:0; } }. Do you think this PR offers any additional advantage?
That would be a great solution!
However, I use this project for inlining emails and I fear that the different versions of Outlook are not able to get the css rules inside a media query - If I'm wrong please correct me!
+1 to the above: Outlook 2007-2016 and several other email clients do not support @media queries, so that would be useless for HTML emails (reference). Something like this would be extremely helpful for email developers who need to automate their email workflow.
However, the current proposal might get very tedious to have to write all the time, for every selector. What do you think of something like this, instead?
<style>
/* juiceignore */
.foo {margin: 0;}
/* endjuiceignore */
.bar {color: #000000;}
</style>
<p class="foo bar">Lorem ipsum...</p>
... would result in:
<style>
.foo {margin: 0;}
.bar {color: #000000;}
</style>
<p class="foo bar" style="color: #000000;">Lorem ipsum...</p>
That is a good suggestion for efficiency and I also like that it is not an actual CSS selector, so if someone was writing CSS that they wanted to use normally (non-inlined) and then also via Juice, it won't create a conflict where you'd need to add an attribute to the HTML for the non-inlined CSS. This PR here was technically speaking a breaking change if someone happened to be using an attribute called dontInline which is probably unlikely, but want to point that out.
This PR went stale and I honestly don't remember why I didn't merge it originally, but either on the original or something else documentation needs to be added to the readme.