Safari 4 Beta CSS Hacks
Posted on 2009.02.25 by Tom
It is innevitable that sooner or later you will have some display issue in Safari that you just can’t seem to fix without weirding out the other browsers. This, for me, is not very common at all but it does occasionally happen so previously with Safari 3 the way I commonly used to target Safari only was to do this.
/*\*/ html*div.focusdiv div#tcontent div.subdiv{ position: relative; left: -3px; } /**/
Well in the newest Safari release, version 4, this doesn’t work anymore. So what if we need to target something now? Well luckily enough there is still a way to target Safari only and as an added bonus it actually looks a lot nicer than the current method.
@media screen and (-webkit-min-device-pixel-ratio:0) { div.focusdiv { width: 400px; } div.focusdiv div#tcontent div.subdiv { position: relative; left: -3px; } }
That is pretty much it, to provide credit to the authors, the first method was called the Stokely Hack and the second method is from this site.
I’m curious, with Safari 4 being the first browser to pass the Acid3 test, why would you need to target it for anything?
There a few reasons. An example of the first reason is when you inherit sites from other devs that have only developed in firefox and their code is, as usual, almost the same in Safari as it is in Firefox. Maybe there is only one or two places where the display is different and you need to adjust a little bit of padding here or there. So you instead of having to rewrite their code completely you can add a few lines conditionally this way to save yourself time.
The worst case of this is when someone will write code in Firefox and then go test in IE next, they will adjust styles back and forth until they get what they need and then go to Safari where they have broken small things, maybe only by a couple pixels. I can rewrite what they have to make it more correct but it is faster and cheaper for the client to fix it by targeting specific browsers for their quirks.
Another example would be for fun, obviously this one isn’t as important but sometimes you might want to do something special for one browser apart from the next, can honestly say only done this once and it was actually to nag IE users but still entertaining nonetheless.
In all honesty, like I said at the top of the post, I rarely have a need for using this. I find that any layout I build with Firefox or Safari will work well with the other and look the same. Most anytime I have had to use something like this was for the above reasons. But might as well post this here in case someone runs into a need to use it or if they have happened to of used the older Stokely hack in their code and just got a phone call from a client who has upgraded to Safari 4 and notices that their site looks a little different. I am unsure why passing the Acid test would mean that someone wouldn’t need to target it though. While people should be following the rules perfectly, I would guess that most people have adjusted to writing their code to match what we have. Meaning that some code that does work now may not work the right way on a fully compliant browser. So maybe people might have to target Safari to give it better, more compliant code than they usually write.
On a last note, I do like Safari. I didn’t post this to in any way say that Safari needs to be fixed all the time. I always have trouble understanding when you see a quote somewhere on a forum that says “I hope this works in Safari.” That usually makes me think that they are a hard core IE fan.
Thanks for the comment and I hope I have answered your question.
Tom
Thanks, that answers my question well. I guess that I’ve never run into such a scenario, which is what made me wonder. When I develop a site, I get it working in FF first, and have never had any problems with Safari rendering it any differently. I think CSS resets probably help this, which is why I tend to use them in some capacity. After I have FF and Safari working, I turn to IE and apply conditional comments where necessary. These are usually specific to IE6, and to a lesser degree IE7.
All in all, I am glad to see that in general, things are getting much better from browser to browser, as they all are becoming more standards-compliant with each release. Now, if we could ever completely stop having to worry about IE6, things would be a breeze!
Will
I agree, they are getting better finally. I have been impressed with IE8 Beta and how it seems to render a lot better than it used to. I work pretty much the same way, hard not to develop in Firefox with the amount of tools available, and when i check Safari I usually don’t have any problems.
Glad that answered your question good enough, I know that I occasionally have to target it but trying to remember why is difficult or I would be able to give more examples.
It will be cool if someday you can build a layout in any browser and they all actually do render the same, seems that they would be willing to work towards this honestly. For the sake of developers they should. The most bad press that IE gets is from Devs and Designers that are tired of wasting a whole day to fix some stupid rendering problem that usually you have to hack around and trick IE into rendering the right way. So if they would work to showing us developers some support that would be really appreciated amongst they community I am sure. I prefer to just use the conditional stylesheets myself also so I don’t have to mess with the hacking around stuff.
Again thanks for the comments and here’s to hoping that by IE9 we will be far better off with IE6 out of the way completely and everyone will be upgraded to IE8 at a minimum. Wishful thinking but we can hope.
Thanks for posting that trick, Tom. That’s bound to come in handy real soon, as I’ve got a real crazy, unconventional layout to throw together.
[...] Source: http://ashevillewebblog.com/tom/2009/02/safari-4-beta-css-hacks/ [...]
[...] Handy snippet of code to target Safari 3 and 4. I found the following code from the Asheville Webblog. [...]
VRy worthwhile to go through it
This is a good solution if the issue is with webkit based browsers globally (Safari, Chrome etc). If you have a Safari-only issue, this will not always work. This could be because the release versions of these browsers use slightly different versions of webkit, so the potential for slight rendering differences exist. I am having an issue now in which I need to target Safari 4 only. Since I am already targeting Chrome using the method above, I must decide in which browser it is more important to have pixel perfect rendering and which to sacrifice…
Thanks for this. Worked well. Usually Safari is well behaved, but I was off by a single pixel that was crucial to the design.
[...] 海外のブログ [...]
thanks for the helpful tips Tom..
This does not target ONLY Safari, as it targets all of webkit browsers, so Chrome is affected as well.
Not sure if Chrome was really even out in Beta when this was posted. Either way, yes it does target WebKit browsers.