The title is really just the shortened version of the question. I'm aware of Gmail's limited CSS support, but I was reading "Guide to CSS support in email", which has a note for Gmail's support of .class and #id selectors:
(!) Works in some instances if CSS is inlined before or during campaign import
What does this actually mean as far as CSS support is concerned? To me, it sounds like it's just suggesting to use a preprocessor to take any style declarations and apply them to the matched elements.
Is there a trick to being able to use CSS classes in an HTML email in the Gmail client?
Gmail will only use CSS that is inline. It will not allow internal or external style sheets. Or rather I have found its support to be unreliable at best. Use this tool to do to convert internal and external style into inline for you:
http://inlinestyler.torchboxapps.com/styler/
It even tells you how well your document is supported in different email clients. This will allow you to develop in a more sane fashion, and only convert it at the end.
Gmail does support .class and #id selector and internal style sheets (meaning tags) at the moment. You should keep in mind that some of the styles are modified by Gmail. You can't for example use negative margins or box shadows atm.
I'm not sure about external style sheets though. I haven't tested those.
Related
I have an old email template contributed to by several people and it uses an attibute selector to select the class attribute value in addition to the normal class selector.
*[class=hide], .hide {
display: none !important;
}
Every media query selector in the email is set up this way using square brackets in the first selector.
I'm trying to figure out if this usage can be removed in favor of only the regular dot syntax .className selectors.
Searching around, I can see that at least at some point, Yahoo Mail required this syntax within media queries.
Where is the attribute selector syntax for class names necessary in HTML emails in 2022?
It's not required. In fact, if you do it, there are risks depending on what is written that Gmail apps will delete your entire <style> block. You are right that it was an old Yahoo requirement (and that requirement has passed).
So definitely use normal classes, if you need embedded styles at all (you should rarely need them, since most of the styles need to be inline as many email environments don't support embedded styles - see https://www.caniemail.com/features/html-style/).
You might also like to lookup what other selectors are currently supported here: https://www.caniemail.com/search/?s=selector
Generally, we only need to use embedded styles for progressive enhancement.
Are there any tools out there that can process a CSS file, inserting -webkit equivalents for styles that aren't 100% supported across the board?
I'm using calc() in my CSS which isn't supported across all browsers. Instead I have to use -webkit-calc() for safari etc.
I'd like a tool that will insert -webkit into the CSS for styles that aren't supported 100% across the board, or to be able to specify the target browsers/versions and have the tool work out whether it needs to be inserted or not. Presumably the tool would have to know what styles were supported in which version of which browsers.
You're looking for -prefix-free.
Are you looking for http://lesscss.org/?
The dynamic stylesheet language.
LESS extends CSS with dynamic behavior such as variables, mixins, operations and functions.
LESS runs on both the server-side (with Node.js and Rhino) or client-side (modern browsers only).
[EDIT]
After answering, i found this website http://prefixr.com/index.php where they use a script to reformat css declarations. Maybe you could study this one.
When developing a web-based email system, is there a generally accepted correct way to handle style sheets on incoming emails? I am referring to the <style tag. Not referring to #import or <link notation.
These stylesheets have to be restricted to only the element containing the foreign email, or else they will also adjust the content of your own system, which is a big no-no.
I am aware that I should sanitize scripts and stylesheets, which will allow me to prevent url background images, or fixed position elements that would cover parts of my system.
I would not want to drop the stylesheet completely, so I see these options
Convert style sheets to inline styles
Put the entire foreign email in its own div with an ID, and change the style rules to only affect that div (for example a,b{color:purple} would become #foreign a,#foreign b{color:purple})
Are either of these good ideas? Is there an obvious/better way that I am missing? What is common/accepted/robust?
Email doesn't support external style sheets, so all CSS on a html email is in the page style tag, or inline. As it is standard for clients like gmail and yahoo to strip the style tag, and everything else outside the body tags, you could simply do the same. Limiting incoming emails to inline styles will keep all CSS local to those elements. It is pretty much email design 101 to inline the css, so you don't have to worry about your email system being less than what is standard.
Web clients also strip many CSS elements in addition to this. Don't want someone adding position:fixed; for example as it would break out of the viewing pane. The best reference for what CSS is allowed in each client is Campaign Monitor's CSS guide.
I think the best idea is use inline styles. I have made may web sites that send styled html email and inline styles is the only thing tha work in most email sistemas.
Best practices in normal web development call for putting your styles between style tags or loading a style sheet; however, I've found out that several email clients will ignore any style tags and only execute inline styles (www.campaignmonitor.com). I can deal with that, but I'm not sure if CSS supports inline media queries. I would like my email to display a little different on the desktop. Is something similar to this supported?:
<div id="myDiv" style="#media screen and (max-width:480px;){ color:black; }"></div>
HTML emails are an entirely different beast. You need to code them like it is 1999. Use a very limited set of tags and make sure all or your styles are inline. Use tables for your layouts.
To make use of media queries you need to do both.
What I recommend doing is to first create your email with all inline styles. Then when you are happy with it you can add support for mobile.
To add support for mobile add the media queries to the head tag and use !important to override any inline styles.
Here is an example:
Optimizing for mobile email
Here is a helpful chart that details which css support for email clients.
http://www.campaignmonitor.com/css/
I don't think they work inline like that, you would probably have to embed the stylesheet in the HTML email template itself (e.g. <style>#media {...}</style>).
Even that seems like a VERY dodgy thing to rely on. HTML emails are a huge pain in the ass because standards and CSS support are about a decade behind and there is massive variation among popular email clients in terms of which properties and types of styling are supported.
In general keeping it simple and using old school table based layouts with all inline CSS is the way to go. Campaign Monitor has a great chart of support for various CSS properties in major email clients and devices.
A common workaround to the problem of HTML not rendering correctly in email clients is to do the best you can and have a prominent link at the top that says: "Email not displaying correctly? View it in your browser."
Ray Kurzweil's weekly newsletter blast does this, and it's very well formed, and well done, and I always read it. (It's a brilliant blend of content and presentation).
I have two issues I have ignored so far, but I will really appreciate some light shed onto them.
First: how can I solve differences between Safari, Chrome and Firefox and the various tags that their engines render differently? Should I just write down the right attribute for each in the same css rule? Is there no better way?
Is there a way to separate the CSS sheets for these browsers as I am doing for IE? Is this recommended?
Second: What about CSS3 attributes? Should I just write them again in the same rule after the CSS2 attributes?
Will this cause problems validating the CSS with WC3?
Welcome :)
If you start without the prefixes, you should write the code, generally, with all the semantically appropriate tags, first.
Then, you can decide what your goals are.
If you want W3C compliant CSS files, then you'd need to strip out the vendor specific prefixes by default. This would then allow the latest browsers to pick up the standardised CSS properties if they support them.
This will target less of your market than you might wish, so then you should ask if progressive enhancement is a possibility. If you can reasonably enhance the visuals by using css applied after the page has loaded, such as applying styles with jQuery, MooTools or Prototype libraries AND these libraries are already serving a purpose in your website, then you could apply additional styles with those libraries (and possibly use them in conjunction with Modernizr to determine which elements you may want to additionally support.
However, it's likely that a browser will skip a property it doesn't understand and will render the ones that it does, so I'd suggest that if you code it to W3C Standards first and then add in your additional vendor prefixes 'before' the final (correct) one, then you'll likely have satisfied reasonable measures to be compliant and meet design needs.
Edit:
There is a little bit of confusion between validation results from:
http://validator.w3.org/
and writing valid code related to vendor prefixes to get CSS effects cross-browser:
List of CSS vendor prefixes?
for working on some cross-browser CSS, you might find http://csspie.com, for IE compatibility with some CSS3 properties, useful along with http://www.colorzilla.com/gradient-editor/ for cross-browser gradients and http://cssplease.com for code that gives you alternative vendor prefixes, including different versions of IE support for many different properties.
In terms of validation, here's what W3C says about it: (see comments here: W3 VALID cross browser css gradient,) and official docs here: http://www.w3.org/TR/css3-syntax/#vendor-specific
If you code according to the specifications first and test your code out against that and then add in your vendor prefixes to get the same effects on the browsers you want to support (see progressive enhancement: What is Progressive Enhancement?) then you can be more confident that your code is supporting the appropriate standards, adding value to those with more advanced browsers and still useful for those without additional features (see also WAI III compliance, 508 compliance and others if you want to write a more inclusive site).
Caveat: Web Apps may not always be inclusive or follow these guidelines depending on who the audience is.
If you are using jquery on the site you may want to look into PrefixFree. It's a script that adds the vendor prefixes for you, so for example your put border-radius:6px; in yor css and it reads the browser and adds the appropriate vendor prefix for you via js. I like it cause it keeps my css docs more readable.