9 Expert CSS Ideas You Should Think Twice About Before Using

I can't get behind "transparence" as a word appropriate for the article you're talking about.

But other than that (which isn't even your fault), this is a great article, and I agree with everything you're saying. At one point in my life I'd even have considered "Digging" this article, but you know, things happen.

There's all kinds of scary advice out there for the aspiring css coder.

I disagree on some points. Most notably, a common CSS library that you can use as a framework for a project is definitely a good idea.

For instance, almost all my projects will utilize an un-orderd list in a div tag with id PageHeader as a navigation element. Similar for main content nav (PageContent) and footer nav (PageFooter). As such, I have a starting point CSS template that includes predefined values to automatically make the bulleted list a horizontal listing of links.

From this point I can apply the styles appropriate to the situation.

I do agree with your example though, make your library of helpful rules apply to "objects" like "articles", "titles", "navigation", etc. rather than specifics like "width100".

I have a few staples like "twoColumn", "threeColumn", "rightPhoto", "leftPhoto", etc. that all apply some common and reused attributes I need. For instance, I almost always want a "rightPhoto" to float right and have a left, bottom, and top margin but no right margin...

* Nitpick ** Also too lazy to go read the original article since it came from the "Evil of Evils" (digg) and most of the things that make it there aren't worth my time... I'd much rather have someone sift through it for me and just read their blog :-)

@Errol

My rebuttal on Section 1.1 didn’t really have to do with the concept of having reusable CSS, but more about the example implementation. However, I think that most of the time reusable CSS gets into the territory of presentational names instead of description of the content.

Using presentational names for CSS classes gets you into the territory of editing your HTML to change presentation, and really, going back to embedding presentation (via class names) in your content.

Let’s say you decide that the photos showing on the top right of each page would look better on the top left. Since you used rightPhoto, you now have to change every page that has a photo on the top right to leftPhoto. Then a day later you change your mind, and you have to reverse it. If instead you used calloutPhoto, you could flip them back and forth without any effort by changing “left” to “right” in your style sheet.

Obviously there are times when rules can be broken, however it is best to teach the “right” way.

I agree.

Also though, I'm almost always dealing with dynamic presentation where I use a style such as rightPhoto and leftPhoto because the document requires it.

Again though, it is certainly possible that twoColumn and threeColumn would need to be changed, that's considerably different. And something that a nice grep can't fix.

My point is more that libraries are a good thing.

While you have me on the subject though, I will simply say that true separation of content to presentation isn't plausible with the tools we have available.

Sometimes an article just looks and feels better when an image is to the right or left... and currently there is no way to handle that totally separate from your content unless you use ids within CSS... which I think shifts the focus away from where it should be.

Ideally this is exactly what you would do, but in my humble opinion, writing CSS rules for every specific image on a page would be totally counter to the spirit of CSS.

I'm not saying it's impossible, simple implausible...

BTW, just a friendly disagreement. I'm trying to spur conversation rather than argument.

That'll be a Digg then.

Good, common sense stuff.

Like Errol, I also think it's very difficult to get a complete separation of style and content; I don't think it's practical with the tools and technology we currently have. What we do instead is to get as much separation as we possibly can, and work towards a time when it's truly possible.

@Peter & Errol

I think it is always worth shooting for complete separation of of content and presentation. With the state of the web as it is, we are hindered by all sorts of things including inadequate standards, browsers that don't support standards, proprietary extensions, etc. These things will prevent us from reaching web development nirvana.

If you look at my work, I’m sure there are many times when I have not written the most semantically correct code. However, with every project I strive to reach the goal of separation, and each project is easier to maintain and understand for other developers.

So, instead of presenting lists of “expert ideas” that don’t strive for the best, let’s instead try to teach the “proper” theory. Then when developers have a good understanding of the ideal approach they will be more equipped to break the rules when they must.

I’ll liken this approach to the average Computer Science undergraduate degree. If you get an MS in CS, you probably don’s know all of the latest programming languages like the back of your hand, but you know the theory behind programming languages in general. Once you graduate it is really easy to identify well structured programs and languages and you can learn new technologies in much less time.

If the “rule” is to completely separate content and presentation, then maybe we will get to the 90% mark, but if we aim for the 90% mark, we are more likely to reach 80%.

Apart from Dean Edwards beiing a genius in some parts - Why should i be using Javascript to counter IE CSS quirks. That's like using the wrong tool, for the right job.

Don't use hacks, agreed. Use IE Conditional comments instead. Some might not consider them standards compliant, but that is a rather wry case to argue. Otherwise the work just fine, since only IE knows how to read them, and all other browsers. Also this way you can target any version of IE easily.

@Melianor

I’ve seen the issues you brought up on the reddit comments also, so I’ll go ahead and address them now. In general I would not recommend using javascript to fix lots of rendering issues, however the IE6 situation is not a general case. For instance:

• IE6 has been improved upon by IE7 and it is not longer the latest version. IE7 fixes most of the problems the IE7 script addressed. (the script does support a number of CSS selectors that the real IE7 does not, but most of those selectors aren’t supported by Firefox, Opera or Safari)
• IE6 is being surpassed in percentages by IE7, and that margin will only continue to grow with time
• The script IE7 makes it so you only have to maintain one set of CSS code
• The number of users of IE6 who are technologically advanced enough to find and disable javascript, who have also not yet installed IE7 is very likely minute
• Even if every IE6 user did turn off javascript, the difference would be they would see a gray background for some transparent parts of pngs, and a few elements on the page would be styled improperly (I personally don’t use pngs, but instead I prefer to take a different presentation approach)
• You can’t replicate the advanced pseudo selectors, pseudo elements, attribute selectors, etc in your conditional comment CSS files without adding class selectors to your HTML, and possibly even more HTML tags. This is even more important if you are styling dynamic content.
• The IE7 script allows you to often times greatly reduce the number of tags and classes you use in your HTML

As a web developer you are always going to have to make a choice about diminishing returns, and what it makes sense to support. From my point of view, the IE7 script is a no-brainer. With it we open up a whole host of powerful CSS selectors that make programming more enjoyable, and we don’t need to worry about all sorts of pesky limitations that only IE6 has. Unfortunately we can’t yet completely drop support for IE6 like we have for IE/Mac, but hopefully that day will come soon. Until then I am going to be using the IE7 script to fill the gap.

Also, just to let you know, the IE7 script is recommended to be loaded via conditional comments, so it targeted the same was as CSS inside of conditional comments. If you are interested, check out this page’s source to see how we are using it. Granted we are using a slightly modified version, but that is another topic for another post.

Your forgot the one about adding borders to all divs, see my comment at Smashing Magazine.

I agree with everything but Section 1.3: Keep selectors to a minimum. (since the advice was originally mine, I feel the need to defend it!) You haven't really explained how it'll save time in trouble-shooting. For example, you've got ".classname ul li a". but LI's are already in UL's... why do you need to specify it? How does that save time? For each level of specificity, you're continually adding more and more selectors to override previous items. For a web site, this probably isn't as big of an issue but when you start getting into web applications where the markup structure tends to be more complicated, needing long lists of useless selectors is troublesome, to say the least.

But like all advice, to each their own. To consider any of the advice here or in the original article or my site (or anywhere for that matter) as the one and only way to approach a problem is short-sighted. Take what works and leave what doesn't.

@Jonathan

Hey, great to hear from one of the original authors!

My examples really aren’t 100% flushed out for the sake of brevity, but I’ll bite on the ul li a issue. I really should have specified that I wanted unordered list with links to be styled a certain way. If I left the ul out, I would also be applying that style to ol tags.

Most lists of links tend to work really well semantically as unordered lists, and often times we want to style those links differently than normal links. For instance, the footer of this site includes unordered lists for the Links and About iMarc blocks. So if I had just applied the style to .footer_block li a, I could potentially screw up an ordered list one of my fellow co-workers might put in their about blurb.

Really, the argument I had against your point is probably the weakest/least important of all of the ideas, but it is great to have this dialog! I think probably the most important thing to ascertain from your idea is that specificity can be tough to track down.

Plug: My favorite tool for dealing with such things as CSS specificity issues, cascading, etc. is Firebug. For anyone out there who hasn’t seen or tried it, I strongly urge you too! It only works in Firefox, but it will get you 99% of the way.

Hi, interesting post.

I kind of disagree with this:

"Better advice is to make sure you include a meta tag with your actual character set."

Well, sort of, but the best advice is to make sure that EVERYTHING you use, editor included, be set to UTF-8. Trying to deal with multiple encodings is a ticket to guaranteed headaches. Just make sure everything is UTF-8 and forget about it.

