EvoBloggito
Keeping Safari (and Chrome) Hacks Out of Your Stylesheets
Author: Ray Gulick; Published: Jan 13, 2010; Category: CSS, Design/Development, PHP for Designers; Tags: CSS, Design/Development, PHP for Designers; 21 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.
Related Posts
Creating a Faux Double Background with Absolute and Relative Position
Web Designer, Web Developer: What’s the Difference?
The Optimal Line Length Principle Applied to Web Design
Free XHTML/CSS Template for Use with Photoshop 4-Column Grids
Oops! There Goes Another Accessibility Mistake
21 Responses to “Keeping Safari (and Chrome) Hacks Out of Your Stylesheets”
Leave a Comment
Comments are welcome; even from those who disagree with me (especially from those who disagree). To see them published, put your name in the "Name" field, rather than the name of your business or keywords. Also, a comment that shows you read the post increases the chances your comment will be recognized as a legitimate comment and not spam. ;-)
Recent Posts
- Recent website launches: all WordPress, all the time
- Child Themes: A Sanity-saving Approach to Redesigning/Hacking WordPress Themes
- WordCamp Albuquerque: beyond expectations by any measure (and some code)
- WordCamp ABQ presentation: Build a powerful CMS with custom fields and custom post types
- What makes a good CMS?
- How to List Upcoming Events and Events Archive with Custom Post Types
- Why I’m abandoning a land line altogether: bye bye Qwest!
- Hilltop Landscaping: what a company blog should look like
Recent Comments
- Hello, I just wanted to comment on this particular article. I think you made a on What makes a good CMS?
- Ray, I've been very happy with the FaxIt Nice service out of San Francisco... Th on Why I'm abandoning a land line altogether: bye bye Qwest!
- Do I think Google mines the data? Of course! I'm sure they mine all the data on on Why Your Primary Business Email Account Should be Gmail
- So what if you're in a business or operating a web site that is or may be in com on Why Your Primary Business Email Account Should be Gmail
- I've stumble a website recently, its a WordPress blog with personalized plumbing on Wanted: A Plumber Who Wants to Grow His Local Business
- Thank you for this. on Quick Tutorial: Simple PHP and CSS to Highlight Current Navigation Section
@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
And with @import? is it the same effect than usin a php include? Thanks for your time =)
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?
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…
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.
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.
AlexS: Interesting. Apparently Opera supports Webkit?
Green in Opera
Theo: Exactly!
When I view your demo from your url in chrome and safari,it’s green,the IE is red