I Hate CSS | Hacker News Reader

I Hate CSS

blog.aaziz.org

51 pointsgnosis100 comments

The problem with CSS is that it wasn't designed to solve a particular problems. Solutions to those problems came later with the tools that were haphazardly thrown together.

Example: vertical centering in CSS is far harder than it should be [1]. Why doesn't "vertical-align: middle" just work for divs like it does for table cells? I'm sure there are reasons. They just aren't good reasons. What's more: why hasn't CSS3 fixed this? It's a longstanding problem.

CSS is littered with examples like this that just go to show there was (and still is) a disconnect between what the W3C is doing and the problems people actually have.

My other big problem with CSS is the "inheritance" model. For one, it shouldn't be called inheritance. It should be called "cascading" because that's what it is.

Inheritance at the class level would actually be useful (and is another glaring omission).

Layout, even with CSS3, is still far harder than it should be. The approach CSS should've taken is to to work through a whole bunch of layouts and figure out how they're implemented. If it's hard, CSS still has gaps to fill. Don't release a spec until those gaps are filled.

[1]: http://www.jakpsatweb.cz/css/css-vertical-center-solution.ht...

I agree that CSS can be frustrating - but I think it's a bit harsh to state CSS has failed when so many people are able to successfully use it to create a huge range of layouts.

People assume CSS should be easy and straightforward - but like most things, it takes a while to get to grips with.

I think there are maybe two main problems with CSS.

One, is that for a long time logic wasn't enough when it came to writing CSS markup. A large number of browser quirks meant that hacks and workarounds needed to be employed all the time. This is luckily changing .. modern browsers are thankfully much more coherent than their previous incarnations.

However, this perceived lack of logically coherence - and the need for arcane knowledge - is obviously infuriating to most people starting out ..

The solution has been to learn a handful of techniques - read a lot, and press on. While it's initially annoying, its not an insurmountable task.

The second is that CSS requires a lot of diligence on the part of the developer. There are good ways of writing code. I've found the 'cascading' part of CSS is quite often forgotten about - but well written mark-up can use this to greatly simplify the complexity of spaghetti code.

"Example: vertical centering in CSS is far harder than it should be [1]. Why doesn't "vertical-align: middle" just work for divs like it does for table cells? I'm sure there are reasons. They just aren't good reasons. What's more: why hasn't CSS3 fixed this? It's a longstanding problem."

I agree - this is annoying.

However, HTML was designed to allow content to be viewed at various sizes - and to scale width-wise (allowing the vertical height to adapt automatically) - I've a feeling this might be part of the reason why vertical align hasn't been included). Vertically centring fixed height elements is very straightforward .. vertically alignment for dynamic height elements is less straightforward, but it's usually possible.

"My other big problem with CSS is the "inheritance" model. For one, it shouldn't be called inheritance. It should be called "cascading" because that's what it is."

The first C in CSS is there for a reason ;) I think the cascading feature is actually quite powerful.

One of the things I'd most like is a way to use variables in CSS - but this will thankfully be addressed in CSS3.

"Inheritance at the class level would actually be useful (and is another glaring omission)".

Classes can be combined, and once applied, a class affects the descending elements contained in the DOM. I'm not sure what you'd ideally like?

Lastly there are some good projects out there that address quite a few of the gaps in the CSS specifications in a very reasonable way. LESS[1] and SASS[2] are two that come to mind.

[1] http://lesscss.org/

[2] http://sass-lang.com/

[3] http://en.wikipedia.org/wiki/Stockholm_syndrome

But I honestly believe sometimes a bad workman blames his tools.

I took the time to learn how to use it, so maybe I'm biased - but it's really not that bad.

And sometimes tools are just bad. Yes, a bad workman blames his tools, but that doesn't mean all tools are as good as they can be. Sometimes a good workman blames his bad tools; when there aren't better alternatives, what can he do?

Let me put my CSS thoughts in context: I self-assess to be about as competent in CSS as I am in PHP. Now, I know PHP isn't great. But when I'm smash-my-head-against-the-wall frustrated, it's usually because of CSS issues. >75% of the time.

In general, I expect frontend layout work to be less frustrating than backend work. It's less complex, IMO. And, actually, it can be -- just by using tables for layouts. So it's not inherent complexity that causes the frustration, it's the CSS issue (tables remove that frustration for me).

In short, I've returned to table based layouts because that tool fits my needs much much better than CSS. I use CSS for my styling, but layout goes into tables.

Maybe you should concentrate on back-end development?

I can sympathise, but I really don't think reverting to table-based layouts is a good solution.

EDIT: Reverting to table-based layouts _ISN'T_ a good solution.

lwhi - sure, I'm more comfortable doing back end dev work (and try to focus on it). But that doesn't change my opinion that CSS is a half assed solution that doesn't solve my problems. Tables do. And the counter-arguments against using a table based structure all tap into situations that haven't affected my specific context.

So tell me again why I should use CSS based layouts? For me, they frustrate me and prohibit me from accomplishing my tasks. Tables don't do this. And all the downside to using tables? Not particularly relevant for my goals.

