Hacker News new | past | comments | ask | show | jobs | submit login

I would welcome this if I hadn't finally just gotten on board the SASS train. All I see this doing (for some ill-defined span known as "the present"), is adding another layer of headache into the browser compatibility game. Furthermore, I agree with VMG that there's something to be desired in the chosen syntax.



There's more to it than what Sass, Less and co. can provide. It simplifies dynamically changing a bunch of CSS properties from JavaScript a lot. Instead of changing all the elements using a particular style, you could now change just the variable instead. This gets even more interesting when properties are composed of variables, like gradient colors.

Also, this is a pretty high-level addition. I wouldn't be surprised if someone came up with a polyfill for this soon.


That's the biggest draw that I currently see. I would love to reference other features that SASS and LESS still bring to the table, but the idea of JavaScript fiddling with CSS variables is mouth-watering indeed.


To me it seems a logical progression would be for webkit to include SASS/LESS in the tool chain, instead of trying to re-invent the wheel.

Possibly some sort of solution where the browser receives SASS/LESS files and compiles them into CSS on the fly?


I can imagine you could create one stylesheet for browsers that support CSS variables, and one for browser that don't.


Wouldn't that 'headache' be prevented with SASS until it is supported across the board?


Oh definitely. I just mean to express that I'm not as excited as I otherwise would be. I'm not fortunate enough to be working on the types of projects where that can say to our market "You can take your IE7 and hit the road!" Thus while I wouldn't have been using these variables anyway, I would still have been very excited.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: