The trap of using @supports in emails
@supports is basically like a media query to test support for CSS features. The W3C specification actually calls it feature query. It has been around for a while in web development, ever since around 2013. And it is now available in pretty much every modern browser.
But what about@supports in HTML emails? Here are a few things I learnt.
About @supports
The syntax for feature queries is very similar to media queries. So let’s say you want to adjust your code for a rendering engine that supports CSS blend modes, you can use the following code.
@supports (mix-blend-mode: multiply) {
.fx {
mix-blend-mode: multiply;
}
}This is really great for progressive enhancement. @supports also features a not operator, so you can target rendering engines that don’t support a certain CSS feature. MDN’s documentation on @supports is really great to dive deeper on the subject.
Email clients with @supports support
I ran a naive test through Email on Acid. And here are some email clients that do support @supports :
- Apple Mail on macOS and iOS (ever since iOS 9)
- Outlook 2011 and Outlook 2016 on macOS (Not on Windows. Don’t even dream about it.)
- Thunderbird
- AOL’s desktop webmail (in supporting browsers)
- The french webmails of Free.fr (Zimbra), Orange.fr and SFR.fr
- Libero and Nate
Unfortunately, but not surprisingly, webmails like Gmail, Outlook.com or Yahoo don’t show any support for @supports.
But even in supporting clients, there’s a huge trap in using @supports in emails.
The trap
In order to get @supports to work in an email, you need both the email client itself and is rendering engine to support it.
By email client itself, I mean any filter, parsing or security rule that might remove certain CSS properties or features. For example, the desktop webmail of Gmail doesn’t any position:absolute declaration in CSS and will remove it from your code.
By rendering engine, I mean the actual HTML and CSS rendering engine used by the email client. So for an application like Apple Mail, it means WebKit. Or for the desktop Windows versions of Outlook, it means Word. For a webmail, it means the rendering engine used by the browser you’re using. So if you’re browsing Gmail in Chrome, the rendering engine is Blink. But if you’re browsing Gmail in Internet Explorer 11, the rendering engine is Trident.
And here’s the trap. Using @supports in emails will give you hints about the actual support by the rendering engine, but not by the email client itself.
For example, Orange’s desktop webmail doesn’t support the overflow property in CSS. But if you were to use a @supports (overflow:auto) query, there’s a good chance it will be validated as pretty much every browsers support overflow nowadays.
@supports is also not exempt of bugs and limitations, as noted by Peter-Paul Koch last year. For example, @supports (background-attachment:fixed) returns true in Apple Mail, even though WebKit doesn’t support the fixed value for background-attachment.
Using @supports as a targeting mechanism
With this mind, I would really recommend against using @supports blindly for feature support in HTML emails. However, I do think it’s interesting to use as a targeting mechanism. In fact, this is already what I suggested last year to target Apple Mail in iOS 10. Because I know that WebKit only started to support four digits hexadecimals colors in iOS 10 (ie #ffff) and that the property -webkit-overflow-scrolling is only supported in iOS, I can use the following feature query.
@supports (-webkit-overflow-scrolling:touch) and (color:#ffff) {
…
}It’s not perfect by any means though. A webmail or email app that supports both these things and feature queries would also be targeted.
Using @media to fake @supports
A little known feature in WebKit is that, well before feature queries became a thing, you could use @media queries to detect support for certain CSS features. Actually, this worked for four CSS properties (as described on MDN) :
-webkit-animation-webkit-transition-webkit-transform-2d-webkit-transform-3d
Here’s an example of it in action :
@media (-webkit-transform-2d) {
…
}What’s really interesting is that while -webkit-animation, -webkit-transition and -webkit-transform-2d media queries only work in WebKit, -webkit-transform-3d media queries also work on Blink (Chrome) and Gecko (Firefox). I’m sure this might have something to do with prefix aliasing and the vendor prefix war. But maybe it could lead to some interesting use to target specific rendering engines or email clients. Unfortunately, from my tests, those media queries don’t have a much broader support than real feature queries in email clients.
Let me know if you find any interesting use for this!