Keeping Safari (and Chrome) Hacks Out of Your Stylesheets
Author: Ray Gulick; Categories: CSS, Design/Development, PHP for Designers; Comments: 18 Comments
Although I design and develop on a Mac Powerbook, I mostly ignore Safari for two reasons:
- Safari is about as standards compliant as browsers get, so it rarely needs any special attention.
- Safari is used on fewer than 4% of all computers (and it seems to have peaked).
I use Firefox almost exclusively (although I’m now experimenting with Chrome for Mac), because it’s very standards compliant, and it gives me about 99% of the same results as a PC version of Firefox. Using FF in my development process means I have the biggest browser covered (that’s right, FF has over 46% of the market, with IE6-IE8 combining for just over 37%). I use crossbrowsertesting.com to hunt for problems in IE. Ideally, I want my work to look the same in all browsers (but I’ll settle for “close” in IE6).
That said, I try to keep in mind an old saying in the web design business: The most important browser to develop for is the browser on your client’s screen. One of my clients is an ad agency, and they are completely tied to Safari (I’m pretty sure they’ve heard of Firefox, but…). So, looking good in Safari is a priority on their projects. Rarely is there a need for a hack, but occasionally it happens.
There seems to be only one reliable CSS-only way to target Safari (incidentally, it also targets Chrome, which has almost 3x as many users), outlined way back in 2007 by Dustin Brewer. You can put this in your style sheet to enclose Safari-targeted rules:
@media screen and (-webkit-min-device-pixel-ratio:0) {
/* Safari 3.0 and Chrome rules here */
}
But then you have a hack in your style sheet. I find it’s easier to maintain (and find) hacks by putting them into a different file, and your basic style sheet is more likely to validate. I experimented with using the above selector in the header to point to a different stylesheet, but had some issues (don’t remember now what they were). Finally, I settled on putting the following in the header, following the basic style sheet link:
<style type="text/css" media="@media screen and (-webkit-min-device-pixel-ratio:0)">
<!––
<?php include("includes/safariCSS.php"); ?>
––>
</style>
This displays the contents of an include file, displaying CSS rules in the header as an "internal style sheet." The contents of the php include file consists of CSS rules, but is not a CSS document. Internal style sheets in the header are usually to be avoided due to maintenance and consistency issues, but by using an include, the Safari CSS for all pages is editable in one file.
By the way, the CSS rules from the include appear in the header for all browsers, but the “@media…” statement means all but Safari and Chrome ignore the styles. Given that I’ve done websites with some extremely complex CSS and only needed 2-3 rules targeting Safari, I don’t think this approach risks adding much overhead.
View a Demo | Download Demo Files
Server Side Scripting Reminder: Because the include is PHP, which renders on the server, the files will not work locally on your computer. To see the results of your experiments, upload the files to a server that supports PHP.
Theo Wong
Jan 14, 2010
2:22 am
When I view your demo from your url in chrome and safari,it’s green,the IE is red
Ray Gulick
Jan 14, 2010
7:12 am
Theo: Exactly!
AlexS
Jan 14, 2010
8:12 am
Green in Opera
Ray Gulick
Jan 14, 2010
8:17 am
AlexS: Interesting. Apparently Opera supports Webkit?
Andy Ford
Jan 14, 2010
8:46 am
Very nice! I prefer external stylesheets – and like to avoid mixing css with back-end code – so I tested this out:
It appears to work as desired in Firefox/Mac, Safari/Mac, Chrome/Mac, & IE7/Windows. The one exception (of the few browsers I tested) was Opera(10.10)/Mac. Opera actually read the webkit stylesheet when following your approach and when using external stylesheets in my example above.
It seems that Opera (at least my Opera10.10/Mac) still doesn’t get filtered out with the ‘media’ attribute stuff. What does seem to work is to wrap the webkit-specific code in this:
@media screen and (-webkit-min-device-pixel-ratio:0) {
/* css goes here */
}
This kinda takes us full circle back to the original method that you were trying to avoid in the first place but at least the webkit hacks are quarantined.
It also doesn’t prevent Firefox (and presumably other browsers) from downloading the stylesheet the way that IE conditional comments do (I was hoping that the external stylesheet method would prevent this… sigh!). The ‘Net’ tab in Firebug/Firefox reveals that the webkit stylesheet did indeed get downloaded even though the ‘media’ attribute of the ‘link’ element prevents Firefox from reading the styles.
Ray Gulick
Jan 14, 2010
8:55 am
Interesting, Andy. Thanks for taking the time to test it out and find a way to screen out Opera.
As you noted, all browsers load the include’s CSS rules in the document header (though most ignore them because of the screen). This would be a poor method for targeting a browser that needed a lot of hacks, but Safari needs so few that it’s a viable approach, IMO.
David Hucklesby
Jan 14, 2010
10:50 am
Given that there are several ways to create almost any particular effect with CSS, why not just find one that works cross-browser? I don’t understand why such hacks are needed. There is only one problem child on the Web, as far as I can determine…
Juanma Guerrero
Jan 14, 2010
11:20 am
Wouldn’t it make sense if you ask for the user agent first and then apply the specific styles? Something like the Conditional Tags in IE. What would be the advantages and disadvantages of this?
Juanma Guerrero
Jan 14, 2010
11:23 am
And with @import? is it the same effect than usin a php include? Thanks for your time =)
Andy Ford
Jan 14, 2010
12:33 pm
@Ray – Agreed. I dare to say it would be cool if every browser had something equivalent to IE’s conditional comments… but that is a slippery slope – a very very greasy incline
Ray Gulick
Jan 14, 2010
2:17 pm
David: I can only assume your client list does not include print designers who hand off to you to make it work online. There are differences between FF and Safari; not enough to worry about unless your client uses Safari and is a designer, IMO.
Juanma: If you can make that work (conditional comments for Safari), please tell me how. @import is part of the screen, not part of the include.
Andy: Of course, what would be really cool is complete standardization between browser rendering, but that’s another post.
Dumm
Jan 14, 2010
3:03 pm
good article. thanks
Chris
Jan 14, 2010
9:32 pm
“The most important browser to develop for is the browser on your client’s screen.”
Nope, the most important one is the one your client’s customers use.
Martin
Jan 15, 2010
2:19 am
Why would I want to have a separate stylesheet for Safari and Chrome? I can not recall the last time I had to write hacks for these browsers, if ever.
Ray Gulick
Jan 15, 2010
7:30 am
Martin: of course the ultimate method for keeping Safari and Chrome hacks out of your stylesheet is to ignore any differences in rendering. But if your client demands identical appearance in Safari and FF, then occasionally you’ll need some CSS targeted to the browser with the smaller audience (Safari).
elWebmaster.com
Jan 21, 2010
3:05 am
[...] Fuente: Evo Estilos CSS para Safari y Chrome en un archivo aparte [...]
Chris
Jan 22, 2010
4:56 am
Not sure why you would need separate stylesheets for safari and chrome? If you keep your code clean and valid you should not have any major problems!
Ray Gulick
Jan 28, 2010
11:10 am
Chris: I think I’ve explained the situation in both the post and in responses to other comments. If you’d like to read them and then comment, that would be great.
If you’re struggling with whether or not to launch a blog, download and read this FREE whitepaper»
Blogging is not for everyone or for every company. If you are trying to decide whether it’s for your company, this whitepaper will help you with your decision.
Download Now»
Recent Posts
Recent Comments
A (Real) Small Business Stimulus Plan!
Post Categories
Post Archives
To top
Web design and development, WordPress blogs, WordPress as a CMS, Accessibility
Serving Santa Fe, Albuquerque, and the Southwest
What we’re talking about on EvoBloggito
Site Map | Terms | Colophon
©2000-2010, Evolution Web Development; All Rights Reserved.
Log in | Site Admin
Evolution Web Development
PO Box 4188
Santa Fe, New Mexico 87502
505-577-4002 cell phone
505-466-8292 phone/fax