CSS sucks

No seriously, hear me out on this one. The idea behind CSS is good: abstract away the presentation from the data. Theoretically, you can change the presentation without touching the underlying document structure just by editing CSS. The problem is that there are far too many gaps in what CSS can do. We’re told not to use tables for layout, but since pure CSS cannot effectively duplicate all the layout options we have when using tables, how can that be the way we develop things?

Take the following condition: a three-column layout where the last column is a fixed width and the other columns should each take up 50% of the remaining width. Oh, did I mention that there should be a ten pixel margin between the columns? I could create a five column table with the widths set to 50%, 10 pixels, 50%, and 300 pixels…that will work (with some finagling). How do I do that in CSS? Using YUI Grids, which can give you some of this (the fixed right column and the percentage-based widths) but not all of it (the 10 pixel margin in between the columns) because the margins are percentage-based as well. You can’t simply float four elements because there’s no way to make all of the columns add up to the complete width at all window sizes and still maintain the flexibility of those two leftmost columns. And then the floats will wrap, which I never want to happen.

How is it that CSS can suck this bad? It started out so promising and somewhere fell woefully behind the times. Why is it that creating multi-column layouts still requires trickery and some magic even after all this time? And why can I still not achieve the same type of layouts that I could easily do with tables?


  1. Gopal Venkatesan

    Just curious, isn't using negative margin a solution to your problem?


  2. Lonnie Best

    I was among the first to purchase the first edition of Dan Shafer's book "Designing Without Tables".

    Since, reading that book, I don't use tables for layout anymore, but I find myself relying on javascript to dynamically change the size and position of elements during onload and onresize.


    It quite laborious, especially for more complicated layouts. It's too time consuming.

    I'm currently standardizing an ugly site I made back in 1998. Its layout took no time using a table back 1998:


    However, the other day I redid that page using div tags and css; it took way longer to get the same layout.

    Yes, markup is supposed to only contain tags that structure the content. Tables are intended indicate tabular data. Tables for layout is frowned upon.

    However, have you noticed how people use div tags for other purposes besides structuring content? I don't see as many frowns upon that, and it's the same abuse.

  3. daaku

    I think for the most part CSS does its job. If you think of layout and _everything else_ - its layout that CSS is bad at. In fact there are other frameworks/systems/applications that have adopted CSS for presentation, just not for layout. Flex is something that comes to mind (not sure if its used for layout there).

    I'm sure the CSS3 will provide us with more - but it seems like we're heading towards table style layouts - just without the tr and tds.

  4. José Jeria

    Lets just hope that all browsers will implement the following real soon:

    Until then, some layouts are just not possible to do without tables. Solutions where u hack CSS plus use JavaScript when you can use a simple table is a no go for me.

  5. Nicholas C. Zakas

    @Gopal - Negative margins help in some cases, but not all. My point is really that we shouldn't have to do complicated math to get column layouts that work the way we want.

    @Lonnie - I'm a purist, I hate using JavaScript for layout. I like keeping JavaScript as the behavior layer and CSS as the presentation layer...and try not mixing the two.

    @daaku - I think that's a fair point. It is the layout part that sucks, it does fonts and colors beautifully. :)

    @Jose - I'm not sure that CSS3 columns are the answer either. It's interesting conceptually but seems totally out of wack and illogically designed. I think column layout should be simpler than this. :)

  6. Lonnie Lee Best

    You can use absolute positioning to get any layout you want. However, when a page is loaded or resized, that layout remains static. For a layout to accommodate sizing, it requires *behavior* of that layout. I wouldn't call it un-pure to use javascript to control layout behavior. I would simply call it an inconvenient reality for those who *purely* wanting to keep their layout out of their markup.

    The question is: do we want that layout behavior to be inherent, or do we want to explicitly control it with javascript.

    We both want it to be inherent because it saves time.

    However, in order for it to be inherit without being in the markup, you'd have to have a mapping construct in the css, a mapping that specified the encapsulation of elements for the purpose a cohesive layout. How else would we be able to make various box elements work as a cohesive whole? The answer is mix structure and layout (like the table element does) OR use javascript to control layout behavior when an event occurs.

    The table route is the easiest for sure, because it avoids mapping; the encapsulation of elements (for the purpose of layout) is specified in the markup. It has to be specified somewhere.

    Wait a second. I'm forgetting about % units in CSS. Because of % (and em too perhaps), a layout can be specified statically, yet change dynamically onresize. However, to make various element behave as cohesive whole (dynamically), some type of layout encapsulation needs to be specified somewhere in the markup or css or javascript.

    Said differently, you need a way of grouping elements outside of the markup. I don't like encapsulating elements within other elements in my markup when the encapsulation says nothing about those elements structure and instead is layout hack.

    Let take the example you give of having divs float side by side to emulate a row. A row is a grouping (an encapsulation of elements for the purpose of layout). Yet CSS doesn't allow you to explicitly specify that elements that are related in this way. That's why if the width of the browser window is too small, the last div drops down underneath the other divs. However, if you were able to specify in the CSS that those divs were part of a "row-group construct" the browser would recognize that this is to never to happen; if the browser width is too small the overflow would be hidden.

    That's what is lacking CSS2; the ability to group elements into a CSS construct that doesn't exist in the markup. If this was added, you could specify: (1) these elements are part of a row-group, (2) this is the ordering of that group. With this, you could then set the width of each div to a % of the cohesive whole without mentioning it in the markup.

    Until the w3 adds this type of construct to CSS, javascript will be our only method of abstracting this behavior to occur during onload and onresize.

    We could create a javascript library that has this construct. The interface would allow us to create an object that contains an array of elements that are to be in a row, and also allow us to specify the % width of each element. Each time the an onload or onresize event occurs, this object's render method will be called, and then it will be sized accordingly.

    Once a library like this is perfected, it would be easy for the w3 to add something similar to CSS specification and the browser makers will have plenty of guidance on how to implement the specification.

  7. Nicholas C. Zakas

    Man, I'm going to have to put a text limit on these comments...it doesn't look good when a comment is longer than the original post. ;-)

    As a point of clarification, Lonnie, what you're describing is layout flow, not layout behavior. Layouts should flow depending on the size of the browser and certain constraints. The ability to specify how the layout should flow should be a part of CSS, not part of JavaScript. You've seen my Maintainable JavaScript talk, I firmly believe in separating data, presentation, and behavior which means JavaScript should not be used for the layout at all. You may consider me a purist if you'd like, but this is the way the Web should work.

  8. Mike Lee

    Some would argue that it's the poor implementation of CSS by browser manufacturers that's the problem here. But dude, I SO hear ya.

    It's sometimes so frustrating that if you're not able to find a CSS master to help you out (fortunately, you work with a bunch), it starts to become a decision of practicality vs purity: Do I spend another 40 hours trying to make this column aligned to the right? Or use a table? (Or down this bottle of Jack Daniels, so I don't give a shit either way anymore?)

    Good luck with your CSS man!

  9. Joe

    CSS is a bad technology with a bleak future, it is a technology that involves the developer in the design process and the designer in the development process - calamitous, so don't feel you have to waste your time on it unless you are working on a large multipage site, and then get a developer to do the CSS part.

  10. mike

    Tables Suck! Period! Stop Arguing about it! Table layouts look like "ebook" sites...if that whats you want then fine...I prefer a more professional layout...css to the rescue bitches!!

  11. Peter

    CSS has many dumb built-in mistakes. Backward compatibility is killing what has the potential to be an excellent tool. The only solution I see is a CSS doctype. What CSS needs is a fresh start. (It is healthy to admit your mistakes and move on)

    By the way, there is nothing "professional" about CSS-only layout. It takes a truly stupid person to believe that all his design problems will be solved by eliminating the table tag. A "Professional" chooses a reliable cost effective design, which meets his client's needs. Sometimes this means using tables...

  12. Andyf

    Lonnie Best say:

    "Since, reading that book, I don't use tables for layout anymore, but I find myself relying on javascript to dynamically change the size and position of elements during onload and onresize."

    This really sums up all that is bad about CSS and shows it to be dogma and not design. It shows that CSS can't "do what you want", and this is the reason it has failed to gain widespread use. Any "new thang" that starts to rely on browser X's scripting capability is just weak, and will bring on a heap of problems as new browsers emerge (as they do).

    Resorting to JS for layout is a much worse "offence" than using tables can ever be

    As for seperation of data from layout - wel lyou have to qualify that by whether you want that seperation at design or browse time. A platform like ASP.NET allows that seperation easily at design time... I don't care about seperation at view time.... :)

  13. Max

    You are an idiot, unless you are being sarcastic. It's not tables that make a page look bad, it's poor styling (including CSS). Tables can help make layout easy, with CSS making your elements look great with minimal effort.

Understanding JavaScript Promises E-book Cover

Demystify JavaScript promises with the e-book that explains not just concepts, but also real-world uses of promises.

Download the Free E-book!

The community edition of Understanding JavaScript Promises is a free download that arrives in minutes.