Tables usually prevent incremental rendering.

Tables are usually more bytes of markup (have a lot of nested <tr><tbody> elements)

Tables may require you to chop single, logical images into multiple ones.

Tables may require you to use a 'spacer' image (!)

We're not living in 1998 (!!)

Tables make life hell for those using screen readers.

Tables lock you into the current design and make redesigns much harder than semantic HTML+CSS.

Tables prevent reuse of content on multiple device formats (mobile / desktop / tablet).

Tables prevent content from being easily scraped or translated into other formats (via a screen-reader or XSLT).

Tables usually prevent JS from being used to dynamically move and reposition specific content.

Tables make dynamic width / liquid layouts difficult (if not impossible).

Some objections, even though I don't use tables regularly personally:

Tables are usually more bytes of markup (have a lot of nested <tr><tbody> elements)

If you are concerned with size, you are gzipping or deflating and these tags should compress well

Tables may require you to use a 'spacer' image (!)

Div's require clear:both and other silliness

We're not living in 1998 (!!)

not really much of an argument--tcp/ip is older than that and we still use it

Tables lock you into the current design and make redesigns much harder than semantic HTML+CSS.

Perhaps a bit yes on your first point, but worrying about cross browser rendering issues twice will kill your time savings from "fast redesigns." If your table is object code, produced by a helper of some sort, this is not necessarily true either.

Tables prevent reuse of content on multiple device formats (mobile / desktop / tablet).

Not sure I follow. The current format for all these devices is just a standard browser + scrolling

Tables prevent content from being easily scraped or translated into other formats (via a screen-reader or XSLT).

Table headers and cells with classes and id's are plenty scrapable

If a person really can't see the disadvantages / advantages - I don't mind.

