5 ms·

Surprised no one mentioned Sass or LessCSS.

astrofinch 16y ago
xCSS was mentioned in the first answer. http://xcss.antpaw.org/ http://xcss.antpaw.org/
callahad 16y ago
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.
- robin_reala 16y ago
  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?
  - ramanujan 16y ago
    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.
  - dhimes 16y ago
    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.
    - statictype 16y ago
      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.
    - almost 16y ago
      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.
    - isleyaardvark 16y ago
      It's the opposite, I recommend you check out the work of Steve Souders, his blog and his books (http://stevesouders.com/ 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.
      - dhimes 16y ago
        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.
- cyen 16y ago
  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.
andyford 16y ago
They did http://stackoverflow.com/questions/2253110/how-to-manage-css-explosion#answer-3434373 http://stackoverflow.com/questions/2253110/how-to-manage-css...
ollysb 16y ago
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/ 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.

xCSS was mentioned in the first answer. http://xcss.antpaw.org/ 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.

robin_reala 16y ago
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?
- ramanujan 16y ago
  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.
- dhimes 16y ago
  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.
  - statictype 16y ago
    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.
  - almost 16y ago
    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.
  - isleyaardvark 16y ago
    It's the opposite, I recommend you check out the work of Steve Souders, his blog and his books (http://stevesouders.com/ 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.
    - dhimes 16y ago
      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.
cyen 16y ago
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.

andyford 16y ago

They did http://stackoverflow.com/questions/2253110/how-to-manage-css-explosion#answer-3434373 http://stackoverflow.com/questions/2253110/how-to-manage-css...

ollysb 16y ago

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/ 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.