Why Sass?
alistapart.com
alistapart.com
I feel that sass is like an amplifier of css. It doesn't actually solve any of the short comings of css. It enhances the features of css, both good and bad parts.
I really want css preprocessor that is non obtrusive. So that the file could still be parsed as valid css. Any feature enhancements used by the preprocessor just get ignored by the engine.
It's in Chrome and FF on a Mac, and it's been this way for months. I assumed it was a bug that they'd catch, but I guess I'm the only one seeing it this way?
I agree though, that insofar as good design is really about communicating information to normal people, A List Apart just dropped the ball there. Maybe the fact of the matter is that the elite designers sometimes get bored that they never get a chance to let their creativity out? I'm not sure, just thinking out loud. :)
It's that way because they want it—Jeffrey Zeldman and the ALA team. It's their playground.
It looks like that because it's striking. Gets the people going. Made you look. Got you mad.
It breaks the mold of traditional website design:
| Logo | Nav |
|----------------------|
| Content |
| Additional info |
| Editorial info |
There's a place for purely functional design, and there's a place for experimental design.
"Hey guys, listen to us about design, we can't even get basic things right!". That's the message I get.
It's ALA's willingness to experiment (even if the end result is suboptimal) that made people listen to them about web design.
1. Tooling integration is a PITA, especially with Visual Studio.
2. Nothing but trouble merging the stored output from the tooling if you are in a branchy development. Basically, merge the CSS, then run sass/less and check in the change. Too much friction on a large project, especially when it comes to a non-Sass/Less dude doing the merge.
3. Parsers are both shit. Sometimes attributes don't get "understood" properly resulting in compile errors and point blank refusal to work.
4. Hacks used for older browsers aren't parsable by either.
5. It's another layer of abstraction. Less abstraction decreases debugging effort.
Sorry but I don't buy it despite the promoted advantages.
Wtf? You don't check generated files into VCS. You check in the source sass/less, and do the generation as part of the build process.
There is no bloody reason to merge it though, just wipe it, merge sources and regenerate.
What happens is, you get three options:
1. Deploy Ruby, Sass and associated dependencies to every workstation, build agent, test machine etc. Deploy tooling and build integration to the above so that any changes to .sass files in the IDE and build process get reflected on disk in the VCS. Educate every developer who touches the project on what they are, how to manage them effectively, the rules around merging etc.
-or-
2. Do the above but ship the entire Ruby VM and libraries in your VCS.
-or-
3. Get random build failures company-wide, old versions of generated CSS files and crap floating around and being checked in by developers, half arsed merges and just pain.
I'll pick option (4) which is don't use it.
I've been at ALL of the above steps. We have removed it from our product. Life is better now.
5. Use CodeKit[1] on the Mac, and similar tools for Windows.
I can't tell you which ones on Windows are the best but damn it sure is nice to just casually write SASS/LSSS and have it get compiled when you save it because the compiler's sitting there watching for file changes.
1: http://incident57.com/codekit/ 2: https://www.google.com/search?client=safari&rls=en&q=codekit...
This should be easy. If it is hard that means your deployment/ops infrastructure is inadequate, and you should fix that now rather than after your build machine suffers a hard disk failure.
> Educate every developer who touches the project on what they are, how to manage them effectively, the rules around merging etc.
You don't edit files that aren't in VCS; if some files are ignored you assume there's a good reason for it; you edit the source version, and you merge the normal way you merge source. These are all standard rules of development that every developer should know.
I guess using sass means every developer needs to learn sass, sure. But in terms of how quickly you can learn, and how much time it saves you over editing raw css, that pays for itself in like an hour.
i still use LESS for its conciseness, the abstraction layer really ain't so deep or different (like CoffeeScript) that you can't track down where the issue is very quickly.
FTFY. Jetbrains IDE have sass support.
> 2. Nothing but trouble merging the stored output from the tooling if you are in a branchy development. Basically, merge the CSS
There is no reason or justification for merging the CSS. Merge the source, regenerate.
> especially when it comes to a non-Sass/Less dude doing the merge.
That's not a problem with Sass or Less or whatever.
> 3. Parsers are both shit. Sometimes attributes don't get "understood" properly resulting in compile errors and point blank refusal to work.
Incorrect source not compiling correctly is not exactly abnormal. The only issue I met was the watcher getting wedged once in a while after a bad compile (no issue with IDE-integrated compilation since it does the watching and recompilation explicitly)
> 4. Hacks used for older browsers aren't parsable by either.
Not seen any issues with that.
> 5. It's another layer of abstraction. Less abstraction decreases debugging effort.
At the cost of increased maintenance effort.
But I can't write C# in it.
> There is no reason or justification for merging the CSS. Merge the source, regenerate.
Regeneration is a problem when you have lots of developer workstations, build agents and test machines to deploy the Sass stack to.
> That's not a problem with Sass or Less or whatever.
Nope but it's a real problem. Some of our guys don't do the web.
> At the cost of increased maintenance effort.
Well the maintenance effort went up to unacceptable amounts for us so I don't believe that.
Not part of VS proper but if you can use extensions it's a good alternative. I haven't used it unfortunately as my work doesn't really keep me in VS for web dev but the tooling should be rather decent from what little I've touched. YMMV though, obviously.
Doesn't change what I wrote.
> Regeneration is a problem when you have lots of developer workstations, build agents and test machines to deploy the Sass stack to.
It's no more a problem than all the other stacks you have to deploy. And if you can't deploy any stacks, maybe that is the core problem.
> Nope but it's a real problem. Some of our guys don't do the web.
They won't be able to merge HTML, CSS or JS any more reliably than Sass or Less, why are they doing those merges? Do you also ask designers to merge WPF?
If you can't make something like sass work with your version control, it's a problem with your workforce or workflow, not the technology. It is trivial to set up a ruby command line on any OS and then have a .gemfile in your version control to ensure that everyone is using the same version of sass. Then all that is required to generate the css files from the sass sources is opening up a command prompt with ruby and typing `compass watch`. It's worth it for the time saved writing css.
> Nope but it's a real problem. Some of our guys don't do the web.
Is it not also a problem that you have people writing your css who "don't do the web"? That seems like the bigger issue here to me.
If you read my comments carefully, you will see this is a merge time issue. Many different people do merges. Some reintegration merges will be performed by people who don't do web stuff. There may be trivial web changes on a feature branch but people have absolutely no idea about Sass or associated tooling. They can cope with css fine.
Our product has about 5000 lines of css and about 3 million lines of other languages. Web is a tiny part of our applications.
All of your problems are actually easily solvable, but it'd be rather pointless to use sass on a project that only has 5000 lines of css anyways. About as pointless as commenting on a thread about a technology you don't really understand to say that you "refuse to use" it, then trying to prove everyone wrong for pointing out that your issues with it are actually either not actually issues with the technology or have trivial solutions (i.e. you're not the first person to run into these issues).
It's somewhat neat, actually. Not necessary by a long shot but 1. there's a chance the IDE understands the precompiled languages (and offers syntax checks, autocompletion, etc...) and 2. you don't need to run the compiler/watcher because the IDE takes care of that when you or it saves, as part of its normal "stuff to do when saving".
Never, ever handle output files directly.
Re 3/4:
So far I haven't seen a single useful thing that SASS doesn't process. Chances are that those attributes/hacks aren't something you want to have in your CSS to begin with.
[1] http://www.yonbergman.com/2012/05/19/why-you-should-use-sass
What is your reason for merging this? Accept whichever set of changes you want then rebuild the generated css at the end. If you can swing it not committing generated CSS to development branches is the way to go, but that isn't always an option.
Another option is to push merging/building duties off to your CI server. Little weird but it keeps things consistently updated and provides a backstop against parser errors.
I totally understand the reasoning to move towards scss though, and it's easy enough to flip between them.
p {
margin-bottom: 20px; font-size: 14px; line-height: 1.5;
}
footer {
margin-bottom: 20px;
font-size: 14px;
line-height: 1.5;
}
p, footer {
margin-bottom: 20px;
font-size: 14px;
line-height: 1.5;
}p { margin-bottom: 20px; font-size: 14px; line-height: 1.5; } footer { position: fixed; margin-bottom: 20px; font-size: 14px; line-height: 1.5; }
p, footer {
margin-bottom: 20px;
font-size: 14px;
line-height: 1.5;
}
footer { position: fixed; } p, footer {
margin-bottom: 20px;
font-size: 14px;
line-height: 1.5;
}
footer {
position: fixed;
}
p, footer {
margin-bottom: 20px;
font-size: 14px;
line-height: 1.5;
}
p {
text-align: justify;
}
footer {
border: 1px solid black;
}
@mixin default-type {
margin-bottom: 20px;
font-size: 14px;
line-height: 1.5;
}
p {
@include default-type;
text-align: justify;
}
footer {
@include default-type;
border: 1px solid black;
}
Example: style.css.php
<?php
header('Content-Type: text/css');
$brandColor = "#fc3;\n";
$defaultStyles = <<<STR
margin-bottom: 20px;
font-size: 14px;
line-height: 1.5;\n
STR;
?>
a {
color: <?php echo $brandColor; ?>
}
nav {
background-color: <?php echo $brandColor; ?>
}
p {
<?php echo $defaultStyles; ?>
}
footer {
<?php echo $defaultStyles; ?>
}However the reusable block makes no sense. That's what multiple classes on an element and selector lists are there for. I can't tell if SASS will still help me, since this is merely a bad example.
So it could mean that either he didn't think that through, the book isn't very good because of his lack of understanding, or that SASS is mostly fluff.
* Wrapping up vendor specific properties. Put all of them into a mixin, use arguments for the value and any edge cases, be sure that all vendors are covered properly at each usage site.
* @media directives in SASS can be used inside a style definition.[1] IME this makes heavy use of media sensitive styling significantly easier to read/manage.
* Nested rules and nested properties[2] help to make your styling cleaner. If your html already has a very component-like structure nested rules can mimic that, which makes the overall design easier to manage.
A lot of the functionality of SASS is geared around reusing bits of styling. Much of what you can do with it could also be done with multiple classes, but that generally comes at the cost of a class explosion as you parcel out the differences.
It makes it easier to move more of the declaration of how your styling works into CSS itself, instead of the final styling being almost equal parts html (and classes) and CSS, with you as the developer/designer being responsible for remembering how all of the details fit together.
[1] http://sass-lang.com/documentation/file.SASS_REFERENCE.html#...
[2] http://sass-lang.com/documentation/file.SASS_REFERENCE.html#...
If you hate or don't get CSS to begin with, stay the hell away from SASS.
If you do serious work with CSS, SASS will probably help you solve things better.
Of course if you have existing CSS it might make sense to use LESS / SCSS.