There’s so much great stuff written about web standards available for free on the web that it’s easy to forget how much bad stuff is also out there; and how many people are willing to support it just because it’s easier than putting in a little extra effort to follow best practice.
Over the weekend one of the most popular stories on Delicious.com was teaching the use of lazy CSS hacks, the type of which I thought everybody was convinced enough to do away with; the star and underscore hacks for targeting IE6 & IE7, the hacks which we’ve been saying (for years) shouldn’t be used anymore.
Disregarding the ‘rights’ and ‘wrongs’, and the validation argument — some of my stylesheets don’t validate, and there are good reasons for that — I’d like to give a few other reasons why using this method is not a good idea.
First and foremost, maintainability; separating out the rules for outdated browsers with conditional comments leaves your standards-compliant stylesheets clean and easy to manage; you don’t have to wade through multiple rules looking for the ones you need. IE6 & IE7 styles are safely out of sight.
Second, and one of the core arguments for not using hacks, is future-proofing; using a hack like this in the main stylesheet could lead to a situation in the future where a new browser — or new version of a current browser — could render this hack incorrectly. It may not be likely, but can you guarantee no future browser will not render strangely when interpreting these rules?
As well as practical reasons not to use hacks, there is one good moral reason: to not be lazy. Writing the syntax for conditional comments takes less than a minute, and while using hacks means there is some reduction in the number of characters required, complex stylesheets can contain dozens — or even hundreds — of rules, and adding those hacks for each rule will mean you end up using almost as many characters as you would with conditional comments.
It’s pretty disheartening to see comments that suggest standards are just for people who want to sell books or conference tickets; standards are to make the jobs of web developers easier. Even the lazy and bone-headed ones.
It still surprises me that there is no formal qualification for web design to try and at least get people in the industry qualified to write HTML/CSS to the standard.
Whether it would help with this situation or not, I’m not sure but in every other industry there are standards that MUST be followed and qualifications that MUST be obtained before you’re allowed to operate machinary or work on products that are going to be used by the public.
Sadly, without a formal qualification, I think we’re likely to see people in so called professional positions still creating websites that amount to DIY jobs.
Things have come along way with web standards over the years but in my experience a lot of big companies still see HTML and CSS as something easy that their web developer or graphic designer can do and not a specialised position in its own right.
Regarging the comments you mentioned…
Wow, it’s a bit scary when people can’t see the value in their own industry having “standards.”
I suppose that’s what separates the men from the boys in web design and development. Surely you can’t get that far career-wise when your motto is to get the job done quick and dirty..?
As I wrote the article to which this article refers, I feel I should respond:
1. Maintainability: I argue that it’s easier to maintain side-by-side CSS rules in 1 file than having 3 files side-by-side.
2. Future proofing: Hacks don’t break other browsers in 99% of cases. This is an idealist argument riding on speculation and fear that standards may not be as viable a business argument as hoped.
Additionally, the concept that IE 9 might break because of hacks addressing IE 6 is absurd. I have stopped supporting IE6 completely in my websites and IE8 hasn’t even begun major adoption. We’ll stop supporting the hacked browsers before we’ll be supporting these supposed “future browsers”
3. Laziness can’t be confused with efficiency. I know I say “lazy” in my article, but it really comes down to efficiency in action. To not do what is quickest on such a trivial issue is to waste your employers time, your customers time, and your time.
@Dave: In the Netherlands a grassroots movement led to the creation of Fronteers, a professional association which gives accreditation to members. I would love to see that expand to more countries.
@Marie: — and the women from the girls, of course ;)
@Brian: Even Microsoft themselves have asked developers not to keep using hacks. The reason you use them is to save you time, not your customer; they pay you a lump sum, I would presume. Using hacks is cutting corners, and it’s not professional.
What saves me time saves my customers money.
This is a comment I posted on Andy Clarke’s site, I suppose it should go here though:
I’m not convinced these reasons are all that important. Take Yahoo for example, they prefer hacks over conditional comments as it cuts down on requests and keeps the hacks within context rather than separated away in some other file to be maintained. Keep in mind how big Yahoo’s website is, maintainability and future proofing are extremely important yet it hasn’t exploded in a ball of hack flames. Their frontend dev dept aren’t a bunch of dimwits.
In fact Yahoo’s Nate Koechley discusses the subject amongst many others in this video: http://video.yahoo.com/watch/4671445/12486762
Personally I have started using one CC style sheet for both IE 6 and 7 and use hacks within to target either browser. Sites I work on aren’t huge so separating into other files isn’t an issue and using hacks within an IE specific file isn’t likely to be a problem in the future either. Keeping it all in one file + hacks rather than two sans-hacks is a nice compromise.
Keep in mind the old-fashioned use of the word “hack”, which applies to things like “a worn-out horse for hire” or “Ooe who undertakes unpleasant or distasteful tasks for money or reward.” It’s strange that to be known “a hacker” lends one a certain je nes se quoi, but to be “a hack” generally means that one is not top quality.
I just don’t think it’s professional. Obviously not all “hacks” are created equally and there may be some situations in which the benefits outweigh the consequences.
CSS hacks, to me, are the sad result of the browser wars and of the demands of hundreds of unprofessional designers. During the browser wars, being the holder of code snippets which targeted deficiencies in IE and Netscape to work cross browser was laudable. Too many searchers aren’t looking to understand CSS and layout engines, they just want to find something that they can copy and paste which will quickly fix whatever problem they’ve encountered. They aren’t thinking about the future and they don’t understand the principles that a professional holds dear.
Which is not to say that a professional can never use CSS hacks when s/he has an informed and justifiable reason for doing so. There are so many considerations that I don’t think any real-world project can ever uphold every ideal of usability, accessibility, validation, maintainability, reusability, technical rigor, artistic expression, etc. It’s important to get as close as you can, which means carefully considering and weighing the consequences of doing something a-little-less-than-ideal here or there.
But that doesn’t mean that the distribution of CSS hacks as if they are the only answer to CSS problems is “good advice” — it’s terrible advice.
And I see ample evidence of that in my day to day work. View the source of designs produced by professionals in my company (professionals whose work and opinions are valued above my own) and you will see completely unnecessary CSS hacks. These designs could be reproduced the sans-hacks with about 2/3rds of the code.
But the hacks skyrocket to the top of the search engines due to people looking for easy solutions.
I might be wrong but “The star html CSS hack” is targeting IE6 only. So, provided link is not correct.
Also, re Future proofing, till all browsers render CSS rules correctly, I don’t think we can’t get rid of hacks.
I don’t agree entirely. If you only need 5/10 lines to fix IE issues, should you really add another style sheet? One more request for your server for just 5 lines?
And If you use conditional comments, sometimes you need to make specific browser styles for IE6 or IE7, and to do that, you must use hacks.
I really can’t help using hacks in projects that need to be IE6 / IE7 compatible…
@Ignacio:
“If you only need 5/10 lines to fix IE issues, should you really add another style sheet? One more request for your server for just 5 lines?” — If your site is so small that only 5/10 lines are needed to fix IE6, I’m sure your server can take the extra hits. Yahoo and Google use invalid stylesheets, don’t close some tags, put the whole markup in one line, etc, because they serve to millions of visitors per day and the costs involved are phenomenal; you don’t have that excuse, I’m sure.
“If you use conditional comments, sometimes you need to make specific browser styles for IE6 or IE7, and to do that, you must use hacks.”
Nope. One conditional comment for IE6, one for IE7.
I think the selector hacks (* html and *:first-child+html) for IE6 and IE7 are perfectly acceptable. They do not make your CSS invalid, and they target rules specifically to two browsers renowned for their disregard for standards. These selector hacks purposefully target quirks specific to those two browsers. For experienced developers, very few style sheet rules require adjustments for IE6 and 7. It seems unnecessary to require the extra requests for a handful of rules, and I know from experience that it makes maintenance a nightmare in a shop with multiple front end developers, or even for a single front end developer. Keeping all of the rules together makes for less requests, easier maintenance, faster creation, and doesn’t kill any kittens.
I would never use any of the underscore or / hacks in the middle of the definitions — those are ugly and invalid, and seem dangerous for future-proofing.
Personally, I think the best overall approach is to use IE conditional comments to write the <html> tag — using the comments to add a class of ‘ie6’, ‘ie7’ etc. to the html tag. Then that class can be used to target rules for a specific browser without resorting to hacks or separate style sheets. The drawback here is that it only works when the developer has enough control over the markup to do so — which isn’t always the case, unfortunately.
@Peter
Or one conditional comment for both ;)
This conversations seem to run in circles. Personally I prefer an extra stylesheet for IE6.
I think the real question is industry certification, why shouldn’t the web development world have certification tests. the certification standards may be hard to develop, but I feel the end result would help both the client (a small measure of confidence added) and the development community by creating an industry wide barrier to entry, which should help cut down on the fly by night types that are rampant in this industry.
Sorry a little off topic but that’s my 2cents.
Using hacks, and then attempting to defend them is the only nature human thing to do. I would be embarrassed as well. Stop hurting the web…
[…] course there are arguments for and against developers using […]
I disagree.
1. I agree with Brian on the first argument. I find my CSS easier to maintain when I solve my problems where they occur, using these hacks, rather than splitting them off into separate files.
You say , but I’m not managing the CSS for modern browsers; I manage it for all supported browsers, including IE6 and IE7. The only time you might be saving here is the time it takes you to remove support for IE6/7, and a search-and-replace to remove the
_and/or*rules is hardly any more work than deleting the relevant conditional comments and files.In the mean time you’d have to carefully comment your main CSS file, referencing all IE fixes, to prevent you from accidentally breaking your site in IE when you make any changes to the main CSS. (You do that, don’t you?)
I sort my properties alphabetically, and I don’t think I’ve ever needed more than a few hacked properties (per ruleset) for IE; hardly any wading.
Why would you want them to be out of sight when you need them for your site to work on the browsers you support? If you don’t support IE6/7, fine, but then you wouldn’t be using any hacks or separate stylesheets in the first place.
For example, the IE6 stylesheet on this site seems to be outdated and become unnecessary since neither of the IDs mentioned in it actually occur on your site anymore, as far as I can see.
2. Secondly, first you say , and then your second argument is “future-proofing”. I don’t see how this can be about anything other than validation.
You’re only partly right with this argument.
The CSS 2.1 spec says this about valid stylesheets:
If you look at the grammar of CSS 2.1 you’ll find that it is perfectly valid for a property to start with an underscore. So the only thing that makes those properties invalid is the fact that they’re not defined. But that is no different from the vendor-specific extension such as –webkit– or –moz-, and technically all CSS3 properties that haven’t reached the recommendation state yet.
In fact, the current draft of the CSS3 Syntax module defines the underscore as a vendor-specific extension as well. So whatever it may be, it is certainly future-proof.
The same can not be said for the
*, though that same Syntax draft also says:So it should be safe to use, though clearly illegal.
But there is an alternative for the
*: you can use “\” instead.E.g.
body { background: green; \ background: orange; _background: red; }, which will turn the body green in all standards-compliant browsers, orange in IE7 and red in IE6 and before.The “escaped space” construction is valid according to the CSS grammar, so it is future-proof (so long as they don’t start adding properties starting with an escaped space), and as far as I’ve tested works the same as the
*hack: I tested it in IE6, IE8 (in IE8, IE7 and Quirks mode), Firefox 3.5, Firefox 2.0, Safari 4.0, Opera 9.6 and Opera 10 (beta 3) and only triggers in IE7 and IE6 (and IE’s quirks mode).3. I think Brian already addressed well enough.
Also, in your reply to Brian, that IEBlog post you link to does not actually go out and say developers should stop using hacks altogether. It asks developers to look at the specific hacks they mention in that post, because those targeted IE6 by relying on bugs in its CSS parser which were fixed in IE7.
Finally, none of this means I never use conditional comments or always think using the underscore/star/escaped space hacks is the best solution. I just use whichever I find most appropriate.
In most cases I’ve seen, hacks weren’t necessary. It was just easier to insert rather than provide a better layout or, what I find most often, being more explicit in related declarations. I recently chased after one in a design in making a print css for my pages. I started to use a hack then realized that all that was needed was to add an additional property to be more explicit to the class. No hack was needed, just better written CSS.
Unfortunately, some institutions are still using IE6 (my wife’s workplace with 2000+ employees) and have to have pages that will display properly in them. My solution has been to do designs that “work” (degrade gracefully) in IE6 but shine in everything else.
I’m not convinced totally of the maintainability argument you pose. One could include their main CSS references to CSS files unique IE versions containing only hacks and delete the unique files as time goes on without having to update all the pages that have the conditionals. The problem with this approach could be argued that one has to remember to delete the appropriate browser version file when the time comes. One wouldn’t need to remember to do anything with the conditionals.
Your maintainability argument does become more justified when the author isn’t going to be the one that maintains the css. Trying to understand somebody else’s approach in the use of a hack to solve some issue can be easily confused with something that wasn’t intended as a hack at all. Conditionals remove this ambiguity as well as the need to remember to remove browser specific sheets outlined in the previous paragraph.
I’m just glad I don’t have worry about IE3 :)
While I agree with the gist of this post, I think the blame should be shifted from where it’s currently being placed (“you shouldn’t use CSS hacks”) to where it rightly belongs (“you shouldn’t NEED to use CSS hacks”). It’s easy to be an idealist about web standards when you don’t have clients blowing up your phone about how awful your work looks because they don’t know how (or care) to install a simple automated update. And it’s certainly not MY job to GUARANTEE that Microsoft isn’t going to do something absolutely braindead in a subsequent version.
TLDR: Until there’s no longer such need, bad browsers beget bad CSS. Simple as that.
ToastyGhost is right on the money. All of the idealists complain about bad development and the fears associated with future proofing (that it may look bad with an update), but there are no standards in the browsers themsleves. Until a set of standards is strictly adhered to in the browsers themselves, no set of standards can claim the term “professional”.
Some people compare web development to other industries/ technologies, but forget that those industries are a little more contained than web development (rendering at least). If you are trained to fly an airplane it is for a specific type of airplane, not airplanes in general. Yet web developers are expected to render sites in 7 (or more) browsers, despite the total lack of adherance to standards.
Conditional comments themselves feel like a hack to me — you’re not using comments as specified. At the end of the day, who are you making the site for? Do you have a heirarchy? Mine is my employer, the public, myself, then the development community.
P.S. fewer http requests = smaller carbon footprint (lame, I know)