In 2006 I wrote a blog post about how CSS sucks. The post was popular and somewhat controversial. It’s been 15 years and the core of the problem remains. CSS has certainly improved but it’s still holding back designers and engineers.
I’ve reposted the blog post with the original comments from blogger as the original site was taken down.
Sept 25th, 2006 – CSS Sucks
CSS is certainly an improvement on plain old HTML but its limitations are staggering and the lack of industry support will continue to hold back designers for many years to come unless we begin to build and design something better.
- For all that CSS has been able to do it’s a technological failure. CSS just doesn’t work as expected. How can I say it’s a failure when millions of sites use it? CSS can be used to style basic text attributes but browsers aren’t consistent in how they use this technology. Even though there is a “standard” and some browsers partially adhere to the standard to truly be a useful standard you need two things: Predictability and Consistency. CSS has neither. Any designer who has tried to create a large and complex site using CSS will tell you that all popular browsers interpret the standard differently.
- CSS is ‘markup centric’ not ‘design centric.’ I have this idea that designers should spend more time designing great looking sites and less time fiddling around with markup tags and browser compatibility. When I say ‘markup centric’ I mean that every CSS design tool forces users to go into source code mode to create an attractive modern site. Many designers take pride in hand coding CSS. Tools for designers should be design centric. PDF/postscript is a good example of a design centric markup , (unfortunately not very suitable for the web.) Designers don’t argue about how to create semantically correct postscript tags they just create great designs using great design tools. CSS sucks because it forces designers to think about how to make it work technically rather than how to make it work from a design perspective.
- Why on earth do we think that cascading is a useful feature? The way that styles cascade from one level of layout to a deeper layout makes it difficult to figure out why a particular item is styled in a certain way. By contrast non-cascading style sheets would be equally powerful and more predictable. The cascading makes it harder to interpret the page for both the designer as well as the web-browser. In fact the complexities in cascading is one of the reasons why so many browsers screw up the standard. In theory cascading could save bandwidth but in practice it creates bloated documents to get around the cascading issues.
- The box-model is too simplistic. The high level idea of CSS is that you can create attractive pages using margin, border, padding and content attributes. While this is a nice theory, it’s primitive in its understanding of both layout problems and design. Highly developed design tools have layout engines that offer multiple layouts, non-rectangular margins, proportional layouts, dock-able layouts, table layouts, column layouts, etc. etc. It’ll be years before these features make it to CSS and many more before browsers implement them with any consistency. If browsers keep spending so much time on CSS they’ll have a well polished turd. Tools like Aldus Page Maker had better design tools, font tools and layout capabilities 10 years ago. This is because good design tools start with the design, not the markup.
- When writing software you learn what works and what doesn’t. You get new and better ideas and you throw away the old ones. This process of starting fresh is absent from the current CSS way of thinking. Each version of CSS builds on the previous one without acknowledging any fundamental flaws. CSS and its HTML sibling are the ultimate designs by committee. Any enhancements to CSS/HTML are piled on top of the old standards. This makes it progressively harder to create powerful, compatible and consistent browsers. This also makes it harder for designers to create sites that target the new platform because they are constantly trying to satisfy the compatibility with older browsers. Version compatibility has to be all or nothing. If you support V3 it has to be 100% supported and tested. Supporting some of the features actually makes things worse.
- There shouldn’t be multiple right answers for a visual design. The way CSS works there can be many ways to do the same thing. In fact there seem to be endless debates about the proper way to hack together trivial things like rounded corners. Rounded Corners? I mean really! Again I refer you to Aldus and even MS Word circa 1997. These features are not that hard to develop but getting them to work in a “standard way” seems to be all but impossible.
- CSS captures styles not semantics or design intention. A design intention would be something like: “I want to balance these two columns” or perhaps “This text should line up with the logo image in the first column.” When designers do things like this:
#content{position:relative;top:32px;left:20%;width:40%;}They are capturing the style specifics not the design intention. Why 32 pixels? Why 40%? Perhaps the logo is 32px tall? Perhaps the other column is 60% wide? When the logo changes size or placement how will you know what styles to touch? There is a basic concept called parametric design that can be used to specify the parameters of the design. This concept helps embody the design intention as a set of rules that can then be preserved as the design changes. Even a very simple parametric design allows you to preserve design intention rather then hard coding sizes and dimensions.
- Design should be declarative not interpreted. Again CSS has to process a large number of rules before it can figure out where things are supposed to go. After these rules are interpreted this data is thrown out and each and every browser that opens up the web-page has to re-interpret the data. This is incredibly inefficient. First of it makes web-pages load very slowly. Even when you’re on a fast connection the browser can’t figure out where to place objects until the entire web-page has finished loading. Secondly this interpretation is very prone to errors. A declarative design isn’t open to as much interpretation allowing it both render quickly and consistently.
- CSS is a pain to work with. Take a look at some of the designs over at CSSZenGarden. The designs are both attractive and sophisticated. A good designer could take these designs and mock up similar designs in PhotoShop or Illustrator in a matter of hours but take the same designs and ask for it in CSS and it may take a couple days. Each time you make an edit to your CSS you have to refresh your browser to see what it’s actually going to look like. Then after you get one browser working you need to double back and get the other browsers working.
- If you can’t get consistency across browsers then you can’t rely on CSS to accurately and properly design your site. If you can’t get the site to look exactly the way you want on every single browser then how can you claim that CSS is a good design tool or even a success? The fact that there is no alternative to create attractive websites doesn’t make CSS a good tool. There are two ways to solve the problem. The first is to continue to hammer on standards and CSS asking for a better solution. This has been happening for the last 10 years and it just doesn’t work. The alternative is to realize that CSS is flawed in it’s intrinsic design and begin to ask the questions of how could you do it better?
——–
Archived comments from the original posting
Chris Moritz said…
*sigh
Jordi S. said…
And about this:
—
“If you can’t get the site to look exactly the way you want on every single browser then how can you claim that CSS is a good design tool or even a success?”
—
Ups, “to look exactly the way you want”? That is not what a web site is for. What about usability and accesibility? Users should be able to change font size; and they may have big or little screens; or … If you want control what users exactly see, give them a paper-sheet.
Greg Raiz said…
The problem is that it’s a an enormous pain with css.
I didn’t touch on accessibility but let’s call it a potential #11. People abuse css by turning lists into hover menus, fixing font-sizes so they don’t scale when the font increases and all sorts of other tricks that are totally not-accessible.
Jordi S. said…
well, I use Dreamweaver and let me tell that it’s not ‘great’ editing CSS. It’s probably better than any other editor, but there’s a lot of things that could be improved (although it’s a hard hard work).Sorry, I don’t exactly know what you mean by ‘high-end site’ (poor English, you see), but let’s take the model-for-ecommerce one: Amazon.
In Amazon users can change font size, the design ‘flows’ depending on screen-size, … Well, if you mean that designers want exactly “an usable design”, then I agree with you 🙂 But Amazon is not controlling design to the pixel (and they are doing right!).
Yes, you’re right: CSS may be wrong used against usability. But… it’s powerful, so it’s dangerous (as nuclear power is).
So I won’t say CSS sucks… No more than some tools suck, or some designers suck. CSS simply is not perfect 🙂
Ross Johnson said…
Every time I read posts such as this there always seems to be more of a “frusteration” than a good understanding and criticizm.
Your proposal to design a tool around the technology is a bit unrealistic. Shall we just convince all browser makers (including the ones that can’t even get CSS right) to just adopt a new technology?
Oh but wait, there is flash – and flash has it’s share of problems as well.
Once you get the hang of CSS it all makes sense and it is not frusterating anymore.
Mike G said…
Montoya said…
As a junior educator contributing to a college course with over 100 students learning CSS based design (as well as PHP programming), I can assure you that CSS is neither hard nor painful; if 100 students can learn it every year, and produce highly flexible, lightweight, and attractive designs with it, then maybe you just need to go back to school (and I say that without intending to offend you).
Greg Raiz said…
I can design something for print production in roughly 1/10th the time it takes to design something for the web using CSS.
The fact that you are blaming me for not understanding is just funny. Your own portfolio proves my point:
html { font-size:100.01%; }
As a designer you shouldn’t have to fight the CSS and the browser to get what you want.
Montoya said…
html { font-size:100.01%; }
wouldn’t be necessary if it wasn’t for IE 6 being so common, but who do you blame that on? The W3C CSS group, or Microsoft? Mind you, it’s a bug in Microsoft’s software. Maybe that will help you shift the blame in the right direction.
You said: “I can design something for print production in roughly 1/10th the time it takes to design something for the web using CSS.” Will your print design scale to the user’s window size? Will it allow the information to be used by multiple user agents (machines as well as humans, including humans who access the web in alternative ways rather than just visually)? Will it offer multiple styles? Will it be easy to modify in the future?
Or are we comparing apples and oranges?
The truth here is you don’t understand the web. You understand print design, and client side software, and even browsers, but that doesn’t give you any knowledge of how the web works. I still challenge you to really learn the medium, the technology, the research and the philosophy behind modern web design practices and why things work the way they do. If you did, you would understand why “problems” like cascading are actually features, and why this new way of looking at websites is a step ahead, not behind. Until then, you are entitled to your opinions, but you have no credibility to back them up.
Anonymous said…
Greg Raiz said…
Counter all 10 of my points if you want. Explain how a markup centric
language is better for design. Explain why consistency is not a problem. Explain why cascading is a good thing. Explain how things like CSS hover menus are a good for accessibility.
Go ahead and convince me. I’ll try to keep an open mind.
Scott said…
rebut your ten points on my own blog (not trying to spam; I felt it would get a bit long in the tooth to do it in your comments section).Mr. Montoya is corrent. You have a limited understanding of the medium. (Oh, and his website kicks ass.)
Greg Raiz said…
I believe CSS limits the creativity of designers by imposing technological constraints on visual designs. This may be because I come from a print background but that doesn’t change the fact that I still feel limited.
While CSS can be incrementally improved I personally think it’s important to think about how to make large improvements rather then incremental ones.
Michelle said…
Anonymous said…
Also, it is very easy to make your website look the same in all browsers.
Brett Mitchell said…
Of course, IE is and always will be the exception. While it is consistantly behind the other major browsers, support is slowly improving.
The point of the internet has evolved to be a source of information and entertainment that is widely available to everyone, everywhere – be it on a cell phone, by a visually impaired person with a braille keyboard, or your average citizen.
The internet isn’t a newspaper. You don’t have absolute control over what your viewers see. You seem to miss the point that the fact your viewers ultimately have control is the benefit of the internet – it’s customizable by individuals to meet their needs. If they need the font size larger, if they need to lower or raise the contrast, or they can’t see and they can have a browser speak to them.
CSS isn’t the be-all and end-all of design – you’re correct. If you want a design that aligns down to the pixel and has the perfect colours on every monitor/browser/platform, HTML is not your best bet to start with, and NO interactive language with the flexability of HTML could do that anyway.
HTML and CSS are easy to learn, cheap on bandwidth, viewable in every browser made in the last what, 6 years, including PDAs/cellphones…
What is your alternative?
Phillip Ryals said…
You push the idea that ‘something better’ should be created, either by fixing CSS or replacing it outright. I challenge you… how would YOU create this fictional superior method of describing a complicated design using RAW TEXT?
You see, from a designer /and/ programmer’s perpective, CSS is a very good tradeoff. No, I can’t draw a few boxes, apply some drop-shadows, scale some fonts, and see the results in a web browser. That’s life. Vector graphics for the web has been tried before in many many ways (anyone remember the Xcalibur BBS?) but it’s never taken off because it still requires more processing power than just rendering raw text.
The point is, you’re not going to get an easy-to-use method of creating complex designs. They’re complex, and so the method for creating them is complex. While CSS rendering isn’t predictable across all browsers (NOT the fault of CSS), it does indeed make many things possible that would otherwise never work.
Dean Hall said…
My rule of thumb is “Consistency, Consistency, Consistency” when it comes to a GUI. Neither CSS or anything else gives me an assurance of that. So I do what all developers do and I do whatever works. If CSS works for a project, then I use it. If it doesn’t look like it will, I use tables.
I thought this was a good article, with some valid points.
Anonymous said…
Anonymous said…
Anonymous said…
Most miss the point altogether, like:
Greg I just want to ask you what if I told you that Quark will no longer be supporting style sheets? Would you be ok with that? Even if you were working on a 120 page document? I’d be pissed, just like I would be pissed if they took away CSS.
This is irrelevant. Greg has not talked against the general idea of stylesheets, he talked against the CSS concept and implementation in particular. His points are specific and razor sharp, and could be used in designing a BETTER stylesheet language for the web. Like this point:
CSS captures styles not semantics or design intention. A design intention would be something like: “I want to balance these two columns” or perhaps “This text should line up with the logo image in the first column.” When designers do things like this:
#content{position:relative;top:32px;left:20%;width:40%;}They are capturing the style specifics not the design intention. Why 32 pixels? Why 40%? Perhaps the logo is 32px tall? Perhaps the other column is 60% wide? When the logo changes size or placement how will you know what styles to touch? There is a basic concept called parametric design that can be used to specify the parameters of the design.
Right on!
And since a lot of web pages nowadays are “web apps”, are you “css people” familiar with actual programming for GUIs? If you know GTK, QT, Java or what have you, they all have MULTIPLE layout models. CSS only has one, and a cripled one at that, the box model. A single model cannot solve all needs. (btw, almost all languages offer a table or grid layout manager, without sacrificing “fluidity”).
Some points:
a) The concept of styles is correct. It’s CSS that has it all wrong.
b) Design should be intention based and parametric. Hell, CSS does not even have parameters! If I want 20 design elements in my stylesheet to be 200px (or 20% or anything), I have to repeat myself 20 times over. When I want to change it to 200px it’s 20x times the work actually needed).
c) A lot of stuff should have been built in, in CSS and HTML and easier. Rounded corners? Blow me, just have something like:
#box {curve-top-right: 20px }
or have a way to define such effects in code blocks and share them.
etc…
Anonymous said…
Nick Presta said…
Oh, you mean like CSS3’s border radius property?
http://www.w3.org/TR/2002/WD-css3-border-20021107/#the-border-radius
Anders said…
Rich C said…
Web sites I build using CSS positioning for images are a lot more readable and maintainable than those I used to make using table-based layouts.
Greg Raiz said…
$logoh:120px;
$smallMargin:3px;
$largeMargin;10px;
.logo {height:logoh;}
.titletext {top:logoh+smallmargin;}
I’m using the $ show how you could declare a parameter/variable. This is still declarative so it’s not an ideal solution but at least it demonstrates how parameters could allow you to do things that are difficult or impossible to do via traditional cascading.
Anonymous said…
Or you can learn what cascading in CCS means and how to implement it.
Erm, cascading != parametric.
In the case I describe, for example, who told you that the 200px always refers to the same attribute (like width?). It could 200px of width for this element, 200px padding for the other, et al, used for implementing a consistent grid.
Or I could want a yellow background-color in one item, and a yellow foreground in some text or a yellow border in another. Cascading does not offer a way to define all these cases depending on a single color definition.
—
foljs
Daron said…
HTML, CSS, Javascript and all their evil offshoots are a result of:
* an inadequate and limited initial definition of the “web page” problem domain
* a crude, fatally flawed but simple to use initial technology (HTML)
* which lead to designers and programmers crufting up a mind boggling array of workarounds to fill the gaps (Tables and Spacer gifs)
* which spurred a belated attempt to redefine the underlying technologies by rigid academic edict mainly by non-designers (Cascading Style Sheets, XHTML, Widespread Deprecation)
* which was anyway largely undermined by the piecemeal and incompetent implementation of the new technologies in browsers and development tools (all of them)
* which is now all welded into place by the network effect, endless inert committees and monopolistic self interest. (Welcome to the Great Leap Backwards)
We are stuck with a kludge built on a kludge until we have a disruptive technology.
And Flash wasn’t it.
bjk2007 said…
Greg Raiz said…
bjk2007 said…
I did take the time to read it again after I had calmed down. I would have to say that while I disagree with you on several points, I do agree that CSS hasn’t done as well as it should have. Why? Simply browser support (IE). If we can’t get them to support CSS, how can we ever assume that they’ll support the newer and better theoretical CSS replacement language?
I guess the rest of my disagreements with you lie in a coder/designer mentality. You seem to be more of a designer while I’m actually a person whose strengths lie in coding, so we’re bound to disagree on how things should work.
Anonymous said…
IN PLAIN ENGLISH:
Not Microsoft, Netscape, Mac whatever can stop a standard being created, fact is those “browser companies” don’t make websites or web application (well they do make some) and developers NEED a standard so they aren’t writting 12 different lines to support 12 different venues. With these 2 standards (CSS2 and XHTML) we will have easier to maitain websites, portable applications, accessibility features for the blind/hearing impaired and about a million other applications.
SO TO ANY NEWBIE DO NOT LISTEN AND MAKE SURE TO USE CSS2 AND XHTML IN ALL FUTURE PROJECTS
Anonymous said…
josh said…
CSS is terrible. I’ve spent countless hours learning it and no matter what, the results are different from browser-to-browser.I can’t stand learning it, but at the same time I love the way some of these Css-driven sites are put together. I think to myself “I want that!” But it never happens. CSS is driving me insane. It always will drive me insane. Has potential, but it sucks.
John Nagle said…
CSS is, simply, a badly designed layout system. Even the rather simple system in Tk which lays out dialog boxes and windows is better. Tk is a nested-box system, but both “pack” (like CSS “float”) and “grid” (like tables) layouts are available in the same system. This is enough to handle most cases. Which “float” and “clear” are not. Page layout is forced to fall back on absolute positioning far too often.
The clever way to do layout would have been with a constraint system. Each box has four edges and four corners, and it would be possible to bind corners and edges to create any desired relationship between boxes. This is something one could express easily in a click and drag graphical tool. Want three columns the same height? Tie their adjacent bottom corners together.
Want to fill the page? Tie the outside corners to a page edge. Ten minutes to explain to an artist. Advanced use would involve priorities on constraints, so if something had to give in “fluid design” as the page size or type size changed, you could pick what gave first. (This could be extended to allow curved boundaries, even splines, but that might be overdoing it.)
The browser would have to have a constraint engine to resolve all the constraints, but there are known solutions to that problem.
Too many people drank the Kool-Aid on CSS. It’s just not that good a technology.
frostbyte said…
John Nagle said…
If CSS had a grid capability, it wouldn’t be so bad. But it doesn’t.
Anonymous said…
Anonymous said…
It was about separating format from markup to create data semantics.
Greg you are right on the nail. I wonder how many of these so called “CSS Designers” have the BIG profitable accounts.
Can you make the money with CSS on these sites using CSS, I dare you?
Look at these:
http://www.cosmopolitan.com/
http://www.elle.com/
http://www.nike.com
http://www.adidas.com
http://www.faithhill.com/
http://www.motley.com
http://www.imandd.com/index.html
Go on, make one of these (CNN for example) using CSS no hacks, js, pure w3c css. Publish the markup as a test and let us see that you know your css stuff.
Montoya you are the teacher, or is css only for the graphics blind? Prove Greg wrong, go ahead and make my day.
CSS can not do what the tables and flash can here. Forget semantics, forget standards, come and visit me for a little while in reality land. Bottom line people, hard cold cash it’s what matters.
Montoya get off you high horse and do something about it. Rewrite the standards so is more workable.
Use what works, and if you can separate format from markup with css and if tables have to be used so be it and format them in your css.