

Google: Introducing Closure Stylesheets - packetslave
http://googlecode.blogspot.com/2011/11/introducing-closure-stylesheets.html

======
malandrew
Question #1: Why didn't Google decide to instead contribute to Less or Sass,
instead of coming up with something new?

Question #2: Why did Google come out with their own solution that has matured
in the vacuum instead of involving the community earlier on? This approach at
best fails and at worst fragments the market further.

Observation #1: When there are two very established solutions in the market,
Sass and Less, you need to point out why these two come up short and why you
are coming out with something new. Simply stating "we have a Google version of
the tools you already use with the same feature set" isn't a very compelling
sales pitch.

~~~
choxi
I agree, I feel like they did the same thing with Dart which, imo, addressed
the same problems that Coffeescript has already addressed.

~~~
KeithMajhor
Dart doesn't add much in the way of syntactic-sugar which is the only problem
addressed by CoffeeScript.

------
nickand
Redundant functionality to JavaScript is redundant. That being said I'm all
for designers having baby steps they can use to simulate some of the
functionality of JavaScript. After all the days of the one line of JavaScript
that does that cool effect are over now that you aren't cool if you don't use
prototypes and 'modules.' JavaScript is getting to the point where if you
don't use at least 3 libraries to make your onclick event handler you get
publicly lambast.

Also who says you need to copy the color every time you use it?

This is how it works. If you have one important property that you want to
change everywhere then you use the most specific target class necessary for
each of those classes in a comma separated list attached to only that property
then you can change them all later or add new classes to them.

.class, .anotherClass, .yetSomeOther .moreSpecificTarget {color:blue;}

Also if you want to simulate if / then statements then you write your most
general classes first followed by your more specific classes. So:

.blue {color:blue;}

.blue.darker {color:rgb(4,4,179)};

It's even better than a conditional. It's a switch.

~~~
nostrademons
That's not the case for variables. The case for variables is when you have a
set palette for the site, and you want the border of some elements to match
the background color of other elements to match the text color of still other
elements. Or you want to set padding on a set of classes, but then want to set
the width of your left column to be some chosen value minus the padding of the
center column. Or you want to flip your layout in RTL languages so that
everything is reversed.

CSS won't let you do any of this natively.

------
latchkey
I started out with sass. Then I started using twitter bootstrap, which uses
less, so I switched to less because the mixin syntax is nicer / simpler (easy
to switch since moving in that direction is syntactically very similar).
Looking at the closure syntax, it doesn't seem like much of an advantage over
less. I think I'll stay where I'm at.

------
dstein
If you want to compare that Java-ish syntax to some of the super-slick stuff
you can do in NodeJS check out <http://www.jaxcore.com/jxss/> which is a
JavaScript/CSS hybrid stylesheet format I came up with recently.

------
skrebbel
The "Not Invented Here"-Syndrom at Google is absolutely baffling.

I can't wait until they port the entire Closure suite to Go.

~~~
nostrademons
To be fair, the Closure suite has been around internally since roughly
2006/2007, and before then was extracted from working code within GMail &
Google Apps that dates back to around 2003 & 2004\. (I remember running across
some of Paul Buchheit's code in Closure Compiler.) Prototype was brand new
back then, JQuery didn't exist, SASS was several years off in the future. It
doesn't really count as "not invented here" if it _was_ invented here, and
just not made public until somebody else independently reinvented it.

It's somewhat unfortunate that there're such long lead times between invention
& publication, but also somewhat expected for a for-profit entity where
basically everyone who works on open-source does so in their 20% time. There's
also a strong desire on the part of many teams working on eventually-open-
sourceable code to have it running in at least one production server, stably,
with widespread adoption, to work out the kinks. I've worked on two projects
that eventually plan to be open-sourced (and initiated one), but the teams
involved don't believe them stable enough to be opened up quite yet. (This
despite one of them being in widespread use internally, and the other one
running in production in both Google Search and Google Maps.)

~~~
lobster_johnson
This is like releasing an incompetable jQuery competitor just because it's
been used internally for years.

This just creates more legacy code in a world full of legacy code. (By legacy
I mean code that will stick around for a long time.) It doesn't really matter
that Google has been developing this for years.

It would have been nicer and smarter of them to adopt Sass or Less (or at
least the syntax), thereby eliminating yet another source of redundancy. It
looks like it would be easy to do an automated translation of Closure CSS to
either Sass or Less.

Competition on merit isn't even a question here, imho. Closure does less than
Sass at the expense of a less elegant syntax.

The world of IT is full of these sorts of redundant projects. Competition is
good, redundancy is not. In situations like these, people need to do is reach
consensus on standardizing on _one_ great tool, or at least compatibility.

~~~
nostrademons
You don't get competition without redundancy.

Anyway, if I were founding a startup today, I would use the Closure suite over
Sass/JQuery/random templating engine/etc. Despite having worked quite
extensively with JQuery & random templating engines before Google (I even
wrote a JQuery plugin that's in use at a dozen or so different companies,
judging from the support emails I get), and still using them occasionally to
prototype with at Google. Why? Because it's an integrated set of web tools
that's better than the competition, because:

1\. There's still no alternative to Closure Compiler. It type-checks your
JavaScript, checks your dependencies, globally renames properties and
variables, strips whitespace, replaces expensive constructs with shorter ones,
and does this all basically transparently.

2\. There's no alternative to Closure Templates if you want to fill templates
on both the client and server sides (alas, if only the server side weren't
Java-only). This opens up a lot of possibilities for rich AJAX apps, having an
efficient JS templating language.

3\. It can globally optimize your CSS classes across JS/HTML/CSS, something
that no individual library could ever accomplish. Sass will minify your CSS,
removing whitespace. Closure Stylesheets will minify your CSS, and then
_rename all your CSS classes to the shortest possible identifier_.

4\. All of this is easily debuggable, with development mode flags to give you
the original names, so that you can use meaningful names in your source code
and get fast output code that doesn't make your users wait.

5\. Closure Templates are trivially internationalizable, and it's not hard to
extract all text in them for translation.

6\. Closure Stylesheets can Bidi-flip the entire page for RTL languages, so
that when you want to launch in Arabic, you don't need to worry about changing
all your Sass rules to include a $left variable that's 'left' in LTR languages
and 'right' in RTL ones.

7\. Closure Library has a wide array of UI widgets, including some pretty
esoteric ones.

I'd argue about Closure doing less than Sass. It does less _syntactically_.
But that's not the point; syntax is rarely the bottleneck when programming.
Closure lets you completely avoid thinking about several things that are _a
pain in the ass_ to get right if you have to do them manually. Like making
your JS tight and optimized so your site doesn't take forever to load. Or
internationalizing - heaven forbid your users want to use a language other
than English to read your site. Or creating separate debug & release versions
of your code so you can understand what's going on and still release something
lean & mean. Having worked in another corner of Google where many of these
things are still handled manually, I guarantee you that you'll lose more
productivity on them than on not having nested selectors.

~~~
lobster_johnson
Interesting points. I would never use Closure _because_ of many of the stated
points, since I would never want to risk being stuck with such a monolithic
set of tools. Same reason I don't want to touch GWT with a barge pole. Sass
and Less, on the other hand, are particularly elegant because their stated
scope is very small.

 _There's still no alternative to Closure Compiler._

Mozilla Rhino and the YUI JavaScript compressor both do the same thing (AST
parsing, analysis and rewriting) and have existed for a longer time. We used
Rhino exclusively for several years until Closure came along. Closure produces
a little more compressed code, but Rhino had fewer bugs for a while.

 _There's no alternative to Closure Templates if you want to fill templates on
both the client and server sides_

I believe there are several templating solutions that allow the same templates
to be run server- and client-side. Mostly based on Node, if I remember
correctly.

 _It can globally optimize your CSS classes across JS/HTML/CSS_

That's interesting and useful. How does it correctly identify JS code that
uses CSS classes? Does it look for $() and .addClass() and so on? Sounds
potentially brittle. Does it work with, say, Rails or Sinatra apps?

 _Closure Templates are trivially internationalizable_

I18n is a solved problem outside templates, surely. Eg., look at Rails i18n.

~~~
hongrich
For renaming css class names, you explicitly call them out by doing
goog.getCssName('class-name') in js and {css class-name} in soy.

<http://code.google.com/p/closure-stylesheets/#Renaming>

------
lambda
Ah, yet another CSS extension that adds variables and mixins. At some point,
shouldn't some of these projects come together, and say "we ought to
standardize this?" I realize that the CSS working group is against adding
variables and mixins to the standard, but given that there are now at least
three prominent (and incompatible) implementations (Less/Sass/Google Closure),
it seems like it's time to fork the standard (like the WHATWG did),
standardize something, and then see if you can roll that back up to the W3C
(or ignore the W3C if you can't get them to accept it).

~~~
wyuenho
I think at this point we really don't need more of these CSS supersets but
more comprehensive CSS frameworks like Compass and web framework integration
with these CSS frameworks, i.e middlewares and asset management tools. I for
once would love to see Compass ported to Less.

~~~
lambda
Well, yes, that's my point. We don't need more CSS supersets, we need fewer;
one standard one, that is called "CSS" (or "CSS4" or whatever). That, then,
can be the target for frameworks like Compass, instead of them targeting CSS
2.1/3 or targeting only a single CSS superset like Less, Sass, or now Closure.

------
djacobs
Honest question: Why would I use this over Sass?

~~~
fleaflicker
Closure stylesheets have one feature that no other framework has--
minification.

If you view source on a lot of google sites you'll see that style class names
are obfuscated.

The one caveat is that you need a sophisticated build system to pull this off
(though it's easier if you use the other closure tools).

~~~
drivingmenuts
I was going to argue that Compass has :compressed output, but halfway thru, I
realized you're right.

However, the beauty of Compass is that it doesn't rely on being intrinsically
tied to the HTML it affects, whereas Closure stylesheets do.

All things considered, I'll stick to Compass/SASS.

------
catshirt
damnit, google. no nested selectors?

------
nicwest
on a platform without javascript and where you're unable to even multiple
class elements (some eBook readers), this makes a lot of sense over LESS.