If your editor can't handle UTF-8, your editor is broken (nowadays very few editors are broken in that way).

It's also important to make sure that your webserver is actually sending UTF-8. This is actually a pretty pernicious and hard-to-debug problem -- I for one have been bitten by it. There's some good advice about how to do that for Apache here:

http://www.cl.cam.ac.uk/~mgk25/unicode.html#web

Really nice, I didn't know "Dean Edwards’ IE7 script" it's very useful, thanks!

Re: the IE7 script. 1. It slows down the page load for IE6. The page renders its true CSS as the page loads, and then goes through and applies the IE7 "fixes" once the page is loaded. So if you really use the selectors as they are meant to be used - to get presentational muck out of the HTML - then the user will see a half second or more of "real ugly" before they see "real pretty". Dialup users will be especially inflicted with "yucky". 2. Is it really necessary to send any extra K's worth of javascript to do something you KNOW you can do in IE6 even if you can't say "h2 + p" and "#menu li:first > a"? 3. There will always be a significant percentage of IE6 users because it is the latest IE browser you can get without Windows Genuine Advantage. There are alot of folks on the planet with illegal installs who can't get IE7 until they buy Windows.

Re: 2.5, the degradation of hacks for PNG transparency, min-height, and min-width. Gone are the days of /\/ this and that for IE5/Mac, being nice to Opera, IE box model Tan hacks, etc. Instead, code for Firefox, use the Firebug, and have fix files for IE6, IE7, and Safari. Challenge yourself to put nothing in them but PNG filters, min-height fixes, expression for min-width - at least until the night before the project is due and it's the only way you'll get the *** thing to look right in IE6 and still get some sleep. You can be confident that those IE6 hacks won't degrade over time because IE6 won't be changing any more.

Better living through javascript :D

Better living through javascript to be sure. All hail the ease with which rich client interfaces can be built nowadays with jQuery, YUI, etc. That's using JS for what JS is for: behavior and effects (and if you want to use the fancy selectors in a cross-browser way, check out jQuery). The IE7 script basically takes your fancy CSS selectors and writes a shadow stylesheet for IE6, adding classes and filters and so forth, basically what you would have done had you written your HTML and CSS with IE6 compliance in mind in the first place. And then if you want to use JS for behavior, you have to watch out for all the "shadow" classes that IE7 script creates.

I will rejoice the day that the need for IE6 compliance goes the way of IE5, and we can use the CSS that the IE7 script was designed to provide. In the meantime, we still have to live with it and code for it. That joyful day is still at least a year off, unfortunately.

Will -

Great post and conversation! I'm always glad to see people who don't take content on the web as gospel and spend some of their time to analyze and refute it.

A note about outline: none - we've taken to doing it on the hover state for the links rather than as a general rule. That removes it for users with the mouse, but still enables it for users who tab to the href (provided the mouse isn't over it, of course). It's not an ideal solution, and your dotted outlines still go off the page, but it lets you use the text-indent technique without suffering the full accessibility hit.

Thanks again!

Jay Goldman

Hey Jay,

overflow: hidden; will take care of your "off the page" outlines.

Great idea applying outline: none; to the hover element only.

Nice post! But i don't understand a point: i'm talking about Section 1.5. What do you mean with "EMs cascade and pixels don’t" ?

@Laburno

Yes, my terminology there is actually incorrect. Both pixels and EMs cascade to child elements. Rather, the difference is that an EM in a relative unit of measure (relative to the parent element’s text-size) and a pixel is absolute.

@Jay/Patrick

Those are some great tips for managing outlines and negative text-indents. Thanks!

@David Furber

Yes, there definitely are some drawbacks to the IE7 script, it is not the silver bullet. Many of the issues you bring up I consider to be rather relatively unimportant compared to the benefits. Again, the worst that can happen is that a user sees a slightly “off” presentation. It’s a good thing that content is king!

I really don’t care about supporting users who have pirated operating systems. I know that some people get their Windows XP installation flagged incorrectly, but they should be able to work that out with Microsoft.

From my own testing I have found that there tends to be a very limited amount of visible style changes that occur when the IE7 script applies itself. Most pages render perfectly as soon as I can see them, and every once in a while I see a style switch.

