How to Manage CSS Explosion | Hacker News Reader

How to Manage CSS Explosion

stackoverflow.com

63 pointsniyazpk26 comments

You can't.

You can try to reduce the horribleness of a CSS file, but the language simply doesn't provide the tools needed to do the one thing all programmers need to manage complexity: abstract away the common part of two specific processes into a reusable component.

I'll never forgive the designers of CSS for not at least providing immutable constants, if not variables.

The more I think about it, the more certain I become that immutable constants (a good idea, IMO) are the furthest CSS could safely go down the rabbit hole before the entire enterprise would consume itself in spaghetti-code madness.

Not that plenty about CSS doesn't beg for better abstractions, but turning it into a programming language is kind of a terrifying prospect. I've see too much of what enthusiastic amateurs can inflict with JavaScript.

Have you looked into Sass and Less CSS? I haven't used them in production. They seem to achieve reuse in a CSS-like way.

You can.

So what if CSS doesn't have variables? We can add them. CSS is the format it has to reach the browser in, it's not the format we have to write in though. There are multiple projects out there for writing CSS at a higher level, which "compile" to CSS but let you use variables and things like that.

Of course you can. The same way we make HTML manageable; by pre-processing it. Sass, Less to name just the two most common options.

"I am using a large number of div tags within the website (previously it was completely tables based)." That's one part of the problem. Why not use tables if you are using .title, .body and .footer for DIVs when tables have this as default? I see a lot of people using DIVs on places they shouldn't. They use things like <div class="title" ... Why not use H1 - H6 instead?

HTML tags provide structure. Structure means less complexity. Using only DIVs will get you into CSS trouble.

Edit: A good tip: your website will look more consistent and clean when you try to build your pages by only declaring HTML tags in your CSS at first. Only when there is no other solution declare classes and IDs. And even then remember you can use multiple classes in your class attribute. Things like: class="width50perc floatLeft textAlignRight textColor1" are very handy.

> Things like: class="width50perc floatLeft textAlignRight textColor1" are very handy.

At that point, how is this any different from just using inline styles? The whole point of CSS is to separate presentation from content, you've done gone and thrown a bunch of presentation back into it.

True, but I think the fun thing is when you use CSS to seperate presentation from content you will end up in CSS hell. I know websites like csszengarden are telling you this is the power of CSS. And it is, but ask yourself: how many times did you change the layout of a website with CSS only? Probably not a single time.

Surprised no one mentioned Sass or LessCSS.

xCSS was mentioned in the first answer.

http://xcss.antpaw.org/

The current version of Less is really impressive. It's written in JavaScript, which lets you do crazy things like:

  <link rel="stylesheet/less" type="text/css" href="styles.less">
  <script src="less.js" type="text/javascript"></script>

Since it's a superset of plain CSS, both the migration and the learning curve are really pleasant.

Why would you want to do this on the client and slow the whole site down? I can understand (though don’t personally want to use) a server-side preprocessor, but doing it in realtime on the client seems counterproductive.

And what? I’ve just checked out the minified version of less.js and it clocks in at 32kB. Seriously?

I think the idea is to use a pure JS implementation of CSS for debugging/dev, and do prerendering of a minimal CSS file before deploy.

Why do you say that doing this on the client would slow the site down? That's counter-intuitive to me. I'm trying to push everything I can off to the client (client machines seem pretty good) in order to keep things on the server speedy- but it's my first web app, so I'm new in this space. Thanks.

On mobile browsers, the speed at which the javascript interprets your data may actually be slower than sending the pre-interpreted data over the wire. Even on 3G.

If you do it on the server you do it once (when you deploy), if you do it on the client it happens every single time.

It's the opposite, I recommend you check out the work of Steve Souders, his blog and his books (http://stevesouders.com/). The general idea is that the server is going to be speedier (through a combination of hardware than caching) than the user's machine. And there are a lot of old machines out there.

Souders estimates that around 80-90% of a site's slowness has to do with the time it takes for the browser renders the page, js slows that down.

Thanks for the link. Browsing "Even Faster Web Sites" he cited 14 rules from the first book ("High Performance Web Sites") in the preface. Rule 1: Make Fewer HTTP Requests. I guess this is what I had in mind. I have a request get the data, but how I allow user to render it different ways. So the local rendering is done in JS.

I'm still building, but it look like I better give this a second look.

I'm also in the education space, so where there are crappy machines there are also likely crappy networks.

It's a little absurd to about the simple changes / features necessary (variables? nesting? c'mon) to make CSS bearable again (if it ever was).

Then you take a look at some of the additional goodies - fadeout(), desaturate(), etc - that have been included in the most recent release, and you wonder how you ever kept your color palette organized before.

Less has prevented me from wanting to claw my eyes out during a recent round of frontend work - just for that, I'm incredibly grateful.

They did http://stackoverflow.com/questions/2253110/how-to-manage-css...

I really like less as an improvement to css. I always end up discarding it though because of the dual representation you end up with. I've tried using the https://github.com/cloudhead/more/ plugin for rails which generates the css on the fly, but it doesn't work reliably enough for me to be confident the changes I've made have been reflected in the page I'm looking at. I also spend a lot of time in firebug tweaking rules and it can be a pain to translate back when you've abstracted the rules you're working on. I think the extensions they've made to css are absolutely the right choices, very minimal. If the browsers would support it I think it would be a winner.

There are better ways to manage CSS bloat.

See Nicole Sullivan's Object-Oriented CSS approach: https://github.com/stubbornella/oocss/wiki

I love CSS. It's so easy to get the results you want. Redundancy, messiness, and other complaints are a small price to pay for that.

I wish my designer would read this ... but he's just a designer, what does he care about the quality of his CSS.

Any good stackoverflow answers for that? Making people who think "code" is a side-product take pride in that part of their work too?

My personal guidelines:

* Partition into sections for fonts, colors+images, positions+spacing, text, and specials.

* Refactor for minimal property duplication, instead of selectors. For example text-weight:bold; will be mentioned only once, but the "#content a" selector multiple times.

* Use a CSS reset.

* Make an extra file per browser+version for hacks. Do not use hacks, which make sure they get triggered in IE7, but not 6 or 8, for example, but use ie6.css, ie7.css, and ie8.css. Duplicate code for this if necessary.

Example: http://beza1e1.tuxen.de/style.css

My approach: http://jonasgalvez.com.br/Software/HCSS.html

Reply on news.ycombinator.com