Grow your CSS skills. Land your dream job.

Is There Any Dedicated CSS Hacks For Safari or Opera?

Published by Chris Coyier

This question was sent in by Marcin Lachowski.

Back in the day, there used to be a hack for Safari using the pound (#) sign. Safari didn't like that symbol, so you could declare something like this:

p { color: red; }
p { color: black;# }

Every other browser will read the second line replacing the first line and the text will be black. Safari doesn't like that pound sign and will stick with the first declaration and the text will be red. This is the perfect example of why using hacks are a bad idea, because it no longer works (Safari 3 and beyond).

Now there is a new hack on the block targeting newer versions of Safari as well as Opera 8/9:

@media screen and (-webkit-min-device-pixel-ratio:0) {
/* Safari-Opera specific declarations here */

Originally published here.

So the answer? Yes, there is a browser-specific hacks for Safari and Opera. But you really need to ask yourself: Should you use being using hacks like this? My generic advice is no. Not only will hacks like this cause you grief in the future, but this the fact that you are looking for a hack like this is probably symptomatic of some deeper problems with how you are approaching the design. That's not to say there isn't potentially some circumstances where a hack like this is your only way out, but before doing it, take a hard look at your current approach and see if there is another way to tackle it without needing a hack.

This is a good opportunity to mention a few other things.

  • There are many "CSS hacks" for Internet Explorer. They are never necessary. They are just as susceptible to future-breakage as other hacks, and all Internet Explorer browsers provide a perfectly valid and future-proof way to handle sending them browser-specific CSS. They are called "conditional stylesheets", see How To Create an IE-Only Stylesheet. Some days, you will wish Opera and Safari had these as well, but the reality is these are problematic to "web standards". Ideally we don't want to serve different files to different browsers. This is a long slippery slope.
  • There are various ways to doing browser detection on the web. The majority of them have to do with reading the browser "user-agent" string. There are a lot of problems with this, for a great primer, read a quick history of the user-agent string. For one thing, it's spoofable. For another, it often makes use of technologies like JavaScript, which you can't be certain is enabled on every users machine. These techniques can be used to serve up stylesheets to very specific browsers, but clearly that can be problematic. If you are going to do it, it's safer to do it with a server-side technology (like PHP) then a client-side technology (like JavaScript). Check out Conditional CSS if this is appealing to you.
  • There are some situations when serving up browser-specific files is just fine, and that's when you are working in a controlled environment where you know all the details exactly. For example, the iPhone. You know exactly what user agent string it's going to serve up, you know exactly the screen size, you know exactly the JavaScript capabilities. So while it can be a good idea to create an iPhone specific page and you can be confident that your JavaScript browser sniffing will work, there are still considerations. iPhone's don't want to be served up a different page just because it's an iPhone, that's like browser racism. It wants the same web that everyone else gets. If you want to create a specific page just for it, it should be an option, not a requirement.


  1. Permalink to comment#

    It looks like your hack targets the rendering engine Webkit. Chrome also uses Webkit so if I’m not mistaken this hack is not Safari specific, but will actually apply to Chrome as well.

  2. Good to know. I haven’t ever done or needed Safari hacks. Just minor things for ie6 (sometimes ie7), like png fixes etc

  3. This does not work in Opera. Do you test stuff before you publish? Why bother eh?

  4. @Dean Edwards:

    Here is the test page and screenshot.

    Do you test stuff before you comment? Why bother eh?

    Enough rude comments for one week.

    • Himanshu
      Permalink to comment#

      Dear sir ,
      I need a css hack which only supports for windows chrome and safari not in mac chrome safari.
      i used below hack but it also catches in mac chrome safari.
      @media screen and (-webkit-min-device-pixel-ratio:0) {

      Please if there is any solution do let me know


  5. Yves Van Goethem
    Permalink to comment#

    This doesn’t work on Opera, and this also couldn’t work.
    @media screen and (-webkit-min-device-pixel-ratio:0)
    This would also affect all webkit based browsers no mater what version, this could have very bad side effects.

  6. Works for me.

  7. Permalink to comment#

    I see red text in both Safari and Chrome (the two web-kit based browsers).

  8. Gavin Tronset
    Permalink to comment#

    I have black text in Opera 9.5 and red in Safari WinXP.

    Could Opera render it differently in Windows?

  9. Permalink to comment#

    @Yves Van Goethem: It’s not suppose to “work” in Opera. You are only suppose to see black text in Opera, so in essence, it does “work.” I can’t think of any ‘bad side effects’ by using this. Which were you thinking of?

    @Gavin Tronset: Opera does not render it differently in Windows. Still black text. It only affects web-kit based browsers.

    I can’t figure out what is so confusing about this post. The CSS property targets the web-kit rendering engine, thus any browser using web-kit (currently Chrome & Safari) will be affected. It isn’t suppose to have an affect on any other browser.

  10. Permalink to comment#

    Ladies and gentlemen,

    All the comments, combined with this post, are perfect examples of what Chris has already told us many times. Just in case anyone missed it, allow me to reiterate:

    clears throat for dramatic effect


    Alongside guidelines like degrading gracefully, etc. we have this wonderful tidbit that, while frustrating to follow at times, is really for the best in the long run. It’s good form, it’s far easier to maintain, and the code is cleaner and easier to understand 99.5% of the time. Good news: If you think before you code and plan ahead (I’m so bad at this…) you can totally avoid these 99.5% of the time, too.

  11. All right, hacks are bad. Sometimes they’re necessary, though. My company’s website was acting weird in IE 6 – the entire footer disappeared! I had to use the Holly Hack to make sure all the main divs, including the footer, got HasLayout set to true.

    Really, I can’t think of any way I could have avoided using a hack in this case. That may be a reflection of my lack of expertise, of course. Any alternative suggestions?

  12. Me again. I just registered.

    I just wanted to say, Chris, that your site is fantastic. It’s fun to look at and use, and full of very valuable practical information. I can tell you put a lot of love into it. Thank you!

  13. As much as ‘hacks are bad,’ I’ve recently spend a bit of time documenting what I consider to be the ‘best’ ones to use to target a whole range of browsers ( I think at times they can be useful, but really the biggest argument against them is the unpredictability of upcoming browser releases.

  14. Actually, I don’t mind using hacks like “* html” and underscore to target some versions of IE. Conditional comments are fine, but they have a couple of drawbacks.

    They add an additional HTTP request for the user, and IE still has the market share so you’re adding an extra HTTP request for many many users. At this state of a page load, requests matter as they block the rendering of the page.

    Also, it hides your hacks away from main CSS. It doesn’t sound like a big deal but I’ve seen people tear their hair out because they’re changing #nav { width: 300px; } to #nav { width: 400px; } and can’t understand why it isn’t doing anything. Turns out there was a conditionally commented CSS file that was overwriting it. Whereas #nav { width: 300px; _width: 302px; } (with some commenting to explain what’s going on) is much easier to maintain.


  15. Permalink to comment#

    “ARE There Any Dedicated CSS Hacks For Safari or Opera?”

  16. John – In the post I link to above, I show a work-around to make an Opera-specific style

  17. Sam
    Permalink to comment#

    I would’nt touch any of these hacks. The regularity Opera updates come out is just amazing – you never know if your hack will still work. Almost the same for Webkit. If you start right with your coding and you don’t wanna build an “Eiffeltower upsite down” then you should not need any hacks at all for these browsers.

  18. Sam
    Permalink to comment#

    Oh – a good topic – how about conditional comment based stylesheets for all other main browsers too like Safari, Opera,… that would be handy.

  19. Permalink to comment#

    Regardless of what the post is about, the title doesn’t make grammatical sense.

  20. Wow that was a grammatical foul, I’m awful at that. Didn’t even notice, even after your “ARE” comment. I think it’s too late now, with the permalink and all.

  21. John – don’t mind me, seems I wasn’t paying attention.

    Chris – in WP you can change the post title without changing the permalink, might be a little better for you.

  22. Joe The Plumber
    Permalink to comment#

    I couldn’t seem to target Opera, although the @media… hack worked for Safari.

  23. Permalink to comment#

    As you mentioned, using hacks for Opera and Safari is like taking heart drugs without having somethin with your pump.
    When you fall back on using hacks for one of these browsers then the problem is definitively (99.999532%?!) your (X)HTML/CSS markup.

    Sam: Even dealing with the thought of having CC for all existing browsers is totally senseless and reveals the missing knowledge about how websites used to be created: independent from any browser or device. Even that CC for IE are very handy, indeed, because all bugfixing is done for these browser, they are still a proprietary bullsh**.

    Nevertheless: Hacks are bad! Almost all hacks make your stylesheets invalid. It’s been a nice ”treasure“ hunt, but that time’s over.

  24. felix
    Permalink to comment#

    A late comment. Consider the table element. In the latest versions of Opera and Safari the cellspace and cellpadding are not parsed well or not at all. The 100% clean css code didn’t make them react. So what to do, when nothing legal helps. You want to include those browsers in your testing process as together they are good for a 4% of users and thus valuable. Developers have no alternative, when browsers don’t function according to the rules. So a hack makes your website work in these buggy browsers and makes your stylesheet invalid. That makes the bots say no to your site, but the users are pleased! Be practical and take a risk. Browsers are like politicians, you can’t trust them!
    Chris, thank you for the hack!

  25. jess
    Permalink to comment#

    Hacks are not all bad. IE6 is not going to change (ever) yet will be here a long time yet. Underscore hack is perfectly acceptable IMO. Using an additional CC stylesheet is NOT always an option. We are serving millions of pages per day and every http request hurts. “Hacks are bad” is dogma, well meaning albeit, but puritanical dogma all the same. Certainly one needs to be skilled in CSS BEFORE using hacks and they should never be a crutch for poor design.

  26. vipul

    this is not work in opera

This comment thread is closed. If you have important information to share, you can always contact me.

*May or may not contain any actual "CSS" or "Tricks".