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
- 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
- It's great to read something that's both enjoyable and provides pragmatic soluti on Because The Light is Better Here
- Great tutorial it works great! Thanks! on Quick Tutorial: Simple PHP and CSS to Highlight Current Navigation Section
Aaron – I normally do not use Safari hacks because the differences are usually quite small. But when I’ve done development for clients who are print designers (who don’t understand the acceptability of small differences), they expect it to look identical in Safari, FF, etc. I don not have a specific instance I can point you to at the moment, but the instances usually relate to letterspacing and positioning. Also form items sometimes need some additional attention.