Thursday, September 11th, 2008

You are not alone. None of the rest of us can fathom CSS either.

Category: CSS

Dave Minter is obviously frustrated, which lead him to write You are not alone. None of the rest of us can fathom CSS either.

He goes on a little rant that covers:

  1. Curvy corners
  2. Vertical floats
  3. Formatting for forms
  4. Floats within elements
  5. Graphical Buttons
  6. Column support
  7. Order Independence
  8. Widths on inline elements
  9. Addressing text within textareas
  10. A pony

Interestingly, do a view source on this bad boy to see nice corners that uses SVG, VML, -*-border-radius, depending on the browser. A lot of code for one feature huh?

On the other side we have 10 principles of the CSS masters by Glen Stansberry that covers:

  1. Keep CSS simple – Peter-Paul Koch
  2. Keep CSS declarations in one line – Jonathan Snook
  3. Use CSS shorthand – Roger Johansson
  4. Allow block elements to fill space naturally – Jonathan Snook
  5. Set a float to clear a float – Trevor Davis
  6. Use negative margins – Dan Cederholm
  7. Use CSS to center layouts – Dan Cederholm
  8. Use the right DOCTYPE – Jeffrey Zeldman
  9. Center Items with CSS – Wolfgang Bartelme
  10. Utilize text-transform commands – Trenton Moss
  11. And in other CSS news, Microsoft is getting nice, and is moving to -ms-* as vendor prefixes on CSS.

Posted by Dion Almaer at 8:51 am

3.5 rating from 33 votes


Comments feed TrackBack URI

While I agree with most of the top post, those “10 principles of CSS masters” has at least one truely, shockingly bad suggestion… like keep CSS on one line to make it more maintainable?

The clearing float div is also another out dated suggestion.

Comment by AdamB — September 11, 2008

I do get that this is not a rant against CSS but just the presentational form for his requests… marked by his frustrations at how slow standards get drafted and implemented.

I don’t see how bad implementation of CSS from the browsers comes into the equation. Whatever alternative would be just as likely to suffer from the same problem.
Back in the table design days… we had the same kind of browser quirks from Netscape and the same types of “hackish fixes” with 1 pixel spacer gifs…

He’s noted good points to work on… and even provided decent solutions for many of them. It’s just a question of patience. Hopefully IE9 gets announced in time for Xmas.
The sun still shines today in the world of CSS.

Comment by JeromeLapointe — September 11, 2008

@AdamB – I think keeping CSS on one line is ideal. In fact I write nearly all of my stylesheets that way. Here’s an example for a small site: . … Aslo, if you are writing a style library for an application with a large number of selectors I think it becomes even more important to keep rules on one line.

Comment by WillPeavy — September 11, 2008

I loved it!
It always makes me really frustrated how SLOW things
get done in the “lets take 10 years writing specs and then 5 more to implement them” world.

and THEN (!!!) comes microsoft says “nah, we don’t need your silly specs, we in microsoft make our own specs!” and then they find out they made faulty things that don’t work, and they’re too proud to climb down the tree and join the rest of the civilized wold.

Any way, I loved your list and I agree with your points, as a client-side coder. except the one you mentions its temping to go back to tables. yuk. no can do.

Comment by vsync — September 11, 2008

I agree with AdamB that one line CSS is a bad idea. I see this all too often and I find it to be hard to read / maintain. Good organization, now that is another matter entirely.

There are plenty of tools on the market that can expand or contract an individual css definition. Not to mention provide a list of selectors for easy access.

In a production environment CSS should be minified before being gzip’d for efficiency anyways.

Comment by Hardy55 — September 11, 2008

I think css must be on 3.14 lines in order to be perfect.
Always wondered the value of assertions like this list. You end up being interviewed by people who are following some selection from It and have to either bs along with the sources or blow it off and get read as either inexperienced or nonconformist.

Comment by ujuxiun — September 11, 2008

Number 4 has an extremely elegant solution I saw some few weeks ago which was to do “overflow:auto;” on the parent element and it actually resizes the outer bugger according to the size of the inline bugger ;)
We have this in our CSS which we’ll deploy in fact at in a couple of weeks (when coming out with the next version)

Comment by ThomasHansen — September 11, 2008

About #5, why not use input type=”image”….?
Am I missing something here…?

Comment by ThomasHansen — September 11, 2008

About #9;
First of all it does NOT use IFRAME (which is dirty) second of all it does mostly what he demands…
Though I know that this must have a relatively new browser to work, but by some freaking accident it actually mostly DOES work today ;)

Comment by ThomasHansen — September 11, 2008

btw: let’s not replay the whole one-line argument. It’s been played out on that link, on my original post on the matter, on my flickr screenshot on the matter. It’s the way I do CSS and I’ll kick you in the nads if you don’t like it. *Ahem*, I mean, code however you want. It’s not that big of a deal.

Comment by jonathansnook — September 11, 2008

Snook the first thing I’d do with your CSS is run this: s/({ \w|;)/\r\t/g. Then have my text editor close the folds. And probably ice my nads. :)

@ThomasHansen: Most WYSIWYG editors do in fact use an iframe with “contenteditable” set to true on the body tag. The editor you’ve linked to is not safe to use on most sites, for browser compatibility reasons.

Comment by MichaelThompson — September 11, 2008

Syntax highlighting editor.

yeah forget about iFrames…
take a look at my DIV-based editor:

Comment by Montago — September 11, 2008

@ThomasHansen, just to add to your comment, for those unfamiliar with it, simply set a width value and overflow:hidden.

Comment by AdamB — September 11, 2008

First Article:

1.) CSS where supported. VML hackery in IE + behavior + .htc
2.) top: 50%; margin-top: negative half of the inner element’s height.
3.) Yes, it’s a pain in the ass.
4.) Floating *anywhere* cross browser is a pain
5.) <button><img…/></button>
6.) Unless you’re printing… why? but yes, a pain.
7.) Well, yeah… that’s the *structure* of the document you created.
8.) It’s… inline… oO
9.) Yeah. Sucks doesn’t it?
10.) When IE is dead. :)

Second Bit:
1.) Heck yeah.
2.) Over my dead body. How on earth is that more maintainable? Make it multi-line and comment your code appropriately.
3.) Sometimes it’s better to be explicit with your declarations. Those few extra characters aren’t going to hurt you. You’re gzipping your css anyway, right?
4.) Mhmm.
5.) ‘Tis a pain, I agree.
6.) Darned right. In a lot of cases, it even makes *sense*.
7.) Yummy.
8.) You had better be doing this anyway.
9.) See 7.
10.) If you’re changing case for presentation purposes, this is the only way to do it as far as I’m concerned. Otherwise, you’re changing the meaning of things and maintainability in the future is going to be painful

Comment by Jocafa — September 11, 2008

@WillPeavy; styles in one line is a bad idea. that type of “optimization” belongs to scripts which compress the output or preprocess the css.

Comment by Aimos — September 11, 2008

Putting your all CSS on one line is about as useful as putting your JavaScript on one line.
If you’re searching for your class name, just use ctrl-f.

Comment by Diodeus — September 11, 2008

Utterly worthless post….thats if any quality CSS developers still reading this

Comment by ViPi — September 11, 2008

Eeek, putting all the properties for each selector on one line is hideous, how do you read it?

Comment by tlrobinson — September 11, 2008


Can you find that example of the overflow: auto elements? I am very interested. thanks

Comment by emehrkay — September 11, 2008

I just checked out our site and as I was inspecting it with FireBug I see that this change actually made it the last release we did :)
Use FireBug and inspect the way the DIVs are built.
Pay especially close attention to the divs with the ids of; “navigation”, “contentOfPageDiv” and “contentPlusBorders”…
Now the whole secret here is that the “contentPlusBorders” has overflow set to auto which will make a two column design possible with floating divs and also different heights of those two divs with a third div wrapping them serving as “borders”. The “navigation” and the “contentOfPageDiv” are both floats and the “contentOfPageDiv” is WAY taller than the “navigation” div. And normally this would require the “wrapping div” (contentPlusBorders div) to have a explicit height if you don’t want the tallest “inner div” to spill over the outer most div EXCEPT due to the fact of that it’s “overflow:auto;” Which actually fixes the whole thing! :)))))))
So incredibly simple I wouldn’t even believe it when I saw it ;)
I actually spent several MONTHS looking for this solution before I found it at some CSS blog (which I cannot remember the link to now unfortunately)
But the whole thing works on “all browser” mostly and it makes it possible to create a two column (and possibly more columns) layout with a wrapper around it to serve as borders…
I probably should wrap up some blog about this, I guess when I spent months looking for this before hitting Jackpot, probably others will need it to… ;)

Comment by ThomasHansen — September 11, 2008

Allow me to clarify that my recommendation for one line has nothing to do with optimization and everything to do with readability/maintainability. But what I find important, is (apparently) different from what everybody else finds important.

Comment by jonathansnook — September 11, 2008

2.) top: 50%; margin-top: negative half of the inner element’s height.
Which may be unknown. Welcome to dynamic content.

Requires changes to markup to achieve formatting. Bad. Doesn’t actually behave identically to the submit input element. This applies (with additional caveats) to the other user’s suggestion of type=”image”

6.) Unless you’re printing… why? but yes, a pain.
Big screens result in either very long lines, or annoyingly limited use of the page. Columns fix this. The CSS3 proposals (or at least their current webkit and gecko implementations) are nutty (they have poor usability as soon as the content has to overflow the page).

7.) Well, yeah… that’s the *structure* of the document you created.
Indeed, and the structure is dictated by the HTML. CSS on the other hand is supposed to let me dictate the styling and layout. If I want my glossary at the front of the book or my sidebar to the right of my account controls that is a layout issue not a semantic (structural) one.

Comment by dcminter — September 11, 2008

I wrote tens of thousands of CSS lines in my life for years.
one line CSS IS THE KEY to success in mastering your code.
If you haven’t done so already..your still in the minor league.

1. Its faster to read it. and I DO read it as a normal person would read a book. proper syntax highlighting makes it that way. If you can’t read it, your not there yet.
2. Its Indented. means, I know the DOM structure just by glance.
3. You don’t need to scroll a lot! and I work with Eclipse, and use GoToLine some times, but still.
4. to complete, it gives you a view at your CSS code as a whole.
in one glass you can see a huge bunch of elements. to see the bug picture in CSS is very important!

heres an example that I wrote:

IF this multi-line, it would be awful!!

Comment by vsync — September 12, 2008

Wow, that CSS was actually quite cool :)

Comment by ThomasHansen — September 12, 2008

Writing a CSS in multiline is like writing every attribute in HTML element in new line… totally pointless :)

Comment by Mrrau — September 12, 2008

I wrote a blog about it just now in fact;
Have fun :)

Comment by ThomasHansen — September 12, 2008

I looked at your blog post, and you forgot to mention the essential fix for IE6. The overflow:auto fix DOES not work in IE6. You need to add a conditional style to the parent div “height: 1%”. This will make the parent contain the children in IE6.

Comment by renderblender — September 13, 2008

“I do get that this is not a rant against CSS but just the presentational form for his requests… marked by his frustrations at how slow standards get drafted and implemented.”

“Slow” doesn’t quite cover it.

I think what bothers me most about the W3 process is the lack of pragmatism. CSS 3 has been worked on for a decade, and yet the W3 process hasn’t produced anything I can think of that is of use to me as a web applications developer (the CSS features I use were all in level 2). Under no definition can you call that pragmatic.

What web apps developers need is pretty simple: better layout tools, on par with what flex can do. This is a solved problem. If the W3 process was focused on pragmatism, they’d find a way to put a versioned trial spec for layouting out there fast, get browsers to put in trial implementations of this spec, and then if anyone actually used it in real world products, the browsers could simply keep supporting the old versions. CSS would easily support this using versioned prefixes (-w3-v123-, like -moz- and -o-). They’d triangulate onto a workable spec within a matter of years, maybe even before the end of the decade. By contrast, I fully expect the current process to take another decade before it starts paying off in a meaningful way.

Comment by Joeri — September 14, 2008

” 8. Widths on inline elements ”
Hey! You actually CAN use widths on inline elements, there is something called “inline-block”. :)
by the way… blame firefox 2 for people not using it ¬¬

Comment by RodrigoCardoso — September 15, 2008

Leave a comment

You must be logged in to post a comment.