I say: “standardised nomenclature!” you say: “boring”.
I say: “CSS wildcards – build a bulletproof rule set!” you say: “Hmmm…?”
I say: “this might change the way you code CSS in emails!” you say: “Meh, OK. Go on, you’ve got 5 minutes“.
Responsive email CSS can get bloated and quickly. Start using master templates and the like and we can find ourselves adding rule after rule downstream.
After playing around with CSS preprocessor languages such as SASS a while back, and looking more recently again at BEM notation; I found these are great for web but not really doing it for me in email production. Too complex and too much of a culture change? – Perhaps.
Synthesising the above, we have found a more real world structuring of CSS rules, specifically for email.
A reminder of BEM:
The key principle is a good one as a naming convention. We can propose a take on this, using CSS attribute selectors to build a better, more robust rule set.
We will need to use the asterisk *. For completion and possible expansion we could also use the caret ^ and the Dollar sign $.
* – matches any part of the attribute value that contains given string
^ – matches if the attribute begins with the given string
$ – matches if the attribute ends with the given string
These are like wildcards, so they enable us to piece rules together in a way that works, is legible and more robust.
For example – a core rule could be:
width: 100% !important;
height: auto !important;
and an addendum would be:
Which can be train tracked together in the HTML to give:
Now it gets fun, because you can keep adding in a way that is easier to understand and less esoteric than amalgamating rules and calling it
"foo" or something, which is what ends up happening a lot of the time (especially if you are me).
We can use literally descriptive class names that tell us what is happening
width100pc means make that element 100% width,
bgFF0004 make the background color FF0004 (a shade of red) You could of course use
bg_red- or something, but don’t forget there is more than one shade of red (you’d be surprised, I’m serious). Try to be a specific and granular as possible.
Here is a working example of the beginnings of a possible master template set up: http://codepen.io/actionrocket/pen/YPmPWQ
Try it out – add rules in, see how easy it is and if it works for you. Initially seems longer, but overall it avoids repetition and makes amending the mobile version easier. Great for when it’s time for that new master template, save the idea for later – we don’t mind.
Rules will drop out where that CSS is not supported, but will still process the ones that are.
Essentially, this method is a lot simpler than BEM, but the end result is the same: code easier to read and understand, easier to work with and easier to scale.
One worry could be load times with lots of the * selector, but this should be negligible vs weight of the email (image sizes for example). Further investigation required on this; always a hot topic – continues getting hotter as email tech advances ever forward and as attention spans continue to dwindle.
Emails are not websites, yet in a large scaled up production (such as master template production) or in a team environment this concept is relevant, remix it to suit your own rule names and give it a go! I haven’t been able to give this the full test treatment, but the theory is nice. As ever use code responsibly and test, test and test some more.