But it depresses me to think that some clients (who aren't knowledgeable enough to know any better) are being provided with sites that make use of something that was introduced as a stopgap solution 15 years ago.

The main reason people use tables is because they don't understand how to provide the alternative. That's not a good reason. People who do use tables should educate themselves - or pass the work onto a front-end developer.

I can see the advantages and disadvantages. I spent several years trying to force myself to use CSS for layout, because I thought that the abstract benefits of CSS were worth it. Abstract = "easier redesign" or "more accessible" type stuff. Things that had never affected me, yet.

And I spent so much time, so much frustration, trying to cram myself into the CSS semantic world. Then I realized, for my startup, that I needed to just BUILD things. I see CSS as providing generally abstract benefits, with very concrete disadvantages.

In short, CSS zealots sound to me a lot like this: "Well, if you could understand what you were doing, it would work right." That entire attitude puts me off.

Also, I believe it's a false dichotomy to say "no tables", or "only css". I put hacks in my code when it is beneficial for my situation. Tables are one of those hacks that I keep in my toolbox, right next to the duct tape.

Frankly, I find it obnoxious that you said, "People who do use tables should educate themselves - or pass the work onto a front-end developer." No. I understand my situation, my context, and my application. I made the decision to use tables, because it was more expedient, and I was insulated from the negative consequences. For you to imply that I'm doing something wrong on my code, well, that's just flat out obnoxious.

"Frankly, I find it obnoxious that you said, "People who do use tables should educate themselves - or pass the work onto a front-end developer.""

I'm not trying to be obnoxious. I didn't mean to offend you, or hit a raw nerve - but sometimes a change does require education. I can't see how declaring "it's not me it's you (CSS)" can be part of a reasonable solution.

CSS isn't that difficult - and I'm really tired of hearing (mainly back-end) developers berate something that I (and tens of thousands of other developers) use everyday successfully.

I find it obnoxious that so many people who don't understand how to use CSS successfully (and have chosen to use tables as a result) argue so fervently that their decision is the only logical choice ("I don't need to learn it, it sucks").

It's a case of the tail wagging the dog.

If you understand how to use CSS successfully and still decide to use tables, then fair enough - but in most cases I don't think there are many good reasons for doing so.

"I see CSS as providing generally abstract benefits, with very concrete disadvantages."

I'd (sincerely) be interested in finding out what these disadvantages are?

Sure, a change does require education. Where we differ is that I do not agree that pure CSS layouts are always the "best" solution. The "best" solution takes programmer familiarity, style, languages, business case, time lines, budgets, etc., as inputs.

And I'm tired of people telling me how I ought to program. It's generally well intentioned folks who have an idealistic theory (it's easier to modify! scrapers can access it more easily! it allows disabled people easier access!) pushed into a half-ass solution. Yes, I find the CSS2 standard half-assed.

For me, it boils down to what I can produce. I have much more flexibility (I can only get CSS to work "right" with certain types of layouts; tables, I can do anything) and am more productive with table based layouts.

Perhaps I'll run into a situation where a light bulb clicks on, and I go "Ohhhh, it would've sure been nice if I'd used CSS for layouts here!" But, up until now, I have only ever had the experience of "Fuck, I sure wish I had put this into a table rather than a CSS layout."

I've read several of the highly recommended CSS type books (Meyer, a list apart, etc.) I've tried to apply the lessons. I've spent more effort trying to figure out CSS than any single other technology I use. Maybe going to a class would help, or having 1-1 tutoring / peer sessions, but that's not in the cards for the future.

So instead, I just pathetically create sites that I love (and are successful, for me) with less frustration, faster, using table layouts.

YMMV.

One of the best reasons I can think of - is that it's good to be able to divide tasks.

If you code using tables - you can't easily hand your front-end work over to a front-end developer, because they won't be able to build an interface without modifying your code. It might be difficult for your business to scale as a result - but as you state, YMMV.

I'll be quiet now :) If you ever do find yourself stuck with a CSS problem, feel free to drop me an email.

> My other big problem with CSS is the "inheritance" model. For one, it shouldn't be called inheritance. It should be called "cascading" because that's what it is.

Cascading already means something in CSS (hint: the C means "Cascading", that quite strongly suggest there is a concept of cascade in it). And I'd like to see what problem you have with CSS inheritance: if an element inherits a property, then it gets the same (computed) property as its parent. That seems pretty simple and straightforward, and a good match for the word "inheritance".

> Inheritance at the class level would actually be useful (and is another glaring omission).

What does that even mean? Do you mean mixins at the block level? Overriding rules? Classes are just a type of selectors in CSS, where would inheritance fit in anything? And if you can inherit classes (whatever that's supposed to mean) why couldn't you inherit ids, attribute selectors or pseudo-selectors?

Exactly - I don't think it's fair to blame a spec when its lack of knowledge that's driving the criticism.

EDIT: Thinking about it - maybe the author should have employed a front-end developer? There's a good reason people specifically work on this stuff ..

There's a good reason people specifically work on this stuff ..

I don't get this at all. Central to the design of HTML and the Web is the notion of democratic access to information and the ability for non-specialists to create it. Furthermore, the motivation behind CSS was to make it easier to do this work by separating the design from the information. CSS should therefore be, if not intuitive, at least easy to learn, use, and troubleshoot.

It's true, we need brain surgeons to do brain surgery, but we shouldn't need specialists to do basic things like vertical centering, convincing layout without tables, and overriding styles in nested elements.

We've come a long way from the intent of CSS if we're arguing that only specialists should use it.

"Central to the design of HTML and the Web is the notion of democratic access to information and the ability for non-specialists to create it."

I imagine the large majority of the hackernews readership can be defined as a 'web specialist' of one kind or another, so if this were true most of us would be out of a job :P

My point is - there's no good reason why front-end development should be any less complicated than back-end development. Just because people expect it to be easy, isn't a good enough reason ..

Even the most complex layouts are conceptually much simpler than any non-trivial business logic. You can test this by trying to explain both aspects of a project you're working on to a non-technical friend and see which he or she is better able to grasp.

It's important to distinguish whether a task is made complex because it actually is conceptually complex or because bad syntax and language rules make it complex. In the case of CSS, it tends to be the latter.

Adobe Flex makes application layout dead simple. All you need are horizontal and vertical flows, consistent alignment, and border constraints. CSS would become about 5x more intuitive and productive for web app development if it just added these basic features and allowed us to escape its cryptic realm of floats, blocks, and display:inlines.

There's nothing cryptic about floats, block elements and inline elements. But you need to make an effort to learn about them!

People assume that CSS should be easy / that they won't need to learn extra skills - and are then annoyed because it doesn't work in the way they assume it should.

Imo, it's a pretty ridiculous situation - how can a person judge something they don't understand?

That's the point--it shouldn't take much effort. It's a simple problem made difficult by poor syntax and metaphors.

I do understand CSS. I've created plenty of fairly complex layouts with it. That's what allows me to judge it as inferior to other layout models I've used.

Why shouldn't it work the way people assume? I see very little benefit for this trade-off, except perhaps for the salaries of CSS gurus.

I don't understand how an incorrect assumption can be used as a criticism? Just because you assume something, isn't going to make it true.

The problems you might want to solve may be simple - but problems that others might want to solve might be more complex. It's not perfect, but CSS actually works reasonably well in a variety of situations.

My main concerns were based around browser inconsistencies, but things are much better in 2011 (compared to 2005).

There's a strong meme that reinforces the idea that 'CSS is rubbish' - but I think it's actually counter-intuitive to spread it. Basically, all we end up with are a lot of grumbling people who believe it's not worth learning - and don't.

It isn't about assumptions being correct or incorrect. I'm saying that if possible, a language should adhere to the concepts and vocabulary that people bring to the table instead of inventing its own, unless there are major benefits to be had in doing so. I see no benefits to the layout model of CSS over that of Flex (quite the contrary), and the vocabulary used in Flex means I understand how the system works immediately without having to look anything up because I know what horizontal, vertical, gaps, and constraints are already from my everyday non-technical experience, whereas I have no idea what an 'inline-block' is, and even when I look it up at w3schools, I get "The element will generate a block box, laid out as an inline box", which is gibberish without further research.

Clearly learning CSS is non-negotiable for being a successful web developer. I'm not contesting that fact, I'm lamenting it.

Being able to specify that an element is placed within a document flow (inline) is useful. Conversely being able to specify that a (block)-level element has its own position (relative or absolute) is also useful.

Sometimes it's useful for an element to be placed 'inline', but also share some of the properties that a block-level element has (like width and height) - so 'inline-block' has its place too.

I think part of the problem is, there are no every-day terms that can be used to illustrate a lot of the concepts that CSS makes use of.

If simple terms were chosen, the ability to do a lot of things would be crippled. Only simple things would be possible - and this wouldn't suit everyone.

But I do agree that it would nice if everything made more sense from the get go.

I don't think those properties should be thrown out. As someone said they are useful for what they were meant to do: style documents. But they're very clumsy when it comes to laying out applications. CSS (and/or HTML) simply needs a friendlier and more direct interface for this purpose.

That's why we have frameworks :)

We're talking about needless complication as opposed to essential complexity. We're talking about goddammit-I-just-want-x-next-to-y-no-matter-what-is-specified-ten-levels-up-the-dom-tree!

The essential reason that front-end development "should" be easier than back-end development is that back-end development is fundamentally algorithmic in nature and requires languages powerful enough to solve any solvable problem in computer science, while front-end development--and we really mean layout here--solves the limited problem of placement, layering, and coloring, and only requires a commensurate level of syntactic power for its implementation. I guess my point is that the front-end, or at least the layout portion of the front-end that CSS purports to solve, is so obviously so much less complicated than the back-end that you shouldn't have to point that out in order to deflect the accusation that it's just a naive expectation.

I realize it was probably tongue-in-cheek, but if anyone defends the complexity of CSS by equating it to a jobs program for web dorks, they've just ceded the point that CSS is improperly designed and needlessly complex.

My point was - if creating websites is so easy, why would we need any web-developers? In the best-of-all worlds, it would be straightforward - but in the real world there are lots of things to consider. We need specialists.

You might only use CSS for layout, but that doesn't mean layout defines the full-extent of its functionality.

When creating client-side user-interfaces, CSS is usually used in conjunction with other technologies. Front-end development often makes use of JS, and last time I checked that was a fully fledged programming language ;) CSS can provide a developer with a lot of flexibility - and the fact that you don't understand it is perhaps the main problem.

I think people assume they don't need to actually learn CSS - and get annoyed when they realise their brain wasn't preloaded with the required knowledge :)

"Central to the design of HTML and the Web is the notion of democratic access to information and the ability for non-specialists to create it."

Non-specialists don't need to know CSS in order to author information. The basics of HTML can be learnt in an afternoon.

> Take float – it’s a property to make text flow around an object. It wasn’t designed to create columns on a webpage. And there’s no CSS property that creates columns, or a header.

Yeah. How much time have I spent mucking about trying to achieve a stable cross-browser column layout. More often than not I just use a table. I know in design land this is an absolute no-no, but at the end of the day 1) it works 2) it's simple 3) it's x-browser 4) it's reliable.

