CSS Hacks -- Your Take
November 24, 2003 | 
16 Comments
There has been quite a lot of talk lately about CSS best practices, keeping CSS simple and various fancy new CSS hacks.
I’m curious to know my reader’s take on CSS hacks. To be honest I avoid them if at all possible and tend to look to them as a last resort, but it depends on the project. I don’t usually worry too much about IE5 (shame on me?), but I do test with it and luckily haven’t run into too many “hackable” problems anyway. Those that I have run into have been killers, but I’m getting off topic a bit.
Anyway, I tend to assume that isn’t almost impossible to eliminate browser display issues completely and would hate to use a hack I’d later have to remove.
I think this is something born out of many years of having to rework code to work with yet another new browser. I just got to the point where I realized that no matter what I didn’t I was going to have an issue in some browser somewhere.
I understand that many, like myself, might not have an hard and fast take on this issue. I mean it could very well depend on the project. With some work you might have more flexibility with your layout and the browsers you are supporting.
So what is your take on CSS hacks?
Filed under: Web Development
Comments
1. Scrivs said:
If you need em use em. Down the road when the crappy browsers get phased out then you can simply remove those few lines in your stylesheet and life still continues to move.
Posted on November 24, 2003 12:34 PM | #
2. Michael Heraghty said:
I can see your point of view but, in the case of CSS, I think hacks are a must.
This could be a question of semantics though. For me, “hack” in this context simply means “workaround” – i.e. using CSS in a way it wasn’t entirely intended (or in a way that isn’t listed in the standards docs) in order to achieve an end result in the browser.
For me, effective web design has *always* been about workarounds, or hacks if you like. After all, even the use of *tables* is a hack – they were intended to display tabular data, not to lay out the page.
Similarly, in CSS, there are some precautions you have to take to avoid those “killer” bugs in different browsers and versions (and CSS bugs are way worse than HTML bugs).
I don’t think that hacks “later have to be removed” either. All my old HTML workarounds (transparent gifs used for spacing, etc.) still work – it’s just that I don’t need to use them any more…
Having said all that, I would prefer if we didn’t have to find workarounds all the time. But if that were the case, we’d be living in a world where things actually work the way they’re supposed to. And that doesn’t sound like the world I’m familiar with ;)
– mike from media junk
Posted on November 24, 2003 12:41 PM | #
3. Keith said:
Well, at the risk of inciting a semantically debate, I have to say I heartily disagree that CSS hacks are a must.
I’ve got quite a few hack-less designs that look and work great. But then again it depends on how you define “hack” and how you define “must”.
I do get your point though.
As far as removing deprecated hacks – and this goes for html hacks like spacer .gifs, probably even more so – you could leave ‘em, true enough. But just because you could, doesn’t mean you should.
Also – If you’ve ever had to convert legacy content to (X)HTML + CSS you know that HTML hacks can be a real pain to clean out.
I will agree that most CSS hacks would be pretty easy to get rid of.
Posted on November 24, 2003 12:50 PM | #
4. Mark Trammell said:
A timely question for me, Keith. I’m in the throes of a site design for my university and have been officiating the battle of pragmatism vs. standards. I’ve come to the decision that to best serve our clients (the university community), forward-thinking design trumps rattling the cage of late adopters. That said, I am employing the occasional hack – namely an empty span cover up as opposed to FIR for accessibility and non-image viewing. Deus ignoscat.
Posted on November 24, 2003 01:08 PM | #
5. ste said:
Like you said, I don’t think there’s a one-size-fits-all solution in this case. I will admit, however, that I @import all of my stylesheets these days because Netscape 4 is really no longer a viable option for designing (and I’m fine with the content being accessible without being pretty). Other than that, first I try to code my CSS to be well-formed and valid, and if something is terribly wrong then I will try to find a way around it if a way is possible without too much hacking.
Posted on November 24, 2003 01:24 PM | #
6. ste said:
Hrm, it occurs to me that there are two potential definitions of hacks - the kind generally meant to filter out (or in) certain browsers (like the high pass filter) and the kind meant to expand the abilities of CSS in general (like FIR). I’m all for the second kind, which I don’t see as hacks so much as a natural progression that would occur in any language (programming or otherwise). The others, on the other hand, I see as oft-necessary evils that, were this a perfect world, would be unnecessary and even frowned upon. ;)
Posted on November 24, 2003 01:31 PM | #
7. patrick h. lauke said:
my pragmatic take: what’s more likely not to change over the next few years, i.e. what do i want to keep as clean as possible ? in most cases, the answer for me is “the content”, the xhtml. the css, on the other hand, is likely to be adapted a lot more often in the months/years to come (especially when we’re talking about archived content which won’t change, but may have to fit in with a new look/feel on a site).
now, if i need/want to make it display at least reasonably well in most browsers, i try to keep both xhtml and css and clean as possible. but when push comes to shove, i’ll only every touch the css. if i introduce any hacks, they’re a lot quicker to remove at a later date than when they’re built into the actual xhtml.
but of course, if there’s a way of getting around display issues without having to resort to hacks, then i’ll go with that, yes.
Posted on November 24, 2003 03:16 PM | #
8. Michael Heilemann said:
If a hack is taking advantage of a bug I’d rather not use it. Then I would prefer working my design around the bug rather than sidestepping the standards.
Posted on November 24, 2003 04:03 PM | #
9. dez said:
I’m still on a CSS learning curve. I started off thinking hacks were just par for the course but the more I learn the more I realise that they are not always neccesary, it just depends what you are doing (eg. avoiding Box Model hack by applying padding to parent element). It’s part of a mindset shift that I think comes with tabeless layouts and that I am starting to finally get I think. So I’ve decided to try to begin a new layout with the mindset of trying to avoid hacks altogether and if I use a hack to try and apply the process of justification for the choice - is this neccesary? what will be lost without it? etc.
Posted on November 24, 2003 06:25 PM | #
10. Christian said:
In support of the “avoid CSS hacks” camp I would also put forward the argument that they make your code harder for others to maintain. One of the benefits of CSS and tableless layouts is that (alomst) any developer can look at the code and see how it works. Using (potentially) obscure and complicated CSS hacks makes that less easy to do.
However, I must say that I am tempted by the underscore hack for solving that blasted WinIE min-height problem…
Posted on November 24, 2003 09:08 PM | #
11. TOOLman said:
I don’t like CSS hacks, but sometimes I have to use them anyway. There’s this fairly popular browser that you can’t really ignore, and it gets most things wrong. ;)
The one important thing for me, when deciding whether or not to use a CSS hack, is that it validates. If it doesn’t (like the underscore hack) I won’t use it. Filters are OK, especially for hiding stuff from old browsers (high pass filters) whose bugs we know will never be fixed.
Recently, I’ve taken to putting the IE workarounds in a separate style sheet, linking to it within an IE conditional comment. Absolutely valid, safe, and I don’t have to burden real browsers with junk rules.
There’s another kind of CSS hack that I find more questionable, though. That’s when you use CSS to fake things that you cannot normally do. FIR and “sliding doors” is OK, I guess, as long as you take accessibility and graceful degradation into consideration. Inserting empty divs with two wide borders just to get a more “interesting” corner, while fun in a geeky kind of way, really is just a hack. To me, it’s like using tables for layout: you use an HTML element for something for which it’s not indended. (I know, we want to create nice-looking bleeding edge web sites, and the current tools are inadequate for our needs, but I still think it’s a perversion.)
Posted on November 24, 2003 10:35 PM | #
12. G. I. said:
CSS hacks are your best friends.
Posted on November 25, 2003 12:15 AM | #
13. Dave Meehan said:
To hack or not to hack comes down to how the ‘designer’ understands ‘development’. Most hacks come from specifying something that can’t be done in one of the target browsers. Your at risk of lowest common denominator syndrome I know, but thats the price of poor quality browsers.
My goal is to always produce valid XHTML and CSS. Without valid code, browsers will always fight to understand what you meant. If your code like crap in a certain browser, maybe you’ll encourage a few people to upgrade to something that works. Possibly the best solution is to always ensure that there is ‘no layout’ mode (i.e. no CSS) so you get pure markup. As long as you’ve created valid XHTML with appropriate use of basic HTML tags (headings, lists, tables) the site will always be accessible, which is the best you can hope for, on any browser, on any platform (if it don’t, the browser is unquestionably broke!).
Hacks cause solutions now, and problems later. IE can never fix the CSS parsing bugs because people have made hacks out of them. All IE users won’t upgrade in a day, so how are you going to cope if MS do fix those bugs? Hacks consign us to repeat history.
Posted on November 25, 2003 01:38 AM | #
14. patrick h. lauke said:
just to clarify: the only hacks i use (and condone) are the ones that still make the css validate. i also shy away from overly convoluted ones (the ones involving weird slash escaping of characters etc). the voice-family hack is one of the few I often use, to be honest…
Posted on November 25, 2003 03:46 AM | #
15. Andrew Bowden said:
What do you define as a hack? I see two levels of hack - low level hack (use of unsupported features like using an @import to call CSS) and high level hacks (anything that uses obscure and strange, but usually valid, markup in odd ways - Tantek etall.)
Low level - I use all the time. it makes sense to use an @import to hide from Netscape 4. It’s also an established precedent in that any new browser will know that having @import support will have to have a certain standard of CSS support.
High level - I avoid like the plague because you simply can’t rely on them. They’re often obscure and klunky and aren’t guarenteed that future compatability. They are usually unneccessary (there are ways round using them) and pose too many potential risks for the future.
Posted on November 25, 2003 09:02 AM | #
16. Andrew Bowden said:
I also agree with Dave Meehan - high level hacks are dangerous and will cause problems later.
Posted on November 25, 2003 09:04 AM | #
Comments are now closed