
CoffeeScript CSS - DanielRibeiro
https://github.com/aeosynth/ccss
======
mkmcdonald
> 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.

------
cobychapple
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).

~~~
Cushman
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.

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

------
netpenthe
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?

~~~
amccloud
Pretty much all the reasons I don't use coffeescript for js.

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

~~~
DigitalSea
I found an interesting article written by John Resig himself who posted an
article in 2008 sharing the same concerns about Javascript abstractions:
<http://ejohn.org/blog/javascript-language-abstractions/>

His shares similar concerns that I do in the first few paragraphs of his
article.

To quote:

 _In the case of these language abstractions you are gaining none of the
benefit of learning the JavaScript language. When a leak in the abstraction
occurs (and it will occur - just as it's bound to occur in any abstraction)
what resources do you have, as a developer, to correct the problem? If you've
learned nothing about JavaScript then you stand no chance in trying to repair,
or work around, the issue._

~~~
chc
Just like before, isn't that just as true of C and ASM? I take Resig's point,
but it really does seem to apply about as well to ASM — knowing it can be
really handy when the going gets tough.

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

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

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

------
harlanlewis
Sass: <http://sass-lang.com> Less: <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
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
He was probably thinking of Stylus, which is a fairly popular JavaScript
reimagining of Sass.

~~~
harlanlewis
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.

------
cageface
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
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>

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

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