Well I meant to downvote and accidentally upvoted but anyway if you're using a table then you are probably not expecting to do anything dynamic via JavaScript on it since it's not a collection of block elements, but table-cells. There's a lot you can not do with table-cells. Also, it's semantically incorrect and really takes like maybe ten minutes of reading a how to guide as to how to figure out how to do it with real css. Also attempting to control dynamic table cell widths is far more painful than anything you might ever want to accomplish with CSS. Finally, yes sometimes you have to reread the guide when you want to do it again. So

1) It doesn't work (with JavaScript and fluid, dynamic cell widths) 2) It's actually not that simple. 3) It's only cross-browser if you have a lot of reset CSS and do nothing fancy. 4) It's reliably problematic.

"There's a lot you can not do with table-cells."

Could you give a few examples?

"it's semantically incorrect"

So is "float".

"So is "float"."

No, 'float' is a property - '<table>' or '<td>' are elements. Float has nothing to do with semantics, it's purely presentational.

By marking up content semantically - it's possible to do interesting things with your marked-up content. For instance, content can be scraped more easily and a screen-reader can use elements to make inferences about the make-up of a page's contents. xHTML can be translated to other forms of XML using XSLT - and HTML content can be shared between desktop and mobile devices with just a stylesheet change. Liquid layouts can be utilised and JS can be used to move content dynamically.

There are a huge number of reasons for marking content semantically.

Using a table is a bad solution for anything other than tabular data.

> HTML content can be shared between desktop and mobile devices with just a stylesheet change.

Have you been able to pull this off in most cases?

In my experience, the mobile version of a site requires changes to the HTML, such as turning links into buttons and removing content.

It depends how complex your markup is.

I've found that a site that's been developed for the desktop can usually be made much more accessible by offering a different stylesheet. I.e. it's better than the alternative of doing nothing ;)

But I agree - it's not always as straightforward as you might hope would be. Sometimes it makes sense to serve different markup.

You can't resize them easily with JavaScript, you can't move them, you can't hide them and then show them again. You can maybe change the contents and add or remove a class, but because there's so little you can do to tablecells, good luck doing something other than changing background color. Since you're using a table cell for your overall design, heh. Not good.

