Use superset of CSS

[jamesgorrie]

This has many benefits. The other thing is, by starting with it, we can always just use normall CSS and compile it down, as this is going to be included in our build systems anyway.

So what do we use? SASS? LESS?

LESS is in SBT and also compiles normal CSS as benefits for it.

[andymason]

I haven't used LESS/SASS myself but I'd be weary of adding another tool to the chain unless it's absolutely necessary.

[mattandrews]

I was initially against this but started using LESS for a personal project (purely for colour variables) and I think I'm in love.

[icodesido]

I'd like to see a pro/con presentation by someone who has used either before.

[jamesgorrie]

I think I'd go with Matt on this one. If you want to see what it does, go and use it. I know very few (I can't think of any) people who have used it on a project and thought "Na, not for me".

[andymason]

My concern is how it works over time on a large complex code base. Anecdotally, I've heard debugging can be tricky, I just wonder what other issues there could be.

While flat files have their issues, they're known issues.

A 'warts 'n all' presentation would be informative.

[icodesido]

The ability to edit other people's comments was NOT well thought out. https://github.com/guardian/gu-bootstrap/issues/1#issuecomment-4348988

[jamesgorrie]

Okay - something I will present on Thursday - as I personally think we are falling behind not using them.

[ahume]

Based on the fact that Matt created a pull request from his less branch (which I just merged in) - I'm presuming the consensus was in favour of Less?

Personally, I think even if we only use this for variables and mixins (cautiously) we are still ahead.

[ahume]

Also - I think we should define exactly what features we use, and how.

For example the nested stuff frightens me, because there's a potential to compile to very un-performant selectors. Eg, the topbar.css file compiles to things like ".topbar .dropdown-holder .dropdown li a" which is gonna be slower in most browsers than something we've optimised by hand.

Also, I think mixins are good for things like vendor prefixes, and re-using code that you would genuinely re-write in a different selector block anyway, rather than for sub-classing modules - which are better handled the SMACSS way, eg class="promo-box promo-box-large"

[andymason]

I wouldn't say their's consensus. Personally, I still have concerns about the the added complexity that pre-compiled CSS adds to the development cycle. Not only running a compiler locally, which I'm still amazing people brush aside so lightly, but integrating that into the build stack.

Also, I still haven't heard a good argument for how using a new scripting language to generate CSS will address the issues the current guardian site suffuses from which are partly down to a divergence from common patterns, with all the inline and !important's styles.

Now, after all that, I'm not against pre-compiled CSS (despite how it might sound), I just can't see the cost/benefit in favour of it at this stage and am concerned about getting locked into a non-standard mark-up. If we wanted to go back to vanilla CSS, can simply switch to the compiled out? I'd imagine not.

[ahume]

From what I've seen of the build, I wouldn't be surprised if LESS simplified it (the combo stuff is insane, right?). Graham's using it in the new SBT based build for R2 already (although only for concat/minification).

In terms of your second point I completely agree. A pre-processor does little or nothing to help issues of organising and ensuring consistency in patterns/usage. That is something that needs to come from the standards and conventions we come up with - and the decent documentation of those patterns. That's the real value of Pasteup, and why I could be convinced either way on Less/Sass (although currently I'd probably say I'm in favour).

In terms of the overhead, yeah possibly. I noticed Matt was using the client-side version which is OK for testing. I have the node version of less installed and have one command that compiles all the files into build/pasteup.css. I'm looking for a simple way to make it watch for changes automatically, and then it should all "just work".

Moving away from less if we don't like it - depends what features we have used I guess. I've only ever used these things very lightly for variables and a few mixins. That's mainly because I still like being in control and understanding the output. Once you start getting into the more complex evaluations and expressions possibly it gets harder.

[ahume]

Am I right to be worried that anyone (including the public?) can edit these comments?

yes.

PUNKED YOU LOL!!

Indeed, I am well punked lol. But I've just had it on good authority that outside people can't edit or delete these comments, so that's good.

[mattandrews]

Yeah, it's a little odd isn't it... it doesn't even indicate that the comment was edited either. Not sure if you saw the epic thread last week debating making Pasteup public (which I went ahead and did) but I guess this is one impact of doing that... wonder if it's worth asking GitHub if they have some setting for this...?

[mattandrews]

To be fair, we already use all sorts of behind-the-scenes CSS "compiling" when we run R2 locally (to the point where you have to run "ant deploy static" to recompile every time you change a local file). Integrating LESS into this will be pretty similar (and according to @tackley, even easier, since a lot of the plugins do things like watch files for changes and recompile on the fly). We have a bunch of Velocity templates with hardcoded colours that are compiled down into CSS files with placeholder variables, so to be honest I think switching to LESS would be an upgrade to this system, given that we're currently using a templating engine to hack these kind of behaviours in.

I agree with Andy that we need some consensus on which aspects of LESS to use. Variables is an obvious one and some mixins are useful (have a look at Bootstrap's use of LESS to generate custom grids), although I think a lot of the nested rules stuff seems to miss the fact that this behaviour is build in to HTML/CSS when used correctly.

Re: moving away from LESS. Well, if we use a minimal subset then it should be fairly trivial stuff to just rename .less files to .css and strip out uses of variables and mixins to their native equivalents. We could even write a Python script or something to prototype this, so at any moment we could pull it out and fall back to defaults. Thoughts?

[ahume]

I've personally got no problem with these threads being open - or even having externals contributing to threads if they're that keen. As long as they can't edit or delete anything we've written - which according to my external friend I asked to test yesterday, they can't.

[andymason]

I think we should separate the deployment process from the development process. How files are minified or compressed is one thing but that doesn't alter how we fundamentally write CSS. R2 does a lot of funky stuff with velocity templates but pasteup is our opportunity to simplify it. So why not start simple?

As we're starting from scratch, would it make sense to see have far we get using vanilla CSS in a OOCSS pattern and then, once we've identified a need for less, integrate it.

[icodesido]

I couldn't agree more.

On 20 March 2012 14:17, Andrew Mason < reply@reply.github.com

wrote:

I think we should separate the deployment process from the development process. How files are minified or compressed is one thing but that doesn't alter how we fundamentally write CSS. R2 does a lot of funky stuff with velocity templates but pasteup is our opportunity to simplify it. So why not start simple?

As we're starting from scratch, would it make sense to see have far we get using vanilla CSS in a OOCSS pattern and then, once we've identified a need for less, integrate it.

---

Reply to this email directly or view it on GitHub: https://github.com/guardian/pasteup/issues/3#issuecomment-4596112

Ivn Codesido Web Developer Guardian Technology

Please consider the environment before printing this email.

Visit guardian.co.uk - newspaper of the year

www.guardian.co.uk www.observer.co.uk www.guardiannews.com

On your mobile, visit m.guardian.co.uk or download the Guardian iPhone app www.guardian.co.uk/iphone

To save up to 30% when you subscribe to the Guardian and the Observer

visit www.guardian.co.uk/subscriber

This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way.

Guardian News & Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software.

Guardian News & Media Limited

A member of Guardian Media Group plc Registered Office PO Box 68164 Kings Place 90 York Way London N1P 2AP

Registered in England Number 908396

[jamesgorrie]

For now Less is being used it seems.

[andymason]

Wait, so is the criteria closing issues just wait till the discussion stops for a while?!

Less is being used because it was added to master before a discussion was had to include it.

[mattandrews]

I think for me, we already have a ton of hacky nonsense inside R2 for doing things that LESS does in a more sane way. We could perhaps pull it out until we specifically need it, but I know the minute I get a design with different section colours, it's going to come in handy. I agree though that we need a better process for signing off issues here, consensus is difficult to come by. Will talk about this in tomorrow's meeting...

[ahume]

I've removed the Less syntax in master ab13ce2.

So - I propose that if you want to add Less syntax in, you have to explain why/how it's better than other approaches, such as OOCSS techniques, or sensible presentational class names, etc... Essentially make sure we've considered how to better use what CSS gives us before we run in to extending it.