Need to exclude some rules from Pynliner

[andybak]

Related to #13

There are some rules we use as fixes for crappy web email clients. For example:

  .ExternalClass * {
    line-height: 100%;
  }

Targets the email when it's displayed within Hotmail/Outlook.com (see http://templates.mailchimp.com/development/css/client-specific-styles/ )

It would be useful to have a way to mark some CSS rules to be ignored by pynliner. For now I can mark that block myself - remove it pre-pynliner and then add it back in afterwards.

But seems like a general solution to this would be a good feature.

[rennat]

That's an interesting thing I hadn't considered up till now. We can
definitely do that but what's the right way?

Options off the top of my head are:

1. a special comment immediately preceding a tag something like /* pynliner ignore */ to bypass the next selector.
2. A method on pynliner to add selector strings (probably even regex
   patterns) to be ignored before executing. In the helper method this would
   end up being a keyword argument.

Thoughts?

On Fri, Jan 16, 2015, 12:06 PM Andy Baker [email protected] wrote:

Related to #13 #13

There are some rules we use as fixes for crappy web email clients. For
example:

.ExternalClass * {
line-height: 100%;
}

Targets the email when it's displayed within Hotmail/Outlook.com (see
http://templates.mailchimp.com/development/css/client-specific-styles/ )

It would be useful to have a way to mark some CSS rules to be ignored by
pynliner. For now I can mark that block myself - remove it pre-pynliner and
then add it back in afterwards.

But seems like a general solution to this would be a good feature.

—
Reply to this email directly or view it on GitHub
#37.

[andybak]

In my case I feel it belongs in the template - as it's probably template specific and the app with the template is a different app to the app that calls pynliner.

Also - might specifying selectors be a bit verbose? There might be lots of them (potentially)...

Maybe something like conditional comments? Either outside the styles:

<!--[no-pynline]>
<style>...</style>
<!--[end-no-pynline]>

inside:

<style>
/* no-pynline */
...
/* end-no-pynline */

</style>

Final idea. Use a valid attribute on the style tag itself. Maybe a data-*:

<style data-no-pynline='true'>
...
</style>

[rennat]

Of what's been mentioned so far I like the data attribute the best. It's
clean and actually very easy to implement. The CSS "no pynliner" block is
my next choice.

On Fri, Jan 16, 2015, 1:06 PM Andy Baker [email protected] wrote:

In my case I feel it belongs in the template - as it's probably template
specific and the app with the template is a different app to the app that
calls pynliner.

Also - might specifying selectors be a bit verbose? There might be lots of
them (potentially)...

Maybe something like conditional comments? Either outside the styles:

[oppianmatt]

+1 to the data attribute way

[knightcode]

Why not ignore unused selectors altogether? I don't see the benefit to erring out when a selector isn't found in the html.

I have a set of email templates that each have different mildly different structures. I also have a set of SASS files I'd like to share between our website and emails. Spreading the styles across each template is gross, unmaintainable, and forces me into the CSS land. It's so much cleaner to throw the SASS through its compiler, and then use something to inline the styles. I expect some of the styles to be unused sometimes.

Why be so strict?