The load time issue is something, but again, I don’t see it as a deal breaker. I do think that the extra Ks of javascript are worth being sent since it greatly reduces the extraneous tags and class definitions in my HTML. It makes maintaining and developing sites easier, and the HTML is lighter weight resulting in better load times. Plus, the IE7 script only needs to be downloaded once onto a user’s computer, while extra tags and class definitions would exist on every page visited.

It seems like in the end our differences tend to be that I would rather support a single standard of CSS and let a script fix a broken browser, while you would prefer to manually fix the broken browser. Hopefully this discussion will inform some people as to the benefits/drawbacks, allowing them to make the best choice!

I agree that the IE7 script makes writing the HTML and CSS lighter, easier, and more fun to write. I am all for streamlining markup so that it loads faster. The extra class here and there as a sop to IE6 rarely bloats HTML and CSS files enough to compensate for a JS file that is 43.5k zipped when you download it from SourceForge. Considering that the classes necessary to make the average page fit for IE6 add, say, 100 to 500 bytes to the code, the user would have to look at dozens of pages on the site before they "pay for" their IE7 script download. (It's more developer time, having to build in the logic to put all the classes on the content as it is being served...) However, it has been a few months since I last tried the IE7 script. Then, even running locally, there was a noticeable delay as the script updated the styles. Perhaps later versions have been optimized. If so, I will happily use the script.

Will, thanks for writing this post. I'm sick of the smashingmag roundups of shitty advice. I'm glad you threw a stake in the ground and promoted best practices. Also, using the YUI reset and fonts css files (plus using a doctype) has reduced my need for CSS hacks 90%.

thanks!

Regarding Section 1.5 - " To work with EMs like with pxs, set font-size on the body-tag with 62.5% "

What the real issue with this is that it's based on speculation, namely that many browsers default font-size is 16px. If a user has changed this setting, your layout may suffer if you use this idea exactly as described. This technique can be useful if used in the proper context, say after globally resetting the default font size - but then again, if you're doing that, why not just set it to 10px straightaway so that 1em=10px without having to do the extra math?

The idea of using relative sizing for certain elements (aka, elastic as opposed to fixed or liquid) is a good idea. It has its pros and cons like the other techniques and takes some discipline to execute, but it can be just what the doctor ordered in certain situations.

The idea: "To work with EMs like with pxs, set font-size on the body-tag with 62.5%" is not "bad" per se, just oversimplified.

Section 2.5 : You can force IE to apply transparence to PNGs. .. but what if you use conditional statement and include a separate file just for lt IE7 ? i think its a good solution, too..

Hi Folks.

Not wanting to be a "niggler" or that... but -

You, (and so many others), have made the point of CSS for being for presentation and not content. 1) Why are some of the abilities made available through CSS then? 2) CSS is often used for additional functionality (Dropdown/Foldout/Popup etc.). 3) As soon as you start making with the fancy Pop-ups etc., you are actually not making a alot ofsense to non-visual users (Think about it... why provide a Thumb next to the fullsize image???)

Additionally, in regards to Hacks - I cannot help but think that it is nigh on unavoidable. To achieve certain presentation results, you either use hacks, or a lot of additional markup. At least with IE you havethe option of expressions to get around - completely ignored by all others! Yet IE is not, repeat, not the only browser with more than annoying bugs. MozFF has had a fair few, so has Opera, and don't mention Netscape :) (Please note: I still view IE as a "pile of..." and think it ought to be revoked!)

And to finish the minor stamping of feet... Suggesting a script to control/fix things is not particularly smart. Sorry - but true. People always assume that it's people at home - do you have any idea how many people "sneak peaks" whilst at work? Do you know that many of them are on networks/systems with JS disabled, or the Security so high even benign scripts throw errors... and some have secuirty software that baulks at a simple JS menu (which are Evil ! ]8| ). So those people get stuffed instantly. Worse, some of theAssistive technologies don't take JS.. and if people are making the flashier affects with CSS support with teh JS, they don-t get it (as lets face it, how many here provide alternatives ???). So no real menu links (or alternative to access page by!), no gallery (ok, they may be blind, using a text reader, so it shouldn't count.... but that will not stop some "idjit" from suing someone!).

So there... The feet are no longer stonping!

Yet after all of that... damned well written, with lots of valid points. Thank you! Keep it up there fella, and keep plugging away to make us all pull our socks up!