PHP emails with CSS not working on gmail - css

I already read lots of threads about this and they all say that gmail doesnt support the style tag so I have to use the inline styling to resolve the problem. The problem is that I've look at the source code on most of the emails that I've received on gmail and most of them use the css style tag, which contradicts what other says.
So question is, why the emails with css that I've send via php mail is not showing correctly on gmail. It does show ok on Yahoo and Hotmail though

Its a bit hard to provide a detailed answer to a question that doesn't provide specifics so I'll make some general comments...
Cross web-browser designing is a piece of cake compared to designing HTML emails for different e-mail clients. There are far more email clients than web-browsers and far more variation in their support of HTML and CSS rendering. There are no "standards" per-se.
You need to keep everything simple and play to the lowest common element. It's not just a matter of the style tag being implemented or not, different client may or may not support different styles. You need to experiment with what works and what doesn't on as many clients as possible.
Some more reading for you if you haven't read these already:
http://css-tricks.com/using-css-in-html-emails-the-real-story/
http://coding.smashingmagazine.com/2012/03/13/techniques-overcome-poor-css-support-email/

Many people design with their CSS in the style tag and then use a tool to inline it prior to sending, making it compatible with for Gmail. Depending on the tool, it may not remove the original css, effectively doubling up. Another reason could be that those css declarations are intended for non-Gmail clients. A common example is media queries, which don't work inline, making them incompatible with Gmail.
Here is a related blog post I've written that also includes a few links to some popular CSS inlining tools

Related

Custom CSS security

I'm doing work on a website, and a user can create a custom CSS stylesheet. I understand that there will always be a danger in this, but is there any way that I could make my validation more secure? I'm using this:
$customCSS = $_POST["submittedCustomCSS"]; //put user's submitted stylesheet into variable
$customCSS = htmlspecialchars($customCSS); //hopefully validate it?
file_put_contents("../custom.css", $customCSS); //save user's stylesheet
The page the custom CSS is displayed on is PHP-enabled, and the CSS is shown through <link rel="stylesheet" href="<?php echo $postID; ?>/custom.css">
Is there any way to make this more secure? Thanks in advance! :)
htmlspecialchars($customCSS); //hopefully validate it?
No, this is not sufficient. This may stop the CSS from escaping a </style> element in which it is embedded, but does nothing to prevent the CSS from styling arbitrary elements on the page, or from loading custom fonts or from abusing other problematic features of CSS whose security implications are still poorly understood.
If a custom stylesheet can be applied to any page that it's author cannot access, then you need to be significantly more strict than this. There are ways that custom stylesheets can be exploited to steal data like Credit-Card numbers or XSRF tokens that don't need to run JS.
For example, if one user can elect to use another user's custom stylesheet, then that could lead to a security vulnerability, and you should not require users to be able to read and vet a CSS file to use features of your site safely.
"Scriptless Attacks – Stealing the Pie Without Touching the Sill" explains some of the ways injected CSS can be problematic:
We show that CSS markup, which is traditionally considered to be only
used for decoration/display purposes, actually enables an
attacker to perform malicious activities.
...
We introduce several novel attacks that we call
scriptless attacks, as an attacker can obtain the credit card
number by injecting markup to this page without relying on
any kind of (JavaScript) code execution.
...
Neither of the discussed attacks depends on user interaction
on the victim’s part, but uses a mix of benign HTML, CSS
and Web Open Font Format (WOFF [23]) features combined
with a HTTP-request-based side channel to measure and ex-
filtrate almost arbitrary data displayed on the website.
Because Microsoft added CSS expressions as a proprietary extension to Internet Explorer, handling untrusted CSS securely is more complex than simply encoding it correctly. To do this properly you need to parse the CSS then only output things matching a whitelist. Unless you do this, it's trivial to inject JavaScript into the page for Internet Explorer visitors.
An alternative approach would be to only accept valid CSS, however I'd be concerned that Microsoft might try to sneak something in inside comments or something like they did with HTML.

Google's crazy ID and class naming conventions

I was just playing around with Firebug and editing Gmail's CSS file, and I wanted to edit a button, but the div ID for that button was :rj. I am fairly certain that CSS does not allow colons in —and especially starting as—ID and class names. So my guess is this is some advanced trickery. I'm not sure if it's consistent like this for each user, but FWIW, the ID was for the "Search Mail" button at the top of the page.
Does anyone know what they are doing and how they are doing it?
IDs used to be quite strict on what was allowed, not so much for classes. HTML5, however, has lessened a lot of the restrictions on what could be ID values.
Here's an article on the what's allowed for IDs and classes in HTML5: http://mathiasbynens.be/notes/html5-id-class
It's enough to make your head hurt.
EDIT:
To address more of your question about why Google is using a seemingly random ID, I'm sure the IDs and classes they are using make perfect sense to their programmers.
Google only owns one browser so if they want to create a web app that is cross browser compatible like firefox they must follow the same standards and rules as every other web developer. That said most modern browsers are pretty lenient when it comes to parsing html so while your example is not correct HTML and probably wouldn't validate there would be no visible negative effects.

