SASS

[nickdunn]

I've been using SASS for about 6 months now. It's incredible. My CSS has become so much more succinct and any repetitive fonts, sizes and colours are nicely abstracted into variables. It'd be great for Factory to be written in this way. If you don't use it yet, you could treat it as a learning exercise. Benefits:

• break up CSS into files and have them concatenated at runtime
• variables; define strings like colours, media query breakpoints and font families once
• mixins; useful for things like repetitive CSS3 vendor prefixes

[DavidOliver]

It's incredible

+1. I'd hate to have to write CSS directly now.

[lewiswharf]

+1 could not write without it now either; would be unbearable.

[nilshoerrmann]

We discussed that with Allen before starting to work on Factory and decided not to add additional dependencies. So we will neither be using SASS nor LESS.

[klaftertief]

But it's only a dependency during development, and only for the developer. Users of the factory will use the compiled CSS. And if they want to override or add something, they can stick to their preferred solution. It's not an essential dependency. So I don't see this really as an argument. (I was always sceptical about preprocessors, but started to love SASS.)

[nickdunn]

Shame; this is the perfect opportunity for a tool to save you time. Take a look at the source for Bootstrap (it's LESS) and tell me it's not infinitely more manageable than plain CSS.

[nilshoerrmann]

Okay, let me point out two things:

• The decision not to use SASS for Factory doesn't have any impact on how you guys set up your network sites: you can use SASS, LESS, vanilla CSS, whatever. Your own styles should be separated from Factory's core files nevertheless.
• The question for us was: do we want to add an other abstraction layer (SASS to CSS) to the project which people might have to learn when they want to contribute to the Factory later on? We discussed that with different people and came to the conclusion that it would fit Symphony's philosophy best to stick to standards (which is CSS, not SASS).

So far, we haven't used SASS in our other projects. We are not opposed to it but we also think that a framework like Factory can be easily managed with standard CSS.

But it's never too late to change decisions – let's wait for a few more opinions and especially for @allen to chime in.

[nickdunn]

Yep, I understand th decision. To counter those points however:

• if we choose to use something like SASS in our own projects, we'll each need to define all of he colours (etc) as variables, which creates the duplication that Factory suggests it aims to reduce
• I think it's safe to assume that someone contributing to Factory (not Symphony) is going to be heavily involved and a seasoned developer, not unable to copy a few terminal commands from a wiki to get set up

I'm not trying to force your hand—you really don't have to use it—but I'd urge you to give it a try, even if it's just while you play with some initial unreleased code. You'll find yourself using it everywhere afterwards :-)

[DavidOliver]

The decision not to use SASS for Factory doesn't have any impact on how you guys set up your network sites: you can use SASS, LESS, vanilla CSS, whatever. Your own styles should be separated from Factory's core files nevertheless.

We are not opposed to it but we also think that a framework like Factory can be easily managed with standard CSS.

I'd say a framework using a preprocessor is exactly the kind of project which benefits its users the most. As Nick pointed out, not having variables alone (for colours, font stacks, breakpoints, and maybe other Factory-specific things) would be a massive missed opportunity. It might also be the case that developers of satellite sites would find a few Factory mixins useful.

The question for us was: do we want to add an other abstraction layer (SASS to CSS) to the project which people might have to learn when they want to contribute to the Factory later on?

I would imagine that the styling would be pretty tightly controlled by a few main authors, anyway. However, if you used the SCSS syntax rather than the indented syntax, developers would be able to add normal CSS to the Sass stylesheet(s) and it would work as expected, as long as they were able to process the Sass locally during their development, which isn't hard. (On the other hand, the indented syntax seems easier and quicker to type so I always use this.)

It also seems pretty significant that two authors of existing sites already use Sass. :-)

I think you'd end up making the project a fair bit more convenient to its users and saving yourselves and its users much time in the long run by using a preprocessor.

[jensscherbl]

We discussed that with Allen before starting to work on Factory and decided not to add additional dependencies. So we will neither be using SASS nor LESS.

Good decision. Not because preprocessors are bad, but because then we would have to argue about which one to use (I would opt for LESS, by the way).

