6 ms·

CoffeeScript CSS

20 points by DanielRibeiro 14y ago

rev087 14y ago
I love how removing the necessity for parenthesis and curly braces enable buildind domain specific languages like this or CoffeeKup.
netpenthe 14y ago
why would you use this over plain css? i can see the disadvantages: - have to learn a new thing - another thing to break - more difficult for new people to work on - probably a speed decrease (even if its a one off parse during deploy, it will still take more time..) what's the advantages? - slightly nicer (subjective?) syntax?
- Perceptes 14y ago
  I'm guessing it's just intended as a proof of concept.
- amccloud 14y ago
  Pretty much all the reasons I don't use coffeescript for js.
cobychapple 14y ago
I don't see how using selectors like: '#id .className': do -> is preferable to: #id .className { Also, the fact that this looks like CoffeeScript could really confuse people who see this code in a project and assume it compiles to JS. IMHO If you're after more from your CSS, just use Sass (or LESS if you don't want the Ruby dependancy).
- pyrotechnick 14y ago
  The quotes around the selector are necessary in CoffeeScript since it does not comprehend the syntax of CSS (# denotes comments). The `do ->` is a self-invoking function which allows for logic and computation in style definitions. These are particularly concise in CoffeeScript since functions implicitly return the result of their final expression.
- Cushman 14y ago
  It doesn't look like CoffeeScript, it is CoffeeScript, and it does compile to JavaScript. `: do ->` is idiomatic CoffeeScript to set a complex value inside an object literal; it compiles to `: (function () {...})()`. The output of that file is a JavaScript object which is translated into CSS by the library. This might be preferable to raw CSS or LESS/Sass if you want to write more complex CSS generation code in the same language as the rest of your stack, especially if you want to integrate your CSS with the rest of your app somehow. I'm a big fan of the idea in the abstract, although I'm not sure I love this implementation.
DigitalSea 14y ago
Coffeescript for CSS? I certainly hope this kind of thing doesn't become common place and people start using it for their CSS. Anything that heavily abstracts CSS making it more difficult to work on, debug and understand isn't helpful. This is a proof of concept more than anything by the looks of it, I hope it stays that way. If you want to write prettier CSS without straying too far away from standard CSS syntax, I suggest using LESS or SASS/Compass which allows you to have functions, nest CSS rules and even write normal standard CSS. This Coffeescript trend for JS is really starting to scare me as a developer that we are going to see a whole new generation of developers who don't know actual JavaScript, only the frameworks built upon them hiding the language itself. Is saving time really worth the cost of not understanding the code these compile-to-Javascript libraries generate? If the same thing were to happen to CSS to the point people don't know what real CSS syntax looks like, then we are all in trouble.
- lihaoyi 14y ago
  The same thing was said when C was invented; everyone knew that no serious programmer would ever not know Assembly, and anyway, hand-written Assembly would always be cleaner and more performant than generated C. All these novice programmers who don't know Assembly! In fact, the same thing was said when Assembly itself was invented: what kind of programmer wouldn't know the opcodes by heart, and need to use an assembler? Lazy buggers. That's not to say that all abstractions are good. It's really hard to make good abstractions, but you shouldn't be scared that people are trying hard things and sometimes failing. If we end up with something better than CSS that everyone ends up using, that doesn't sound like trouble, that sounds like awesome!
  - DigitalSea 14y ago
    I agree there are great abstractions out there (as you pointed out), I just believe Coffeescript isn't one of those. C and Coffeescript are two completely different things, I don't forsee Coffeescript being anything more than just the new JS kid on the block it feels like a trend at present. I would hardly call Coffeescript a contender for a new language built on Javascript. I think CSS is easy enough as it is, I don't see how removing braces and using indentation would make it better, I don't mind the braces. If you want better CSS use LESS or Compass, both exceptionally great additions to CSS that don't detract away from the native way to do things. Having said all of that, I can see that my argument is somewhat flawed. I'm not against change, change is great and in the case of the whole Assembly > C change it was definitely a refreshing change for the industry I just think some things are good the way they are like CSS. If something were to come along for CSS that made our lives easier and things prettier that became the standard I wouldn't be against it at all.
cageface 14y ago
I'm not sure I agree with this particular approach, but I have been wondering lately if things would be simpler if styling was accomplished in a JS dialect instead of CSS. The popular CSS preprocessors are getting more and more like full-blown languages already so why not just do everything in JS anyway?
- ashearer 14y ago
  Interestingly enough, a JavaScript syntax for stylesheets was originally proposed by Netscape back in the early days: http://www.w3.org/Submission/1996/1/WD-jsss-960822 http://www.w3.org/Submission/1996/1/WD-jsss-960822 The declarative CSS syntax we know won out. (Netscape's CSS implementation remained tied to JavaScript anyway, a detail that was normally hidden, except when a JavaScript error also killed the remaining CSS on the page.)
mkmcdonald 14y ago
> despite the name, CoffeeScript is not required; So think of an original name instead of latching onto the cachet of another project. > it just makes writing objects (as well as everything else) easier. I actually find the CSS example in your README to be far easier to understand than the convoluted mess above it.
harlanlewis 14y ago
Sass: http://sass-lang.com http://sass-lang.com Less: http://lesscss.org http://lesscss.org Both are widely adopted. Bracket-free syntax, variables, mixins, if/else, more. And you can get started without learning anything new! A coffeescript-based syntax signals true object-oriented behavior - but the compiled CSS declarations are still ruled by specificity and inheritance. Danger zone.
- rapind 14y ago
  Just a nitpick, but I don't believe Less is bracket-free. At least not the last time I checked. Sass is just plain awesome.
  - chc 14y ago
    He was probably thinking of Stylus, which is a fairly popular JavaScript reimagining of Sass.
    - harlanlewis 14y ago
      Wasn't thinking of it, but sure, add Stylus to the list. The point is CSS preprocessors get a lot of mileage out of a syntax with familiar roots. Dropping the curly braces stays true to these origins. Presenting style declarations as json in anonymous functions misrepresents compiled behavior.
tferris 14y ago
Anyone looking for a CSS dialect beyond SCSS, SASS and LESS should try Stylus. Smallest footprint, highest flexibility.
- ghempton 14y ago
  +1. Stylus is really under represented in these conversations. IMO it is the cleanest of the bunch.
lazerwalker 14y ago
I can see value in being able to create and represent your stylesheets as JSON objects, but syntactically this seems like a mess to me. For example, here are two things I noticed from a cursory glance at the example code that have their roots in CS's syntax: * The distinction between representing a selector as a JS object and representing it as an immediately-invoked anonymous JS function that evaluates to a JS object is whether or not it declares any local variables. * If your selector has a colon in it (in other words, :hover/:active/:before/:active or any other pseudo-selectors), it needs to be wrapped in quotes. Otherwise, it doesn't need the quotes. Both of these make complete sense when viewed in context of "you're actually writing CoffeeScript", and are sensible solutions to problems you will encounter when writing day-to-day CS. But writing code that compiles down to a static stylesheet is a very different problem than writing business logic: it seems weird to present a DSL where writing two blocks of 'CCSS' code that compile down to nearly-identical blocks of CSS could easily require the two CCSS blocks to superficially look very different due to the accumulation of edge-case language quirks like these. That is to say: CSS has a lot of quirks. CoffeeScript also has some quirks. It seems to me that this doesn't necessarily do a better job of masking CSS's issues than Less/SASS/Stylus, while adding in the mental overhead of dealing with some of CS's syntactic quirks.
radagaisus 14y ago
This is just an expriment. Look at the source code, it's ~40loc, it was last updated a year ago. Say you would want to write a mixin for a better border radius, you'll have to call your variables MozBorderRadiusBottomleft and borderTopLeftRadius. Clearly not a good style. Why? Because it's just a simple regex: key.replace /[A-Z]/g, (s) -> '-' + s.toLowerCase() That's why I'm afraid of uploading half baked projects to Github. Though so far, even my fully baked projects didn't get any attention.

20 points by DanielRibeiro 14y ago

I love how removing the necessity for parenthesis and curly braces enable buildind domain specific languages like this or CoffeeKup.

netpenthe 14y ago

why would you use this over plain css? i can see the disadvantages: - have to learn a new thing - another thing to break - more difficult for new people to work on - probably a speed decrease (even if its a one off parse during deploy, it will still take more time..) what's the advantages? - slightly nicer (subjective?) syntax?

Perceptes 14y ago
I'm guessing it's just intended as a proof of concept.
amccloud 14y ago
Pretty much all the reasons I don't use coffeescript for js.

cobychapple 14y ago

I don't see how using selectors like: '#id .className': do -> is preferable to: #id .className { Also, the fact that this looks like CoffeeScript could really confuse people who see this code in a project and assume it compiles to JS. IMHO If you're after more from your CSS, just use Sass (or LESS if you don't want the Ruby dependancy).

pyrotechnick 14y ago
The quotes around the selector are necessary in CoffeeScript since it does not comprehend the syntax of CSS (# denotes comments). The `do ->` is a self-invoking function which allows for logic and computation in style definitions. These are particularly concise in CoffeeScript since functions implicitly return the result of their final expression.
Cushman 14y ago
It doesn't look like CoffeeScript, it is CoffeeScript, and it does compile to JavaScript. `: do ->` is idiomatic CoffeeScript to set a complex value inside an object literal; it compiles to `: (function () {...})()`. The output of that file is a JavaScript object which is translated into CSS by the library. This might be preferable to raw CSS or LESS/Sass if you want to write more complex CSS generation code in the same language as the rest of your stack, especially if you want to integrate your CSS with the rest of your app somehow. I'm a big fan of the idea in the abstract, although I'm not sure I love this implementation.

DigitalSea 14y ago

Coffeescript for CSS? I certainly hope this kind of thing doesn't become common place and people start using it for their CSS. Anything that heavily abstracts CSS making it more difficult to work on, debug and understand isn't helpful. This is a proof of concept more than anything by the looks of it, I hope it stays that way. If you want to write prettier CSS without straying too far away from standard CSS syntax, I suggest using LESS or SASS/Compass which allows you to have functions, nest CSS rules and even write normal standard CSS. This Coffeescript trend for JS is really starting to scare me as a developer that we are going to see a whole new generation of developers who don't know actual JavaScript, only the frameworks built upon them hiding the language itself. Is saving time really worth the cost of not understanding the code these compile-to-Javascript libraries generate? If the same thing were to happen to CSS to the point people don't know what real CSS syntax looks like, then we are all in trouble.

lihaoyi 14y ago
The same thing was said when C was invented; everyone knew that no serious programmer would ever not know Assembly, and anyway, hand-written Assembly would always be cleaner and more performant than generated C. All these novice programmers who don't know Assembly! In fact, the same thing was said when Assembly itself was invented: what kind of programmer wouldn't know the opcodes by heart, and need to use an assembler? Lazy buggers. That's not to say that all abstractions are good. It's really hard to make good abstractions, but you shouldn't be scared that people are trying hard things and sometimes failing. If we end up with something better than CSS that everyone ends up using, that doesn't sound like trouble, that sounds like awesome!
- DigitalSea 14y ago
  I agree there are great abstractions out there (as you pointed out), I just believe Coffeescript isn't one of those. C and Coffeescript are two completely different things, I don't forsee Coffeescript being anything more than just the new JS kid on the block it feels like a trend at present. I would hardly call Coffeescript a contender for a new language built on Javascript. I think CSS is easy enough as it is, I don't see how removing braces and using indentation would make it better, I don't mind the braces. If you want better CSS use LESS or Compass, both exceptionally great additions to CSS that don't detract away from the native way to do things. Having said all of that, I can see that my argument is somewhat flawed. I'm not against change, change is great and in the case of the whole Assembly > C change it was definitely a refreshing change for the industry I just think some things are good the way they are like CSS. If something were to come along for CSS that made our lives easier and things prettier that became the standard I wouldn't be against it at all.

cageface 14y ago

I'm not sure I agree with this particular approach, but I have been wondering lately if things would be simpler if styling was accomplished in a JS dialect instead of CSS. The popular CSS preprocessors are getting more and more like full-blown languages already so why not just do everything in JS anyway?

ashearer 14y ago
Interestingly enough, a JavaScript syntax for stylesheets was originally proposed by Netscape back in the early days: http://www.w3.org/Submission/1996/1/WD-jsss-960822 http://www.w3.org/Submission/1996/1/WD-jsss-960822 The declarative CSS syntax we know won out. (Netscape's CSS implementation remained tied to JavaScript anyway, a detail that was normally hidden, except when a JavaScript error also killed the remaining CSS on the page.)

mkmcdonald 14y ago

> despite the name, CoffeeScript is not required; So think of an original name instead of latching onto the cachet of another project. > it just makes writing objects (as well as everything else) easier. I actually find the CSS example in your README to be far easier to understand than the convoluted mess above it.

harlanlewis 14y ago

Sass: http://sass-lang.com http://sass-lang.com Less: http://lesscss.org http://lesscss.org Both are widely adopted. Bracket-free syntax, variables, mixins, if/else, more. And you can get started without learning anything new! A coffeescript-based syntax signals true object-oriented behavior - but the compiled CSS declarations are still ruled by specificity and inheritance. Danger zone.

rapind 14y ago
Just a nitpick, but I don't believe Less is bracket-free. At least not the last time I checked. Sass is just plain awesome.
- chc 14y ago
  He was probably thinking of Stylus, which is a fairly popular JavaScript reimagining of Sass.
  - harlanlewis 14y ago
    Wasn't thinking of it, but sure, add Stylus to the list. The point is CSS preprocessors get a lot of mileage out of a syntax with familiar roots. Dropping the curly braces stays true to these origins. Presenting style declarations as json in anonymous functions misrepresents compiled behavior.

tferris 14y ago

Anyone looking for a CSS dialect beyond SCSS, SASS and LESS should try Stylus. Smallest footprint, highest flexibility.

ghempton 14y ago
+1. Stylus is really under represented in these conversations. IMO it is the cleanest of the bunch.

lazerwalker 14y ago

I can see value in being able to create and represent your stylesheets as JSON objects, but syntactically this seems like a mess to me. For example, here are two things I noticed from a cursory glance at the example code that have their roots in CS's syntax: * The distinction between representing a selector as a JS object and representing it as an immediately-invoked anonymous JS function that evaluates to a JS object is whether or not it declares any local variables. * If your selector has a colon in it (in other words, :hover/:active/:before/:active or any other pseudo-selectors), it needs to be wrapped in quotes. Otherwise, it doesn't need the quotes. Both of these make complete sense when viewed in context of "you're actually writing CoffeeScript", and are sensible solutions to problems you will encounter when writing day-to-day CS. But writing code that compiles down to a static stylesheet is a very different problem than writing business logic: it seems weird to present a DSL where writing two blocks of 'CCSS' code that compile down to nearly-identical blocks of CSS could easily require the two CCSS blocks to superficially look very different due to the accumulation of edge-case language quirks like these. That is to say: CSS has a lot of quirks. CoffeeScript also has some quirks. It seems to me that this doesn't necessarily do a better job of masking CSS's issues than Less/SASS/Stylus, while adding in the mental overhead of dealing with some of CS's syntactic quirks.

radagaisus 14y ago

This is just an expriment. Look at the source code, it's ~40loc, it was last updated a year ago. Say you would want to write a mixin for a better border radius, you'll have to call your variables MozBorderRadiusBottomleft and borderTopLeftRadius. Clearly not a good style. Why? Because it's just a simple regex: key.replace /[A-Z]/g, (s) -> '-' + s.toLowerCase() That's why I'm afraid of uploading half baked projects to Github. Though so far, even my fully baked projects didn't get any attention.