Java based mailer not displaying properly in gmail

I have made a java mailer which is not displaying properly in gmail, but it is showing up properly in hotmail. In gmail, the CSS is not getting read properly, which disturbs the entire layout.
Follow a couple of rules:
If possible, just design everything in a table. Keep fixed layout.
Don't use CSS file reference. Just do styling in the elements.
Try avoiding images or at least keep as minimal as company's logo only.
Keep limited number of links in E-mails. This point is to avoid your automated mails to go in junk folder.
Avoid complex CSS rules.
Updated
By the way, you must set content type "text/html". You may look couple of good already done examples:
Real's How to: http://www.rgagnon.com/javadetails/java-0504.html
Another detailed and good worked out example: http://www.vipan.com/htdocs/javamail.html
Hope this helps.

Problem with Style in Outlook

I have a mail in Outlook which is having an Html layout and has defined some Styles in style tag. When I open Outlook in IE and open the mail, it works fine and show me the correct layout. But, when I have used same in Firefox, the style part doesn't work. When I view source, I could not see Style tags.
Style tags are notoriously badly supported by Outlook and other HTML E-Mail clients.
The convention is to use inline CSS for Rich E-Mail.
Check out this great overview: Style in E-Mail
mail readers have far greater diversity than browsers and support of HTML ranges from none to limited CSS. While a few of the newest mail readers might support CSS, its almost always safest to stay with very conservative (old) markup. HTML for emails going to the overall web should be written in HTML3.2 with limited use of CSS1.
Design your HTML with the following guidelines:
Use HTML3.2 DOCTYPE for all email going to non-restricted internet domains
If your audience is restricted to AOL, you can safely use HTML4.01 transitional or experiment with XHTML1.0
Validate the HTML and keep it very clean. After you validate, shred the validation with the following hacks.
Use CSS1 and extremely limited CSS2. If NN4.7 can parse it, it's probably safe. Otherwise: TEST.
Another great resource that I always use is Campaign Monitor's Articles and Tips section. Their Guide to CSS support in email clients is just fantastic! There's loads of info on how to get started, etc...
Hope this helps!

Why is Gmail blocking CSS in emails?

I used CSS in my email and sent it out.
When I received the email in Gmail, all the CSS was disabled; however, when I retrieved the email in thunderbird or outlook, everything is OK.
How would I fix this?
Gmail doesn't block CSS totally. It still supports inline style. Why doesnt it support style block, I've no idea. To have a good overview of CSS support in various webmail and email clients, here's a good one. http://www.campaignmonitor.com/css/
I am answering it too late but this may help someone here. To be able to view your mail as it is in gmail and other email clients, you need inline style for each tag in your html, but writing inline css for each html tag is time consuming, to save your time use the builtin tool
http://templates.mailchimp.com/resources/inline-css/
Just paste your whole email template and you will get the html document with inline css in each tag. That much easy :)
Note: you can have your class and id in class as it is.
Stylesheets are one of many, many HTML features that are often blocked by webmail providers.
HTML mail is a world of hurt and it's not going to get any better — in fact, you can expect it to get worse. Almost every feature of HTML is not supported in some mailer or webmail service. Anything at all modern is a dead loss. And of course there are still the text-only clients.
Unless you have endless spare time to burn uglying up your code and testing every last mailer, forget HTML mail. Just send a text mail with a link to a normal web page where you can be sure everything will work as expected.
If you could embed styles to classes and ids in an email, those could accidentally collide with styles used by gmail to display the application, or on purpose by someone with malicious intentions. In-line styles are local to the tag, and therefor leave gmail styles alone.
Google has to protect the user experience that it has created for people.
Another good source of info is the MailChimp EMail Template Reference. I find the Development section particularly useful because it includes information about what CSS GMail does support and how to take advantage of it.
I have just been testing this and it does support inline styles, makes the code a bit ugly but you can get around it all.
Hope that helps.
If you're using Ruby on Rails and ActionMailer you can use the gem ActionMailer Inline CSS. All you have to do is install the gem and it will automatically inline all the CSS in your mail templates. It literally could not be easier.
ActionMailer Inline CSS on GitHub
<style type="text/css"></style>
Tags have worked for me, I did have an issue where all my CSS was not working because I missed a ;
It was a tedious process but I eventually found it.
At this link #9 from here gave me the initial hint that it may be due to an individual line of CSS.
Gmail blocks all external (referenced) assets - stylesheets, images, scripts, etc. This is to protect the privacy of the recipient. You can still include inline styles:
<span style="color:red;">Red text</span>

Resources