[DavidOliver]

I'm a committed Sass and Compass user but would still love to see LESS used instead of nothing. Either would have a substantially positive impact.

[jensscherbl]

Or (if they get some help from the community) provide all three flavors (CSS, LESS, SASS) along with the framework, so people can choose what to use.

[nilshoerrmann]

Or (if they get some help from the community) provide all three flavors (CSS, LESS, SASS) along with the framework, so people can choose what to use.

Because we love bloated frameworks, we created Bootstrap-Factory-Foundation. A design system that lets you build Symphony, WordPress and Drupal websites all at once. It's built in PHP, Ruby, Java and Markdown.

No. Definitely no.

[allen]

I've used both Sass and LESS. The Soario website uses Sass. The Symphony website Johanna & Nils expanded on for the Factory mockup, uses LESS. I appreciate the convenience that these compilers bring.

I am not committed either way.

Personally I like hand-crafting my CSS. I can't explain it, but "scripting" my CSS bothers me somehow. But that's just me. I also don't like so many different up and coming frameworks and having to pick one and stick with it, only to realise the industry ends up adopting the one I didn't pick. Remember mootools v.s. jQuery v.s. Scott's framework? That was fun.

Johanna & Nils, as you're tasked with doing the bulk of the work, using it may save you a lot of time, but if you guys simply do not enjoy using it, I think it's shitty to have to be made to use it. Factory adopters can still use their preferred framework and include the Factory source. I think Nick's argument is valid, that there's still some additional setup involved (declaring variables, etc.), but it's not that a huge of a trade-off, especially when there's always going to be the developer being stuck using a framework they don't prefer.

I'd say, Johanna & Nils, if you guys have tried both frameworks and like it, and the Factory adopters can unanimously agree on the one to adopt, then sure.

[jensscherbl]

No. Definitely no.

Thank God.

[DavidOliver]

Just another thought: if some thought is put in, the variables could really help here.

Example: a colour needs to change/be tweaked at some point in the future after Factory is in use. If a pre-processor is used and a variable partial included in the Factory file layout, the change can ripple through all satellite sites without the individual developers having to manually update their own custom style colours/variables. Once they pull in the relevant update, their preprocessor will spit out the new colour in the CSS on the next compilation.

(Colours shouldn't change often, of course, but it's the general principle of inheritance and less copying/pasting appled to lots of different aspects of the styling that appeals to me.)

[nilshoerrmann]

So, Allen and I have just been chatting on Skype about this topic and have weighed pro and contra of our three options (CSS, SASS, LESS):

• SASS is one of many projects that aim to simplify CSS creation. We don't know which tool will be the one "everyone uses" next year. It's not an industry standard, others are using LESS (see Jens' comment). So which one to choose?
• Nick and Mark who are already maintaining a network site use SASS. So should we opt for that as well?
• Pre-processors are really helpful when it comes to variables. But how often will you need these variable outside of the Factory core files?
• Pre-processors simplify the deployment process (combining and compressing assets). Thing is that we only need this feature when releasing a new version – which we won't do that often.

Johanna and I know the colours and metrics of Factory, they will be documented. Our guess is that if you are working with Factory, your main tasks will be HTML/XSL/Symphony related and less CSS oriented. You will need CSS for custom layout snippets that are not bundled with Factory – but you will most likely end up with custom measurements (all standard definitions will be available via CSS classes).

For Johanna and me, working with vanilla CSS to build Factory is just fine. We love some features the pre-processors offer, but we also think it's a quite fundamental decision to choose the one or the other tool: it won't be easy to go back afterwards. We don't know enough about how people will be using Factory to make a decision.

tl;dr

CSS is the smallest denominator of all discussed options. We are going to stick to CSS while developing Factory 1.0 and will revise that decision when Factory has been used in the wild for the first time.

[nilshoerrmann]

By the way, as posted on Twitter yesterday, Factory will also offer visual tools to build network sites:

[Tchilly]

I know, it's decided.. Still +1 on Less or Sass, more manageable code either way.. Cleaner & faster..

[nilshoerrmann]

Cleaner & faster..

And non-standard :)