BTreeHugger’s BlogDelving into the mind of a raving code-a-holic
-
CSS hacks series
June 25th, 2008
Important updates: Opera hacks are now internationalization-friendly and isolated from Konqueror and Safari. A Safari hack isolated from Konqueror is added, and Gecko hacks are revised to filter out the latest versions of WebKit.
This is an updated version of an article I first released December 2005. I try to keep it up to date, and only feature hacks that are as forward-looking as possible. It is far more likely that hacks targetting the latest versions of a browser will change than those targetting an older version, so exercise the usual caution one should apply to CSS hackery.
IE8 has finally started to show some decent CSS3 support, and all the other betas are starting to achieve compliance with the online tests. Hopefully we will soon require no hacks at all for the major browser engines. Here is a shortlist of the hacks herein:
- Target/Filter out Gecko
- Target/Filter out Internet Explorer 7/8
- Target Safari, WebKit, Shiira and OmniWeb 5
- Target modern Opera versions
- Target only Konqueror 3.4.3 up
In an effort to be thorough (and because I use these hacks myself) I test quite a few browsers. I have added several browsers to my list: OmniWeb, iCab, Konqueror, the latest WebKit, and IE7/8. I don’t guarantee that I ran each test on each browser; sometimes I lose track while hunting for the hacks. If anyone tests these and finds they are not working correctly for a given browser, please leave a quick comment with as precise a version number as sanity dictates, including the platform.
- Camino 1.0.3
- Firefox/Firebird/Phoenix 0.1-1.08, 1.5-1.508, 2.0, 3.0 Gran Paradiso alpha
- iCab 3.02, 3.03
- Internet Explorer for Windows 4.01, 5.01, 5.5, 6.0, 7, 8
- Internet Explorer for MacOS 5.23
- Konqueror 3.55
- Mozilla 0.6, 0.9, 1.8a3 and Seamonkey 1.0-1.06
- Netscape 6.1, 6.23, 7.02, 7.1, 7.2, 8.04, 8.1
- OmniWeb 5.13 (563.66), 5.5 beta 1 (601), 5.5 (607)
- Opera 2.1, 2.12, 3-3.21, 3.5, 3.6-3.62, 4-4.02, 5.02, 6-6.06, 7.03, 7.50, 7.54u2, 8-8.02, 8.51-8.54, 9-9.02, 9.1
- Safari 1, 1.2, 1.23, 1.3, 1.31, 1.32, 2, 2.02, 2.03, 2.04, and nightly WebKit (04 Dec. 2006)
- Shiira 1.22, 2 beta 1
Target/Filter out all Geckos or just Gecko 1.8 up
Vital Update June 15 2008! Safari 3.1.1 and up may apply the old versions of these rules.. just throw an extra
[xmlns^=""]to filter out Safari. The rules have been updated below.The latest versions of Konqueror and WebKit both support
:only-child. This renders my previous Gecko hack useless. Thankfully there is a new hack, which is still valid CSS 3.This hack hinges on a difference in interpretation, namely, what would the selector
[x*=""]mean? Should it match anyx, or never (regardless of whatxis)? It turns out that almost all CSS3-capable browsers believe it should match, but Gecko does not. This means that if we reverse the clause using a:notwe can target only Gecko, or we can filter it without the:not.Target Gecko: html:not([lang*=""]) … { … } Filter Gecko: html[lang*=""] … { … }Note that you must specify a
langattribute on thehtmlelement, or this will not work as advertised.. since that breaks the XHTML Strict Doctype, feel free to change fromlangtoxmlns(or any other attribute you have onhtml).All of this is great if you want to target every old Gecko browser since at least as far back as Phoenix 0.1 (Gecko 1). However, if you want to target only modern Gecko-based browsers of the Firefox 1.5 generation (Gecko 1.8, remember Netscape 8 uses 1.7.5), then simply take advantage of the fact that older ones cannot understand both the not and only-child pseudoclasses.
We can also distinguish between versions 1.8 and lower and 1.9. This relies on the fact that case-sensitivity is supposed to matter in CSS ID’s but prior to 1.9 Gecko would allow any case. This of course requires that you use an ID (or class, which has the same issue), but if you need to target or filter out 1.9 it’s better than nothing:
Target Gecko 1.8 and up: html[xmlns^=""]:not([lang*=""]):not(:only-child) … { … } Target Gecko 1.8 and lower: html[xmlns^=""]:not([lang*=""]) #someID[id="SOMEID"] { … } Target Gecko 1.9 and up: html[xmlns^=""]:not([lang*=""]) #someID:not([id="SOMEID"]) { … }There are also two hacks that target or filter older and irksome Gecko browsers without resorting to the above hacks. Targeting relies on the Star-7 hack, which the particular versions of Gecko suffer from (Netscape 6 and OmniWeb 5 for instance). It is actually possible to target all of these browsers, then flip the Star-7 portion of the hack around to reverse rules for non-OmniWeb 5 browsers, thus isolating that browser. This is strange, since OmniWeb 5 does not actually understand the
:not([lang*=""])portion of the hack (note that OmniWeb 5.5 is also affected).Unfortunately that hack is not valid CSS. However, the hack to filter out these browsers is. It relies on an inline comment (with a space) that other browsers also cannot apply:
Target old, irksome Geckos (including OmniWeb 5): html*#test1:not([lang*=""]) … { … } Target old, irksome Geckos (NOT including OmniWeb 5): html:not([lang*=""])*#test1 … { … } Filter out old, irksome Geckos (including OmniWeb 5): html:/* */not([lang*=""]) … { … }Here is a test page. The hack is valid CSS3. Here is a test page for the hacks for older Geckos, one of which is non-validating.
Target/Filter out Internet Explorer 7/8
The IE8 beta fixes a bunch of comment-parsing bugs IE7 suffered from so it’s pretty trivial to target IE8 only by adding one of those comments to an IE7-only hack. Phil Schalm’s className trick combines with this to provide ways to target IE7 and IE8, or neither. Targetting IE7 alone is more tricky, and the best I could come up with is a non-validating hack. This reduces it’s usefulness, but since I place IE-specific hacks into conditional comments I don’t mind. Note that IE8 actually suffers from the Caio hack as of the first public beta, but I highly doubt this will stick around for long.
Target only Internet Explorer 7 (invalid, place in a conditional comment): [xmlns]body … { … } Target only Internet Explorer 8: *:first-child+/**/html … { … } Target Internet Explorer 7 and 8: [className="actualClassName"] { … } Filter out Internet Explorer 7: head ~ /* */ body … { … } Filter out both Internet Explorer 7 and 8: …:not([className="actualClassName"]) { … }Here is a test page. The hacks are valid CSS3.
Target Safari, WebKit, Shiira and OmniWeb 5
Update: The xmlns version of this hack is now applied by Opera 9.5, so it’s gone unless you want to target both browsers. The other Safari 2 hack still works fine. We can target Safari 2-era engines using
last-childin conjuction with a double-root negation of:not(:root:root). To target only recent WebKits we can use an@mediafilter with the negation, as pointed out by Chris Griego. Gecko does not understand double-not clauses like this, so it’s pretty safe. Thanks Chris!Target Safari 2 and under/KHTML: body:last-child:not(:root:root) … { … } Target WebKit: @media all and (min-width: 0px) { body:not(:root:root) … { … } }Here is a test page. The hack is valid CSS3.
Target modern Opera versions
I’ve put together some new Opera hacks not based on the :lang pseudo-class; Patrick Cavit rightly chastizes those for being a bad solution on internationalized sites. The good news is that I have better hacks now; the bad news is that the W3C Validator still doesn’t parse vendor-extensions properly. The net result? The hacks appear to be invalid, when in reality they are according to the CSS specs.
The hacks are based on thomasb’s suggestion of using media queries with the WebKit
-webkit-min-device-pixel-ratioproperty to target things. The situation is complicated a bit because Opera 9 to 9.27 treat this value as a pass, when clearly they should not. Thankfully the result is that Opera can be targetted cleanly without reversals for Safari or Konqueror, since neither apply the hacks.Target Opera 7.2 up, 9 up, or 9.5 up: @media all and (-webkit-min-device-pixel-ratio:10000), not all and (-webkit-min-device-pixel-ratio:0) { /* 7.2 up */ head~body … { /* 9 up */ } :root … { /* 9.5 up */ } } Target Opera 9-9.2x: @media all and (-webkit-min-device-pixel-ratio:10000) { … }Here is a test page. The hack is
valid CSS3(technically these are valid CSS but the validator is buggy).Target only Konqueror 3.4.3
This hack is not likely to last long, but Konqueror is currently the only browser that currently supports
:nth-childand similar CSS 3 properties. In the unlikely event that you have to target only Konqueror (I have to on Tanrei), you can use something likehtml:not(:nth-child(1)).html:not(:nth-child(1)) … { … }Here is a test page. The hack is valid CSS3.
Posted in Articles, CSS Jun 25th, 2008
Leave a Reply
To filter spam comments are approved before they appear
July 2008
| M | T | W | T | F | S | S |
|---|---|---|---|---|---|---|
| « Jun | ||||||
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 | 31 | |||
Categories
- Articles (15)
- Code (35)
- Linux (32)
- Gentoo (22)
- nLite (1)
- PostgreSQL (1)
- Random Thoughts (18)
- Rant (14)
- Tips (15)
- UML (1)
- VIM (3)
- Wordpress (1)
[...] (found on BTreeHuggers Blog ) [...]
[...] Came across 2 great articles on CSS filters and hacks for various browsers. One is available at BTreeHugger’s Blog and another one is available at Mezzoblue, whose author happens to be Dave Shea, the creator of CSS Zen Garden. For anyone who developed IE6-centric CSS for corporate intranets or mainstream audience, the articles presented some great hacks in case you need to target certain CSS rules just for IE7, Firefox, or Safari, and validate CSS 3 at the same time. [...]
Thanks… I’m using your approach to target safari….works great on my test machines. Woot!
[...] Thanx to Thomas’s CSS hacks series and the other browsers’ bad CSS3 compliance. We’ll be able to ‘fix’ it by a pure CSS3 way. [...]
What will happen when these attributes start becoming supported by future browsers? Not something to worry about on a small site, but once you start looking at enterprise strategies where the impact is much greater, is this really a way forward to CSS development?
It’s true that CSS hacks only have a certain window of usefulness. I believe that such hacks are generally last resorts, but that won’t stop everyone from not using them. Personally I hate CSS hacks, but find them an evil necessity once in a while. I won’t devolve into any rants here, but I do have some observations..
Use on an enterprise site is possible for some types of CSS hack. Careful observation shows that CSS hacks relying on specific browser-bugs or lack of support are usually safe; this includes the hacks I show for Gecko or Safari. Once those browsers support the CSS properly the hacks will only work for the older versions, and there is little chance they will affect a newer version of the browser once the bug requiring the hack has been fixed. In this case the worst that can happen is that the hack won’t affect newer versions but they will still have the bug that needed hacking. That’s really the kicker here, it means you will have to somehow track or easily search for such hacks to “update” them, if you need/want to (in practice this hasn’t been a major problem for me because I tend to use quite simple templates that are easy to update 99% of the time).
Obviously it is best to avoid hacks that are too involved; these quickly become a nightmare to manage, especially if they are not forward-looking (ie target only specific browsers with specific parsing bugs). I also feel that if you find yourself having to use more than just a few CSS hacks then your page is far too fragile, and should be re-implemented to avoid the need for hacks. This includes going back to older techniques like presentational tables in the rare cases when they will save space and be more readable. In short, CSS hacks are to be avoided but they are a powerful tool when you use them responsibly.
One final note for enterprise use. It’s generally wise to use hacks that are “obvious”, and to comment on their exact purpose. Otherwise, they become lost in the rest of the CSS and newcomers will be confused, possibly breaking their purpose. It is up to you whether that risk is high enough to justify a design not requiring hacks, although that is still a bit of a holy grail these days if you need to support a wide range of browsers.
thx, useful!
WebKit recently fixed their broken :last-child selector, so the ones above no longer work as they did when they were published.
Changeset: http://trac.webkit.org/projects/webkit/changeset/19528
So now the Safari/WebKit/KHTML selector selects only Safari/KHTML and the WebKit selector selects nothing.
I’ve combined the approaches and found this selector works for WebKit and correctly filters out Opera:
/* for WebKit */
@media all and (min-width: 0px) {
body:not(:root:root) … {
…
}
}
Thank you Chris, I was waiting for them to fix that one
[...] Note: This article may be out of date; please read the version on my personal blog at http://thomas.tanreisoftware.com/?p=11. [...]
[...] 1st, 2007 · No Comments Styling forms is always an interesting task. Just check out how the different browsers like todisplay the form elements. Today I was having a little problem with the input element margins in Safari, among others. I was about to ignore the 2 pixels, but decided to give Google a shot, which immediately brought up a post from the CSS hacks series by a busy coder and blogger by the name of BTreeHugger. [...]
[...] Originally Posted by smallbeer cool cheers. no problem. on this subject this guy has put together a pretty comprehensive list on how to target specific browsers. __________________ hey how do i get one of those signature things? Do you have to have a certain number of posts or something? [...]
[...] Where abstraction into separate files can be really useful is with the use of a reset style sheet and in the use of browser specific hacks. IE6 and IE7 stylesheets can be served based on conditional comments in the HTML, other browser specific hacks should also be in their own files, always included but full of rare selectors. Anything that isn’t part of the core sheet should be separated. [...]
[...] Originally Posted by herkalees Since we’re on the topic, I wrote up a quick tutorial on how to target Safari. I’ll mention that it uses JavaScript, and that’s generally lame, but it’s for those rare cases when the client is extremely picky, and you need the money: CSS Filtering for Safari : Marc Amos CSS hacks series ? [...]
[...] Forrás [...]
[...] On the issue of targeting Safari CSS… I’d be interested to know how consistently the Safari CSS filters mentioned below perform x-platform. CSS hacks series Anyone able to comment/confirm/deny? [...]
[...] Fundort dieses Hacks soll nicht unverlinkt bleiben. Damit macht man sich die ganze Webkit-Menagerie zum [...]
[...] I was about to ignore the 2 pixels, but decided to give Google a shot, which immediately brought up a post from the CSS hacks series by a busy coder and blogger by the name of BTreeHugger.Allthough I have Firefox as my main browser, [...]
[...] buenos como: CSS browsers separation, some “advanced” CSS selectors, (Bad) CSS hacks, CSS hacks for modern browsers. [...]
[...] 알려주신 CSS hacks series의 webkit filter로 해결할 수 [...]
I read your blog in a regular manner and just love it
hope there will be more postings from you, keep on going
greetz, terry
Great work on the hacks - I badly needed one that worked with Safari 3. Grabbed your feed to keep up to date with them. Thanks!
Hello Thomas.
Don’t you know you shouldn’t hack for other browsers.
Anyhow these series of hacks may interest you.
http://css-class.com/test/ie8hack-valid.htm
and
http://css-class.com/test/ie8-XUA-control.htm
I do have to add to the XUA compatible test series the various ways that they can be tested but toggling between the various modes of IE8 via either the emulate IE7 button or developer tools mode switch produces different results.
It’s like the hacks tell the truth all the time.
I’m surprised how often people run into “undocumented features” in modern browsers
It’s tough to manage them, but I figure if one nut online tries to manage it then we can all profit. I’ll have to look into these types of comment hacks seriously again; they are very promising.. thanks!
[...] CSS hack series [...]
The invalid comma hack (for instance p, {color:red;}) is a way o feeding IE 5, 5.5, 6 and 7 with the same targeted rule(s). Has IE8 finaly closed this bug?
@danieldpont: Good question, and the answer appears to be yes (at least in Strict XHTML 1.0 mode). I have not tested with the meta tags or IE7 emulation, but IE7 did of course apply the rule. Here is a link to the test-case I’m using.
The reason it’s not on my list of hacks is because it’s considered invalid CSS, and I tend to not include such hacks where there are alternatives that validate.
@Thomas
Yes those commented hacks has just opens a new Pandora’s box. I have this page up now. Very incomplete but it shows how (u)successful the CSS parser is in IE8.
http://css-class.com/test/bugs/ie/ie-hacks.htm
Some IE teams member have now seen that page, so they may or may not disappear soon.
Thanks with all my heart for the Safari hack !
I love you :))
The Safari hacks is NOT a valid CSS code!
The Safari hack is perfectly valid CSS3. It is not valid CSS2, if that is what you are still aiming for. The W3C validator defaults to CSS2, so you have to select the CSS3 profile. You can use a link like the one I provide under the hack if you must rely on such hacks at all.
[...] : BTreeHugger’s Blog Share and Enjoy !!EN : FR [...]
…right now I’m using following hack to separate Safari 3+ (& Opera):
@media screen and (-webkit-min-device-pixel-ratio:0) {
#menu ul {margin-top: -0.1em ;}
}
the reverse for Opera 9 (or below?):
html:first-child>b\ody #menu ul {margin-top:0;}
is working for me….cheers
Note, it seems that Safari 3.1.1 is picking up your Gecko Hack of:
html:not([lang*=""]) … { … }
I’m worried that none of your Opera hacks work for sites that properly use the lang attribute and have internationalized versions. I got all excited about the ease of targeting and then realized that every international site wouldn’t apply the hacks.
The hack in comment #34 works for Opera 9.27 but not Opera 9.5 beta. The only intl-safe hack you have for Opera 9.5 (head~body:last-child … { … }) is being picked up by Safari Win as of 3.1.1 (525.17)
The Safari hack of body:not(:root:root) is still working as intended.
Has anyone seen a hack that targets Opera 9.5 (entire 9 series would be better) that doesn’t bring in Safari? I can’t use hacks that target both Opera and Safari and then override using the Safari specific hack without adding lots of additional specificity to my rules. That’s fine for now, but almost as bad as having to use all these hacks
[...] CSS hacks series Hacks for various browsers. Via Rusty. to css hacks webdev reference tips howto [...]
@Patrick: Thankfully, yes I do - I’ve been trying to find the time to update this post. The good news is that you can target specific versions of Opera, or just Safari 3, and you won’t have to worry about Konqueror. I have not tested the more minor browser engines but I doubt they will be affected based on the fact that they don’t really support media queries that well. The bad news is that the W3C validator is still not accepting vendor extensions (a bug they have had for years now) which makes it look like the hacks are not valid (they are).
@SSmith: While I don’t see 3.1.1 picking it up on Windows I do see newer versions of WebKit doing so. I’ve found that just adding another selector it works again, and doesn’t break the hack for older versions of the browsers. I just hope the hack doesn’t have to keep growing to accomodate the whims of the WebKit team.
@thomasb: Thanks, that gave me a couple of ideas that make Opera hacking a little cleaner.
It seems, that the Safari2 hack: html[xmlns*=""] body:last-child … { … } can be read by Oper9.5
useful info here! thanks a lot! [bookmarks] [pushes "I like it!"]
Nice. I was looking for some Opera hacks. I wish every browser vendor could have the conditional comment like IE. The IE browser brings us developers a lot of pain, but at least MS has admitted it and brought us the condidional comment. I would like this for Opera and Safari as well (and others). This brings us a much cleaner world
Anyway, thx for great tips and tricks to get around.
Thanks Andreas, I didn’t notice that the first of the Safari 2 hacks is now Opera-friendly as well. And yes, Ronny, I think we can all agree that browser vendors should all slip in simple selectors that make it easier for us to give clean hacks. I’ve written about this time and again, but no one listens. Apparently it’s just too much work on the browser vendors or something. I honestly cannot think of a reason to *not* have them, but who knows? Even Microsoft dropped the ball by not letting us comment out sections of a CSS file, but there were enough well-known hacks that made up for that.
[...] Via: tanreisoftware [...]
[...] man mit CSS-Hacks oder Conditional Comments ein Fallback definieren und auch für Opera gibt es passende Hacks. Wenn modernes HSLA-Grün nicht funktioniert, bekommen die Nutzer von Opera und Internet Explorer [...]
Really the only safe hack to use are browser extension hacks much like IE’s conditional comments. Firefox has -moz, safari has -webkit. These combined with media queries creats a sure fire way to target that browser and only that browser.
I’d love to agree with you, Neil, but it’s simply not true. For instance, Opera 9 to 9.2 apply media queries that include non-standard attributes like -webkit-min-device-pixel-ratio. Also, the Playstation 3 and other browsers will apply Internet Explorer’s conditional comments. So technically, it’s closer to the ideal situation but it’s simply not true enough to be “safe”.
It’s a shame, too. Technically we should be well beyond the point where such hacks are even necessary, but for those hard-to-fix problems and deficiencies, we still have workable CSS hacks. Thankfully I have only found them necessary in highly complex layouts, and even then only in very rare cases. By the time IE8 is adopted I doubt such tomfoolery will be necessary.
Thanks for offering this info… though I am ashamed to say that I don’t understand how to apply the Opera hack:
Target Opera 7.2 up, 9 up, or 9.5 up:
@media all and (-webkit-min-device-pixel-ratio:10000),
not all and (-webkit-min-device-pixel-ratio:0)
{
/* 7.2 up */
head~body … { /* 9 up */ }
:root … { /* 9.5 up */ }
}
Can you use an example? Not sure how much of the above is part of the hack and how much is suppsoed to be substituted with the actual values.
I am trying to change a div for Opera only, also trying to find a hack for Firefox 2.0–my dropdown nav is working in IE7, but not in either Opera or Firefox, and is slightly different in each of those…
Thanks!
Basically, you group all the Opera-specific styles into the media query. In that query, all rules are then normally applied only in Opera 7.2 and higher. However, by beginning one of those rules with head~body, only Opera 9 and up will see it. Likewise, beginning it with :root will ensure that only Opera 9.5 and higher will see it. You can start by making your normal rule, and then just prepend the bits I’ve mentioned.
For instance, let’s say you want to replace a bitmap background with an SVG one. The basic rules would look like this without the hacks yet applied:
/* All CSS-capable browsers should see the bitmap */ #my_element { background-image:url("image.jpg"); } /* Opera 9.5 should see the SVG */ #my_element { background-image:url("image.svg"); }Now, we just have to wrap that up in the rather nasty looking hack to get it working:
/* All CSS-capable browsers should see the bitmap */ #my_element { background-image:url("image.jpg"); } /* Opera 9.5 should see the SVG */ @media all and (-webkit-min-device-pixel-ratio:10000), not all and (-webkit-min-device-pixel-ratio:0) { head~body #my_element { background-image:url("image.svg"); } }And that’s basically it. Of course, you can group more rules in the media query, so you could technically have one section in your stylesheet that handles Opera 7.2 and higher, with rules that begin with the appropriate selector to activate the hack.
As for Firefox 2, you will have to apply your hack first to Firefox 2 and higher (Gecko 1.8 up) and then reverse it for Firefox 3 (Gecko 1.9 up). It would be nice to not have to do this, but sometimes that’s the way it happens. Here’s an example:
/* First hide an element in Firefox 2 and higher */ html[xmlns^=""]:not([lang*=""]) #my_id[id="MY_ID"] { display:none; } /* Now reverse the above in Firefox 3 and higher */ html[xmlns^=""]:not([lang*=""]) #my_id:not([id="MY_ID"]) { display:block; /* or inline, or whatever */ }