Symphony.

Hello,

I have been using SASS on my projects and it’s saving me a bunch of time building complex stylesheets.

http://sass-lang.com/
http://compass-style.org/
http://wiki.github.com/chriseppstein/compass

Many projects out there are using SASS. It’s not the fact that many projects are using but the power and flexibility that SASS provides.

I asked myself why Symphony shouldn’t use it?

What do you think?

I’ve been thinking about this sort of thing for a while now, looking at projects like SASS, xCSS, and LESS… if I ever find time (doubtful) I’m going to experiment with it…

From my point of view SASS is becoming more popular. Watch this video.

I asked myself why Symphony shouldn’t use it?

We had this discussion with a few other techniques (namely using jQuery) and the general feedback was that new techniques shouldn’t be adopted “just because they can be”. Or words to a similar effect.

I’m going to give SASS a go as I think it might help when rapid prototyping and creating wireframes directly into HTML :-) But I can think of several good reasons why Symphony should not use it:

• abstractions should take something complex and make it simple. SASS takes something that is already well-understood (and extremely well documented) and not particularly complex, and abstracts it
• the Vimeo video caption concedes “…learn the basics of the new Sass stylesheet language…” — from an open source point of view this increases the barrier to entry for contributors if they also need to learn the SASS syntax to contribute to the CSS/UI
• it adds a dependency on Ruby and potentially another step in the release procedure for the core team (to compile the CSS)

Do you find using SASS more useful when writing the CSS for a new blank project (saving time), or making minor modifications over time? Trying to work out where the biggest time savings are.

If Symphony wants to adopt his for the back-end, that’s fine as it makes no difference to me, a Symphony user.

However, the thing I like most about Symphony is it’s easy to display and manipulate the content on the front-end any way I wish. The only requirement is the use of XSLT. Anything that changed that would likely make me switch to another CMS. So I hope you’re not advocating changing the way Symphony interacts with the client-side of things.

I watched the screencast mentioned by rainerborene. I think that SASS/COMPASS is a very interesting new way of managing the presentation layer. You will probably end up with a less cluttered HTML code (and more complex, but more or less auto-generated CSS files). But I do not feel that this is something the Symphony backend should make use of. (I agree with Nick here.)

For building website frontends, the additional abstraction might nevertheless be very useful…

@rainer: Like Nick, I would love to hear about the biggest advantages.

I’m not sure if this is what rainerborene originally had in mind, but I’m just talking about the idea of bundling some CSS-related tools into an extension—maybe to enable the use of variables, possibly some OO stuff. That’s all. For me, there’s not even a question of something like this going into core, for the front end or the back end.

As far as the extension goes, ideally the learning curve would be minimal and users would barely have to alter their normal CSS-writing techniques, if at all. What I don’t like about SASS, as Nick points out, is that you essentially have to learn another language, another syntax. This doesn’t fit well with Symphony’s core principles.

I’m not sure if this is what rainerborene originally had in mind, but I’m just talking about the idea of bundling some CSS-related tools into an extension—maybe to enable the use of variables, possibly some OO stuff.

That’s the point. There are many possibilities that could help developers to take advantage of SASS. For example, providing mixing functions and variables. It would be really handy.

@nickdunn I understood your point of view and I agree with you. Fortunately, XSLT is already barrier to uses Symphony.

However, the main idea is to keep stylesheets lightweight and give developers the possibility to reuse these classes in a intuitive way (like jQuery UI CSS Framework).

Thanks!

Scaffold might be something to keep in mind. It has ported over some SASS. Plus you don’t need Ruby to compile. It runs off of good old PHP.

XSLT is already barrier to uses Symphony.

Perhaps, but XSLT is a standard whereas HAML and SASS are not.

I love SASS. I use it—often alongside Compass—for most of the projects I work on and highly recommend using it for CSS development. If you use it properly, it lets you rapidly brush through the repetitive bits of CSS and allows you to separate the structure of your CSS documents much more easily.

@Makenosound Just to clarify, I’m not saying that’s a bad thing but It took me some time to learn XML and XSLT before using Symphony. XSLT makes all the difference.

I love Symphony and that’s what matters :)

I love Symphony and that’s what matters :)

For sure, and I do think some way of integrating SASS into Symphony would be nice, it should definitely not be required though. I’ll have a think about a nice way of combining Sympony and SASS, something along the lines of the Datestamp Helper might work.

@Makenosound That’s a good idea.

Perhaps, but XSLT is a standard whereas HAML and SASS are not.

This is the most important thing. Is there any specific reasons to use SASS for the core besides that it looks cool at first glance? Symphony’s CSS does only change on a irregular basis - so why move away from a standard in one of the most standard based CMS?

The reason to introduce jQuery was (in my opinion) that most of the Symphony users do know how to build HTML and CSS but have no idea how to write JavaScript. JQuery is the widely adopted “industry standard” for those cases - that’s why Symphony implemented it (I’m not sure if jQuery was the best choice, by the way). But SASS? I don’t see a reason to implement something like it into the core.

Like Nils said, it might not be the best to introduce something like that into the core, but perhaps what rainer is getting at is what people previously mentioned, adding an extension to compile sass quickly and easily.

Maybe creating an Stylesheet extension that lets you edit raw SASS then saving it compiles it. It’d be a simple addition really.

Personally, I use Compass for CSS now, it makes cross-browser development slightly easier, enough to make me advocate using Compass and SASS. It turns CSS into more of a programmable language (only a tiny bit), rather than just a design language. SASS alone never did it for me, but add Compass into the mix and you can build sites much faster.

I think it’s a no-brainer to leave something like this out of the core. An extension sounds great.

I personally find this interesting, since most of my time is spent with HTML/CSS. My biggest issue is that it adds yet another level of complexity to an already very complex job. We already have PHP, JS, CSS, HTML, Flash, XML and XSLT all working together. Throw in extensions and other frameworks and you have a lot to troubleshoot when something goes wrong.

I’m beginning to want to move to more simple solutions with Web development. I don’t want to use layer after layer of frameworks and systems. Anything I can do to simplify things will save time. I feel like every site I build now is a house of cards. One little thing could send it crashing down.

There are only a few things that SASS offers over a CSS framework. The big one is variables, but a quick find-and-replace tends to do the job. I usually have the things I would place in variables already sorted out by the time I start my CSS anyway.

Also, being able to call bits of CSS that I can reuse isn’t really useful to me because I always have to edit the rules for the simple reason that I don’t want my sites to all look the same. One reason you design a site is so it has a unique look. Unique code goes against the purpose of these types of systems.

I was hesitant to use CSS framworks at first too and now I find them essential, so I might warm up to these things. Scaffold’s ability to create custom grid systems on the fly is brilliant! :-)

I personally use LESS. It reads like what CSS3 should be - it carries over your HTML’s structure into the CSS, and it’s not like learning a new language as with SASS.

It’s just CSS as it should be. Simple, clean, and powerful. I’m a huge fan of LESS :D

@ Throlkim, could I use LESS like this?;

On my mac, edit and preview my css with cssedit, as if it were css3, activate the LESS gem, and make it watch my files, so it automagically copies a css_lessified.css, which is a css2 file used for upload to the development server, whenever my orignal css file is saved.
And then over time when css3 is fully supported just remove the gem step from my workflow?

@rainerborene: Extension released.