Inlining CSS
Web development has moved past inline style="" attributes—but email clients haven't. Outlook for Windows still uses the Word rendering engine. Many Gmail variants strip out <style> blocks, and even modern clients can behave unpredictably when messages are forwarded.
Moving CSS rules inline ensures that the markup you send is the markup your readers see—regardless of where they open the message. Litmus testing confirms that campaigns without inlined CSS often break in Outlook and lose critical layout properties in Gmail. Campaign Monitor’s long-running CSS support survey—covering 35 clients and 278 properties—draws the same conclusion: embedded or external styles are risky; inline styles are reliable.
How the NSW Email Framework handles it for you
Our framework uses Maizzle. During development, you write clean, maintainable Tailwind-class HTML inside partials and pages. At build time, Maizzle passes the output through Juice, the email-optimised CSS inliner trusted by the community.
Juice applies every utility class from your <style> tag directly onto the relevant element. It expands shorthand properties and resolves client-specific quirks—like Outlook’s lack of support for multiple classes. The result: a single, self-contained HTML file, ready for Litmus or your email service provider. No manual inlining. No copy-and-paste. No missed rules.
Because your source and compiled email sit side by side, you get the best of both worlds: version-controllable templates and production-ready HTML. Need to preserve a rule in <style> for a client-specific fix? Add data-embed—Maizzle won’t touch it.
What this means for developers
Less boilerplate
Focus on logic and Tailwind tokens. The build process manages compatibility.
Faster quality assurance
Inline-ready HTML passes accessibility and rendering tests earlier, speeding up reviews.
Configurable defaults
Inlining is enabled by default but can be adjusted or disabled in config.js to suit your needs.