4 ms·
The are a few problems with this approach. First, it takes more work. Second, it makes it harder to share values between CSS files. (Of course, you could add an
by pc 19y ago
The are a few problems with this approach. First, it takes more work. Second, it makes it harder to share values between CSS files. (Of course, you could add an @include statement to the "CSS++" language -- but that's starting to get pretty heavyweight.) Lastly, having yet another language is kinda unnecessary and confusing, as compared to just integrating ordinary Ruby expressions.
- antirez 19y agoFirst: you did the work just one time, it's a 10 lines of code function :) Second: I use only a CSS, and only a JS file, it takes a lot of sense because the client will cache them both the first time, so even without include it's ok most of the times. Lastly: It's semantically not more complex than your. Just @define to define and @symbol to expand. But of course it's just a point of view like many things in design. I wanted to share my view about this because I planned to write the interpreter for this stuff and write a blog entry. Thanks for your article I'm happy it makes sense for others to extend in some way the CSS in order to have some kind of symbols. CSS gurus and standard fundamentalists will usually reply that with inheritance you should never need this kind of stuff, but they lies ;)
- pc 19y agoAh, misunderstood you first time round. The problem with just doing symbol expansion is that you can't have values that depend on other values (like the "Width + 10" example in the post). For us, this has been a large part of the gain.
- antirez 19y agoPerhaps it's possible to mix this two things to get something like: ruby { .... ruby code defining stuff ... } attrib: @stuff Self contained, not a new language, able to define stuff relative to other stuff.