> [it] really takes like maybe ten minutes of reading a how to guide as to how to figure out how to do it with real css.

This is the crucial point! CSS isn't remotely difficult.

Please demonstrate it then. I hear many more people saying CSS isn't difficult than showing it.

To be sure, I'm talking about CSS for layout here, not styling. I find CSS for styling to be relatively straightforward.

> takes like maybe ten minutes of reading a how to guide as to how to figure out how to do it with real css.

Sorry but I'm skeptical.

If you could prove this by sharing a paragraph or two (should be all it takes, right?) teaching how to use CSS to build reliable layouts I would be grateful.

Me too.

I suspect what he meant was that you can come up with a simple layout with 10 minutes of reading, but that's a strawman. The real problem is that it's extremely easy to rapidly make a once-simple layout a nightmare to maintain or debug.

With bitter experience I've realized I need to be extremely disciplined when I use the CSS directives margin, padding, and float. Everything else is relatively straightforward, with localized implications. But anytime you mess with the box model itself you really need to think about the big picture of your page's layout.

Step one is to abandon your initial requirements and rewrite ones that are compatible with robustly portable CSS.

After that I think the quoted statement works.

Can you gives some examples of requirements that must be abandoned?

There are many CSS books that give concrete examples of various layout types that work in all browsers.

Dan Cederholm wrote one of the best: http://simplebits.com/publications/bulletproof/

Thank you, this look like a good resource. :)

However, a book is a very different investment from "maybe ten minutes of reading a how to guide".

If you want that, see this:

http://www.maxdesign.com.au/articles/css-layouts/

It was written in 2002. Cross-browser layouts are a "solved problem" :)

"Semantically incorrect"

A "table" is an abstract concept with certain properties. If a layout shares those properties, it might as well be a table. If it quacks like a duck..

I enjoy luring people in to discussions about tables vs pure CSS layouts. You get a lot of hand-waving about theoretical benefits related to accessibility and the semantic web. Just press them for specifics and ask for examples of a simple three-column layout table causing an actual problem for any extant user-agent.

Though I too enjoy boring people with the "Tables are bad for anything"-pedantry it would be easy to give a few reasons where a simple three-column layout can turn into a problem.

1) You colspan the header image. Since the table "encapsulates" the columns, for user-agents with a browser width smaller than the header image, content will be less accessible.

2) Screenreaders will have trouble reading the content inside the layout in its intended order. You are presenting the screenreader with a table, so its expects tabular data. You can't content stack your page elements (and place the most relevant important information at the top).

3) No progressive page loading. It will not always take longer to render tables, over divs, but the loading will be a lot clunkier. Internet Explorer might wait till it has the entire table contents, before it renders the table, giving the user a blank screen.

These are some actual user (agent) specific problems, on top of many other problems with using tables for layout, maintenance being a particular excruciating one.

All very valid points. But compared to using CSS for layouts, where the downside is that I get so frustrated I have to stop working, these "downsides" aren't that bad. I value my sanity most. And,

1) in some minute percentage of my users, there's a chance my content won't show up fine. Whatever. I care about getting products launched faster, not about catering to 99% rather than 95% of my audience (premature optimization, really)

2) I have to suspect screen readers are somewhat smart about tables. For the past 15 years, most websites have been table based. Hell, Apple's store was totally table based when I last checked (1-2 years ago).

3) This is an optimization.

I find it interesting, in a startup community that values pareto principle, low hanging fruit, etc., that there is such a strong contingent of supporters who cry "CSS is simple!" I consider myself a very strong programmer, and CSS has caused me more problems than it has solved (again, only WRT layout, not styling).

In short, I use tables because I can accomplish my goals faster, and with less frustration, than CSS layouts. It prevents premature optimization, and it keeps me happier. Like anything, YMMV, but I really am sick of people who insist "CSS is so simple, take 10 minutes and you'll be fine". It's just not.

> I know in design land this is an absolute no-no, but at the end of the day 1) it works 2) it's simple 3) it's x-browser 4) it's reliable.

The conclusion I would make from that data is that designers are... ahem... idiots (for not using a working, simple and reliable cross-browser solution)?

After doing front-end development for 10 years, I have come to the conclusion that 97.3% of all my annoyances with CSS would disappear if IE and Opera adopted the Flexible Box Model (http://www.w3.org/TR/css3-flexbox/): vertical centering, scaling based on available space, constraints-based scaling, etc.

This is basic layout behaviours that I keep spending hours implementing in JS, which is slow and brittle, because you need fallbacks, etc.

I honestly would be OK with CSS if its only problem was anti-intuitive complexity.

Unfortunately, CSS suffers from this complexity PLUS the fact that browser makers don't interpret CSS in the same ways. Both of these together make the whole enterprise of web development burn up far more time than is reasonable. What makes this even worse is that the w3c doesn't bother to step up and make clear the ambiguities of how CSS SHOULD BE interpreted. They're in a perfect position as an arbiter of correctness, but they squander that power and are content to leave everything up to variable interpretation.

Sure, there are frameworks that abstract away the bullshit of CSS, but these are the result of COUNTLESS wasted hours of suffering that have propelled people to create layers of tooling for something that could have been VASTLY more simple in the first place.

You hate CSS? Here is an actual rant by zedshaw: http://oppugn.us/posts/1287608776.html

"I absolutely hate CSS. It has to be the most inconsistent, poorly designed, bat shit fucking crazy piece of computing technology we have today. And remember, I used to code Ruby and Perl for a living. If I'm saying CSS is bat shit crazy I mean it."

i can't help but feel that this kind of hatred is only derived from a lack of understanding of css. particularly the primary case for floats. admittedly a bit clumsy, they do whatever you ask them just fine.

it has it's quirks. though considering there are only a very few contemporary designs css couldn't achieve, surely it's doing something right.

that's not to say css couldn't be improved. but to think it takes "magic of the deepest kind to implement what should be simple", as one commenter says, seems like ignorance to me.

With all due respect you either are suffering from Stockholm Syndrome or you haven't given much thought to how one could design a text-based format for layout.

Not in the feverish imaginings of a thousand tortured opium dreams would one design something like CSS-P. Try sitting down with someone who has never used CSS and teaching them how to do a simple 3 column layout with background colours and a header and footer that works reasonably well across the three major browsers.

Scratch that - sit down and explain it to me. I gave up and hired someone else to do it.

"Try sitting down with someone who has never..."

sorry, are you saying that this frustration is most prevalent in people who don't have a strong grasp on css? isn't that exactly my point?

what precisely are you trying to argue? that floats and columns aren't perfect? allow me to reiterate a few of my concessions: "that's not to say css couldn't be improved", "it has it's quirks", and "admittedly a bit clumsy".

with all due respect, perhaps you're either suffering the effects of mere exposure or self-victimization.

All we're saying is that CSS was haphazardly thrown together, wasn't well thought out, and makes hard that which should be easy. In short, it sucks.

  body {
    #header {
      @include column(24, true);
    }
    #right {
      @include column(4);
    }
    #center {
      @include column(14);
    }
    #left { 
      @include column(6, true);
    }
  }

That's Compass/Blueprint.

Complaining about CSS is like complaining that the register names in x86 assembly have too many 'e's and 'x's in them. Don't write CSS; write something that compiles down to it. People argued about macro assemblers. Then they argued about C compilers. Then they argued about high level languages. People are always going to argue with replacements to technologies they've grown expert in. That doesn't mean you have to listen to them.

How about: Explain valid Doctypes and rendering modes then: <style>

* { margin: 0; padding: 0; }

.columnwrap { width: 960px; margin: 0px auto; overflow: hidden; background: url("faux-columns-red-green-blue.png") repeat-y; }

.col1 { float: left; width: 200px; }

.col2 { float: left; width: 500px; }

.col3 { float: left; width: 260px; }

</style>

You could create 90%+ of the websites with that and even IE6 would know it, because that's how floating designs were made 5/6 years ago.

I'm constantly working in HTML and CSS for my day job and floats cause the most problems and yet they're also the only way to create some complex layouts. Honestly, to this day, I don't know all the rules about floats and most of the time I end up doing cross browser trial and error until I get them to work right. That is not good design.

You need to learn how to clear floats, 'overflow: hidden / overflow: visible' are your friends.

I work with HTML and CSS constantly and rarely have problems with floating elements.

i can't help but feel that this kind of hatred is only derived from a lack of understanding of css.

The problem of element layout is a relatively simple one. It should not require some kind of in-depth "understanding" and extensive research. That's pretty much the point of the article, and I tend to agree.

CSS does layouts badly, and it should include dedicated tools to deal with the common issues. Right now, it pretty much relies on a bunch of hacks. The problem with those hacks is that they don’t allow for easy modification or code reuse. Nesting one complex layout inside of another is most likely to break both of them.

It always seemed to me that the people who defend CSS as "good enough" simply stick with a couple of mostly-working solutions and never try to design their websites exactly as they see it. That’s where the real pain starts. Something that takes five minutes with tables + css takes hours of reading and experiments with a "pure" layout. The sheer amout of articles about multi-column layousts is tribute to how complex the problem is.

"The problem of element layout is a relatively simple one. It should not require some kind of in-depth "understanding" and extensive research. That's pretty much the point of the article, and I tend to agree."

maybe my comment was ill addressed, then. i agree with this. my sole intention was to express that once you get over it's issues, you can write css just as fluently as anything else.

perhaps what confused me is that the article is expressing a sentiment that's been common for nearly a decade.

I completely agree with you. It's not that hard - but it requires effort.

If you continue to believe that CSS is an abomination and can't be tamed - you'll remain unable to use it.

Everything requires effort to use. Question is, how much. The effort to learn and use some technology should be comparable with the complexity of the problem it solves.

CSS provides solutions to some quite complicated problems - to think otherwise, is trivialising the work of front-end developers and designers .. and I think that might be part reason for some of the animosity that's often expressed.

E.g. it's front-end / it's trivial ;)

