Google: Introducing Closure Stylesheets

http://googlecode.blogspot.com/2011/11/introducing-closure-stylesheets.html

by packetslave • 15 years ago

75 32 15 years ago

googlecode.blogspot.com

latchkey• 15 years ago

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.

djacobs• 15 years ago

Honest question: Why would I use this over Sass?

gbog• 15 years ago

I guess if you already used one or more of the Closure Tools, you might want to use Closure Stylesheets over Sass, even if Sass was slightly better.

fleaflicker• 15 years ago

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• 15 years ago

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.

malandrew2• 15 years ago

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.

allertonm• 15 years ago

Well, to be fair to Google, this looks very similar to the CssResource mechanism that has been in GWT for a while now, with the addition of mixins. If this is an evolution of the GWT version it's likely to be fairly mature "out of the gate".

choxi• 15 years ago

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

KeithMajhor• 15 years ago

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

vidarh2• 15 years ago

I'm glad they did - if for nothing else because I find the Coffeescript syntax obnoxious to the extreme.

bdr• 15 years ago

Your questions aren't a response to reality. Google has these tools that they use internally. They can either work to release them publicly, or not. I'd prefer they do.

adgar• 15 years ago

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

You need to understand that when an announcement like this is made, the development behind it happened over the course of years.

It isn't as if a few days before the announcement blog post is linked on HN, somebody made the decision "we can use Less, or Sass, or write our own. Screw those guys, let's write our own and release it open source!"

malandrew2• 15 years ago

Next question: Why now? If this was being worked on for several years, why wasn't it released much sooner?

I have nothing against projects coming from Google. I'm all in favor of it. However I think Google acts as a much better open-source citizen when it adopts a posture like it has with HTML5. With HTML5, Google got involved early and publicly and one of their employees works as a benevolent dictator, which in the case of HTML5 is Ian Hixie.

When a project is released from some company, with no real defined ownership in the form of one human being or a small team at that company, it is a far less compelling project to get involved with, and the likelihood of a community being formed around it is low.

beej71• 15 years ago

Why didn't Google decide to instead contribute to Less or Sass

I'll see you and raise: why didn't Less contribute to Sass? ;-)

I don't see either question as being a problem in real life. You're going to have to have the build tools installed for any substantial web project you work on, and it's going to be less, sass, uglifyjs, closure, yuicompressor, the one I use that you've never heard of, or something else. Exactly which tools used is not particularly important.

And if you look at the Closure Stylesheets docs, it takes about 10 seconds (literally) to get it, if you're already familiar with similar systems. And if you're not familiar with them, you're riding the learning curve no matter what system you choose.

Finally, as to the observation, the argument is extremely compelling if you are deciding which toolset to use on your new project. Should I use Closure + Sass? Or should I use Closure? What do Less and Sass bring to the table that Closure does not?

(I'm not badmouthing these fine projects, and would not fault people for using any of them.)

dstein• 15 years ago

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.

catshirt• 15 years ago

damnit, google. no nested selectors?

lambda2• 15 years ago

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• 15 years ago

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.

lambda2• 15 years ago

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.

baddox• 15 years ago

Unless it's the standards group that's going to standardize it (which like you say is unlikely), what exactly is the advantage of the projects getting together to "standardize"? It may seem good to the average end developer, simply because there's fewer deliberation to be made, but I suspect the "competition" is probably a net positive for everyone.

The way most of these things go is that over time, either one of the projects becomes the de facto "best one," and the other projects eventually fade away, or two or more projects make some significantly different choices and thus branch off in multiple directions, each with its own community of contributors and users.

skrebbel• 15 years ago

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

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

nostrademons3• 15 years ago

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_johnson2• 15 years ago

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.

vidarh2• 15 years ago

To me that tells me that they don't understand central aspects of open source, and/or are worried about losing control.

When companies take this approach, it dramatically lessens the value of what they release. Case in point: Your description above. If this had been released around 2006, it could've had a dramatic impact. Now there are plenty of alternatives.

nickand• 15 years ago

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.

nostrademons3• 15 years ago

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.

nl• 15 years ago

I think it's fair to say that people at Google do actually know this is possible.

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

That's no better, because you have to duplicate your selectors. You end up with stuff like:

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

.yetSomeOther .moreSpecificTarget {border: pink solid 1px;}

.anotherClass, .yetSomeOther {margin: 5px;}

.yetSomeOther .moreSpecificTarget {margin: 1px;}

Basically if you follow this model you have to have a line for every single property you want to style. It's unmaintainable, and increases the size of your CSS files.

nicwest• 15 years ago

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.

Google: Introducing Closure Stylesheets

Related Stories