I should blog about the disaster that was CSS in Netscape classic and IE's attempt to rush CSS1/CSS2 support before the spec for both was finished and how it caused compatibility issues. You might be surprised to learn that the first draft of CSS1 dates back to the Netscape 0.9 period!

Use sass: http://sass-lang.com/

In particular: sass --watch styles.scss

Big productivity win.

even better - use Compass: http://compass-style.org/

Takes Sass to the next level. Actually makes Blueprint usable.

I'll take that one step further and say that Compass makes CSS intelligible, reusable and efficient to write. The Compass people have taken the time to understand what the right cross-browser techniques/best practices exist for lots of common CSS problems, so I don't have to worry about it. I wouldn't do CSS without it ever again.

That's awesome to hear!

Another alternative: LessCSS -- http://lesscss.org/

Include less.js in your page and you're done. No externally running process necessary -- the less.js file renders your .less files right in the browser.

less.js has weird issues with caching. If you use @import, sometimes it won't ever refresh the imported files. It uses the HTML5 offline caching APIs, so even clearing your browser cache doesn't help (at least in Chrome).

I love sass, but that's not what he's talking about. You still have to figure out your 2/3/whatever column layout. It's still a pain to figure out which elements to float and which to position absolutely. Much as I love sass, and I do love it, making the syntax easier to type doesn't make the fundamentals of the layout any easier.

Eric Meyer has a great post on the subject: http://meyerweb.com/eric/thoughts/2009/02/17/wanted-layout-s...

To Eric's point, summarized here, layout is not style, and CSS is all about style. No word yet on a cascading layout sheets (CLS?) which would provide that sort of capability.

Multi-column support is already in CSS3, and is supported by all modern browsers... with the usual exception of Internet Explorer.

However, multi-column implementations tend to be still a little rough around the edges, and some of the more complex formatting options don't appear to work. Also except to use -moz and -webkit a lot, unless you're using a framework like Compass which will handle the cross-browser support for you.

It also looks like there are a few Javascript libraries to give IE support for the multi-column CSS properties.

> with the usual exception of Internet Explorer.

Which, of course, makes it's entirely useless for real work. CSS properties for layouts that web developers commonly did in the 90's should have been in the spec from day one. Instead, CSS was far too concerned with word processor-like document layout than anything resembling a web page.

http://dowebsitesneedtolookexactlythesameineverybrowser.com/

EDIT: for the down-voting, disbeliever[1] ;)

[1] http://en.wikipedia.org/wiki/Progressive_enhancement

Progressive enhancement is fine for things like rounded corners but we're talking about multi-column support in CSS3. Rendered in IE9 your page will look it belongs to 1994.

I don't agree .. not many sites use multiple columns at the moment, and they can still look reasonably good (current). If not having multiple columns is a deal-breaker for a user, they'll switch browsers (which might not be such a bad thing).

My point is, the fact that some browsers haven't implemented some features yet shouldn't be problem. A website usually doesn't need to look exactly the same on every browser - and following a system of progressive enhancement allows a developer to use newer features more openly.

Now with the slow death and lessening support of IE6 and even IE7, my CSS life has never been easier. I build some layout and test in IE8, Chrome, Safari, Firefox, most always, my layout is laid out. I spent the time and it's gotten easier. Now people are complaining "it's too hard. I don't want to learn. What happened to the 1997 misnomer that any one can build a website?"

"But CSS is hard..." Well life is hard. Listen I have spent years learning the ins and outs of CSS. (Mostly Browser compatibility issues and best use principals.) I have spent years learning all the skills in my web development tool kit. This is what allows me to bill for my skills; not everyone can do them.

That's the broken window fallacy at work. Why should CSS be hard? Why should it take years to learn the CSS-specific skills which, as far as I can see, mostly involve memorising hacks to work around browser bugs and a fundamentally insufficient layout model? All that energy you and I have expended learning this crap is effort we couldn't put towards something actually useful.

I love CSS2 just the way it is. Developers seem to have a knack of forcing object-oriented thinking on CSS. They want to dictate what CSS should do different, when browser vendors still have trouble deciding what specification-valid CSS should do.

Dynamic CSS to me is an abomination. CSS is not a programming language and I doubt treating it like one will enhance portability and suddenly inspire the OP to invent the "holy grail" of CSS layouts: A simple variable height multi-column design with a header and a footer.

Come on, give the web and the front-end community a little respect. Don't use javascript for essential design/layout work, you don't need it, never needed it for years. You don't need hacks or CSS3 to build a fantastic website. You can float and use absolute positioning to your hearts content. You can keep your stylesheet organized and even support mobile and print media with it.

@cletus Vertical-align:middle does work differently on block-display elements. Use it in conjunction with display: table-cell or look at http://phrogz.net/css/vertical-align/index.html

I consider the OP post a little flame-batish and uninformed. I could say this about Lisp in an exaggerated manner: I hate it, because it does support labda, though it has its drawbacks and all those brackets look silly and confusing. I haven't really studied Lisp, but it could benefit from listening to my problems (which are real).

1) CSS is great the way it is

2) CSS makes "a simple variable height multi-column design with a header and footer" require so many contortions to achieve that it's considered a "holy grail" and not "a basic layout"

?????

The OP is treating a basic layout like a "holy grail". Around 2004 Glish.com published a series of CSS-based layouts they called "the holy grail" and many more followed. It's a bit of an insider's joke I guess.

A wrapper, a header, 3 columns, a footer in CSS was a "holy grail" back when table-based design ruled and everybody was figuring out new things to do with CSS (csszengarden.com).

Nowadays, it's easy. It doesn't require any contortions at all. Wrap the floating columns and clear them... The OP is lamenting 5+ year old problems, where there are simple and proven solutions available to anyone willing to simply look, instead of rage.

TFA seems to be down right now, so I can't read it, but I have a sense of its gist from this thread.

I have an extremely low opinion of CSS. It has poorly thought-out abstractions, and the designers sold that as a feature ("it's not a programming language!") as if that's a good thing for a computer technology primarily used by coders.

However, I've been able to make CSS work. I learned a bit about its general nastiness, and struggled with browser compatibilities (insert some choice phrases about IE here). Then, I managed to make nearly all problems go away by using column layout systems. http://960.gs/ with 24 columns works well for me.

Using these systems requires some extra markup and introduces some additional div noise. This problem tends to come up for any non-trivial layout anyway, but my .css files stay free of weird float and positioning rules (you know, the ones you can't understand six hours after you finally got the layout to render properly). On the flip side, I save days of effort, and I've been able to eliminate special stylesheets for IE. Anything "semantically important" still goes in separate "semantically important" divs, so accessibility devices should still be able to cope with the layout. Win-win, as far as I'm concerned.

PS: The next step is to turn CSS into a kind of object code. Someone who actually understands the way layouts should work can probably come up with a good language or syntax which can be processed into CSS.

"TFA seems to be down right now, so I can't read it"

Try this mirror:

http://blog.aaziz.org.nyud.net/i-hate-css

I feel a major problem here is that what we're using the medium for has evolved massively since it was first considered. The article suggests having special definitions for common elements, like header, footer and menu bars. What happens in 5 years, when those concepts are mostly obsolete and have been replaced by another way of doing things? That's how we ended up with the confusing model we have now.

>What happens in 5 years, when those concepts are mostly obsolete and have been replaced by another way of doing things?

People stop using them.

No they don't; they carry on using them for entirely inappropriate things. Like tables for layout.

CSS doesn't define element types. HTML does.

The proposed HTML5 spec. has definitions for many of these elements.

I haven't used a table for layout in 6-7 years, and although floated columns were initially difficult, I quickly found them to be very easy and more reliable than tables. These kinds of rants usually come from programmers who don't want to take the time to understand how CSS works, and when it doesn't "just work" the way they expect, they blame CSS. That said, CSS definitely needs improvement. I hope the flexible box model gains traction. I find that to be a more natural way to lay out pages, although the syntax seems a little clumsy.

CSS isn't to blame for a lack of creative application of itself. It doesn't matter what the `float` attribute was intended for, look at all the cool stuff it can do! Yes, I know it's hard to make column-based layouts. But really, go use a table (JUST ONE) if you must—but it still isn't too hard to do using CSS.

Also take a look at isotope and masonry for jquery-powered layouts.

Previous discussion: http://news.ycombinator.com/item?id=2189251

Mirror of original article:

http://blog.aaziz.org.nyud.net/i-hate-css

I don't understand rocket surgery. I hate rocket surgery. Rocket surgery is still a bitch.

That being said, I don't actually research, develop my craft, understand how to design, implement or maintain a solution or even work in rocket surgery. It was something someone asked me to do at the last moment and I thought I could pull rocket surgery out of my ass by reading up on some extra* articles.

* Implies that I regularly read rocket surgery journals.

Anyone have experience with good frameworks? An overview, perhaps?

As a non-designer I've used both blueprint and the 960.gs grid system.

They both work fine and I've never ran into the problems he describes with either one.

My somewhat limited understand of the two is the blueprint addresses issues with typography and sets a typographical rhythm, so it has some advantage there. However, I think it's pretty easy to trash that rhythm if you don't know what you're doing.

If you're using node.js ; stylus seems really good. I'll be using it as soon as I have the time to clean up my CSS.

[LearnBoost's Stylus: Expressive, dynamic, robust CSS] : http://news.ycombinator.com/item?id=2162620

The Eric Meyer reset is great for a base sheet... clears all those little default values you probably forgot about http://meyerweb.com/eric/tools/css/reset/

I swear by 960.gs or any of the fluid interpretations (http://www.designinfluences.com/fluid960gs/) for most of my projects. It is such a simple concept to understand, adding classes .container_12 or .container_16 (now in 24 columns) to wrap your content and then .child_X classes to each div or block level item you need.

Saves a huge amount of time, and is something that lends its-self to more organized styles if you don't spend all of your time designing. When the objective is to ship something quickly, frameworks are absolutely the route to take.

Reply on news.ycombinator.com