Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
everyone — I was looking over a recent presentation on 960 Grid System, Refresh OKC – April 19th 2011, and on the penultimate slide (101/102), the guy recommends "if you're going to use Sass, use Sass, not SCSS." Given that SCSS is the new main syntax, why prefer Sass to SCSS? Is it simply a preference for conciseness over similarity to CSS, or is there a real reason for using Sass, not SCSS?
I can't think of a good reason :)
I looked at the whole set of slides, I think the presenter (who is also a connected to the SASS project, I think anyway?) is of the mindset to use what you know to "get 'er done"
Sass is supposedly shorter and more concise and it's possible that the speaker knows Sass inside out, but speaking from personal experience having read and written CSS for over 10 years I find SCSS much more intuitive. I do not have to learn the Sass indentation rules, and the brackets in SCSS and CSS provide visual indentation clues for nesting - which is very like most every other language uses, so anyone from a programming/coding background would be familiar with the idea of closing the nests??
.. more importantly every valid CSS is already a valid SCSS so no conversion needed to start using it - e.g. I was able to take my Drupal sheets (all 29 of them!), change their extension and recompile/compress them in very little time.. since then I've been able to take a little chunk at a time and "Sassify" it, using nesting etc. and I still like to see the brackets and semi-colons, it matters not, which you use once it's all compiled anyway!
IMHO Sass itself is too high a barrier to entry for a large project (existing one, i.e. one not built/sassified from scratch), where as it can be modularised with SCSS
So to follow the original author's (of the slideshow) thinking rather than debate pro's and cons I'll just keep using the one I know TYVM :)
I believe that the bracketed .scss syntax is currently the default only because it is more familiar to newbies who switch to SASS from LESS and vanilla CSS.
The indented .sass syntax was the first in SASS, being identical to (and making an ultimate team with) HAML. The new bracketed .scss syntax is similar to LESS, a competitor of SASS, both SASS and LESS make it possible to convert from CSS just by renaming.
The indented .sass syntax has only one drawback: it does not allow splitting function/mixin arguments into multiple lines. That can make the code harder to read (example).
In practice, this problem is rare and might be an indication that the code is poorly designed and requires refactoring.
The only yet decisive advantage of the indented .sass syntax is that it is much cleaner and easier to comprehend, while being equally expressive and powerful.
I have created an animation for you to consider the difference:
Also, didn't you hate it every time when your code failed to work/compile due to a semicolon missing (and maybe the interpreter/compiler producing a misleading error message)?
Basically, the indented .sass syntax just removes bloats of visual noise.
Of course, it requires some time to get used to it. At first it looks alien to anyone who has some experience with CSS or LESS. But once you get accustomized a bit, you'll find yourself feeling distaste to the bracketed syntax of CSS/LESS/SCSS and JavaScript and preferring the clean syntax of SASS, HAML, CoffeeScript and Python/Ruby.
Pros:
It's cleaner. Less visual noise. More elegant.
Cons:
The big one: Can't use newline. This is the only thing that I don't like about SASS. See example below.
The rest: Higher barrier to entry for people who struggle with the apparently difficult concept of indentation.
In SASS you are forced to stick to lines. So if you have
#function -create-gradient-from-color($bgcolor:#000,$depth:6%)
...code...
then you can't do this, which i find much cleaner
#function -create-gradient-from-color(
$bgcolor: #000,
$depth: 6%
)
...code...
That will throw an error because of the newlines.
But you can do that in SCSS, since it doesn't care about newlines
#function -create-gradient-from-color(
$bgcolor: #000,
$depth: 6%
) {
...code...
}
So I find myself keeping things terse in optional argument strings to prevent this situation.
I find SASS much faster to type.
SASS and SCSS both are a huge add-on to CSS - so different that I don't want to confuse them with standard CSS.
It's not hard to learn SASS - lose the brackets, and use tabs to decide nesting.
Related
I very frequently use the CSS line numbers in Inspect Element to find where a rule is in a particular CSS file. When Sass outputs a CSS file, it imposes its own style rules on it which really don't line up 1:1 with how my SCSS is formatted. This makes it hard to find CSS rules in my code because none of the line numbers match. It's completely disturbing my workflow and is a major barrier to my further adoption of Sass.
I've already looked at sass --style=expanded and sass --style=compressed but neither of them come anywhere close to matching the whitespace style I want.
What I really need is a way to make Dart leave all my whitespace and line breaks exactly as they are, and minify mixins down to a single line each. Something you might call --style=preserve-line-numbers Is it possible?
No. That is not possible by SASS itself.
If you like you may have a look to the avaiable styles:
https://sass-lang.com/documentation/js-api#outputstyle
But to be honest: if you use SASS in the intended way with nested styles, mixins, using modules ... the compiled CSS will considerably differ from the SASS code anyway. That even applys to the line numbers. So your problem is a common challenge in the coding process.
As fast debugging is important SASS offers mapping technique:
If activated you are able to see the source code in the browser on the fly. That's really easy and should meet your demands. Maybe you like to have a look on it. Here is a good overview to it: https://thesassway.com/using-source-maps-with-sass-3-3/
Or however if not that way there is another little trick/workarround which may help:
Most SASS projects organize/structures code in partial files (which doesn't make it possible to keep line numbers). That's for different reasons and speeds up working as well. If you do so you just start every file with a CSS comment which notes the file name only. As comments are shown in the browser tools you are able to find the relevant SASS source file without mapping ... and as partial files are almost not as long finding the relevant code (which differs from the CSS) should not longer be the problem.
// ### examples partial filename in a CSS comment
/* base-typography */
...
/* base-forms */
...
/* section-hero */
...
That is not as fast as mapping technique I would really recommend. But finding the code that way is faster than try to keep line numbers exactly the same and missing that way a lot of other advantages of SASS which speeds up my work (like nestings, setting SASS only comments, using mixins and modules ...).
This question already has an answer here:
Is there a SASS rule for outputting a descendant to the root?
(1 answer)
Closed 6 years ago.
For example, I want to make my code easier to read by doing this:
#article{
...
#article_inner{
...
}
}
However, I want it to compile into this:
#article{
...
}
#article_inner{
...
}
Is this possible using SASS?
Yes, #at-root will do what you want.
However, I question the premise of your question.
First, let's assume you really want to write #article { #article-inner {. For this, SASS will generate the code #article #article-inner {. You want it to generate #article-inner {. But why? Presumably you are concerned about the possibly lower efficiency of parsing, downloading, or applying the former as compared to the latter. Actually, though, any differences in efficiency would be miniscule to non-existent.
Second, I wonder why you think nesting the rules is "easier to read". Actually, to me it's harder to read. Presumably you think following the structure of the HTML is going to make it easier to read. Actually, following the structure of the HTML makes your CSS brittle. In computer science terms, this is called "coupling", generally considered a Bad Thing; in this case, you are coupling your HTML too tightly to your CSS. For instance, if for whatever reason #article-inner moved, or appeared somewhere else, then, even though the ID matched, your rule would stop working.
Experienced SCSS coders make very light use of its nesting capabilities. Instead, they write rules that are orthogonal to the HTML, which can be combined to create a number of styling effects, without being slavisly bound to the hierarchical structure of the HTML. Good SCSS coders I know limit themselves to nesting in the case of things like .class { color: red; &:hover { color: blue; } }, or in other cases to one level at most. In your case, if you have to use #at-root to do what you want, you have now actually made your code less readable in the name of readability.
SCSS is not going to live forever. Some day CSS will handle much of what it now does for us, including variables. Some shops are already moving away from SASS, with its ugly, verbose macros, mixins, hard-to-maintain features like #extend, and excessive nesting, back to raw CSS or forward to more modern preprocessors like suitCSS. We need SASS less and less for vendor-prefixing; other preprocessors support modularized, automated vendor prefixing tools. For all these reasons, therefore, it's not unreasonable when writing SCSS today to consider the potential that your code might need to be ported away from SCSS sometime in the future. That would indicate you should avoid using lots of SCSS-specific features when they're not really necessary, such as the nesting in your case.
If you want readability, add comments, which you should be doing anyway.
#article { ... }
/* The `#article_inner` element is inside `#article`.
#article_inner { ... }
More generally, I would question an ID-based approach to writing CSS. Presumably you intend to specify a bunch of properties on #article-inner, like font size, background, padding, or whatever. I've seen CSS where there are a dozen properties or more. What is the point? You might as well just write the properties in a style attribute directly on the element; at least then, you'd only have one file (the HTML) to manage. Instead, knowledgeable CSS designers create small, utility-like classes that can be applied to many elements. For instance, they might define a PaddedGrayBox class, that handles the padding and background. Then, they write in their HTML
<div id='article-inner' class='PaddedGrayBox FloatRight...'>
Now this is more readable. Someone looking at the HTML can immediately see what kinds of styling are being applied. If you take this approach consistently, you may find that you are able to do away with using IDs altogether, although I know that would be quite a departure for jQuery-oriented programmers who believe that doing $('id') (or getElementById) on every other line is the core of JavaScript programming.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
Can anyone recommend some CSS to less, or CSS to sass conversion tools? I have found a few .e.g. http://css2less.cc/ and http://css2sass.herokuapp.com/ but any insight into their reliability (or recommendations of other tools) would be greatly appreciated. I have a large CSS code base for a white label solution which would benefit greatly from having a CSS preprocessor in place but it would be a huge task to manually convert to sass/less.
Thanks in advance
EDIT: I should emphasize I'm particularly interested in experiences of using a tool (such as those listed above (in the absence of any better ones)) to convert a large CSS code base towards using a CSS preprocessor such as SASS or LESS. Or if any other ways (other than the tools listed) to achieve such a feat are pragmatic. What hurdles did you have to overcome? Is it even worth attempting? Or are such metalanguages only suited to a new project where you can start from scratch?
I made good experiences with http://css2sass.heroku.com/. You can also find their code base on github. You can also convert files directly via the sass-convert tool which will be installed by the original sass gem. Basically this is just what css2sass is doing.
Just call:
sass-convert -F css -T sass original_file.css converted_file.sass
The good thing about SASS is that you don't need to convert CSS into SASS, since SASS is an extension of CSS.
Simply copy and paste and you're good to go.
If you're looking to refactor your CSS into well structured SASS files though, thats something i don't think a tool can do.
This post needs the following 2 online tools listed for any future viewers.
Firstly, I would always run the css through this online tool to convert it to cleaner shorthand css http://shrthnd.volume7.io/
- no explanation needed really, just makes it all cleaner and smaller if you're not in the habit of writing your css that way already.
Then, through this online tool http://sebastianpontow.de/css2compass/
-This is a really good tool for creating scss files from your css. It will convert all colors to your preferred format, set color variables and font variables and overall give you a good idea of the basics of sass just by seeing what it did to your css.
The only thing I have noticed as not so desirable in the second tool is that it names font families like this $font_0: Open Sans; $font_1: Roboto Condensed; $font_2: arial; and so on. I always find it more intuitive to name them in short form of the actual font, or setup 3-5 names that relate to the content such as $font_main, $font_sub, $font_callout, $font_titles or however you prefer. But that's a 30second fix when you paste it all back into your brand new scss file :)
It's a bit late, but recently I found this online conversion tool:
http://css2sass.heroku.com/
It helped me out though it sometimes reject valid css
I actually found something now: Leafo
It does a basic formating, e.g.:
#header {
/* ... */
}
#header p {
/* ... */
}
to
#header {
/* ... */
p {
/* ... */
}
}
Hope it helps!
And if you want to verify or anything to view the sass to css, you can try the sass online website...
Try Sass Online
CSS style sheets have a habit of growing big and chaotic over time.
There are a lot of rules, hints, and schools of thought that help achieving cleaner CSS. (For example here) However, all those require constant alertness, activity and a lot of discipline on the maintainer's end, with mixed real-world success. As Nicole Sullivan so nicely puts it:
In fact, in most cases, the things we considered best practices were leading to the bad outcomes we sought to avoid. I realized (unpopular though it might be), that we couldn’t make it work out well by trying harder. Each time we start a new project, we think “this time, I’m going to keep the code clean. This time the project will be a shining example of what can be done with CSS.” And without fail, over time, as more content and features are added to the site, the code becomes a spaghetti tangle of duplication and unpredictability.
Are there any efforts to create a language of some sort, with strict structural rules and a merciless compiler, that enforces strict rules that prevent style sheets from becoming spaghetti? The compiled end result would be CSS.
I have no idea what such a language would look like and whether, given the vast amount of possibilities and combinations, this is a solvable problem at all.
Is there any research in this field? Anything to try out?
One very interesting related tool is CSS Lint, but what I'm asking about goes even farther than that.
Edit: LESS and SASS absolutely go into the right direction, but they are not what I am looking for. They introduce some very nice features and are a godsend for the CSS developer, but what I'm, asking about goes even further and more into defined, enforced structures.
You could very easily write spaghetti code in any interpreted language, so really what you are looking for is a CSS compiler. This is sort of what Google GWT does for JavaScript by generating it from Java code.
However, CSS doesn't have flow control, functions, variables etcetera, which means it doesn't make sense to have a higher-level language around CSS. At the root of it, it's just name-value pairs with cascading logic.
If you want to reign in your CSS code, you need to reign in your DOM as well. If you are defining columns with IDs left and right then you are semantically restricting the designer from moving them anywhere else. On the flip side, if you are smart about things you can do a lot more.
Lastly, the cascading part is what most new designers have the highest tendency to get wrong. If you pay close attention to the DOM and cascading logic, make use some good resets or grid-based frameworks and incorporate tools like LESS (Ruby) or LessPHP, you'll end up CSS that's far more pleasing to work with. I like LESS because It empowers you with quasi-functions, variables and nested properties which really helps clean up your CSS.
Are there any efforts to create a language of some sort ... The compiled end result would be CSS.
There are two efforts that I know of to do exactly this:
Less
SASS
Both aim to provide an improved version of CSS which allows you to write with more structure.
In addition, Google have demonstrated a development version of Chrome which incorporates a number of additions to CSS along similar lines. This is interesting because it indicates the future direction of CSS, but in the short to medium term you will need to use Less or Sass, as even the work in Chrome is very much experimental and will not be released for some time to come (and even when it is, you'll need to wait for the other browsers to follow suit).
[EDIT] Here's a link which details Google's experimental CSS features in Chrome: http://johanbrook.com/design/css/webkit-css-variables-mixins-nesting/
[UPDATE 18 April 2012] There has been some progress in this area since I wrote this answer. Slow progress, but progress nonetheless. The good news is that CSS Variables has just been published as a First Draft specification by the W3C.
See http://lists.w3.org/Archives/Public/www-style/2012Apr/0228.html for the official announcement of the specification.
So that's goodnews. Of course, how long it takes to get into the browsers and the end user base is anyone's guess, but at least there are signs of progress.
There is Stylus, something like LESS and SASS, but with transparent mixins.
That means that you can hide away complexity by bundling it into new key/value pairs. Example from the site:
border-radius()
-webkit-border-radius arguments
-moz-border-radius arguments
border-radius arguments
form input
padding 5px
border 1px solid
border-radius 5px
Maybe this kind of syntax is what you want?
PS: you can still type braces and semicolons, if you prefer ;)
Well you seem to know about Nicole Sullivan, so if you know about OOCSS already, I apologize, but no one seems to have brought it up. If you don't, it's her own project to do this very thing, I believe. It's only in Alpha testing right now, but you asked about efforts and not finished languages, so maybe this will be just what you're looking for. It definitely claims to be be for solving the problems you describe, but I haven't used it myself.
https://github.com/stubbornella/oocss/wiki
Have you checked out Compass? Compass is a framework built around Sass. I think it mostly adds features and boilerplate code to add a library of predefined mixins and whatnot. However, Compass might be even closer to what you want. Compass is based around Blueprint which is a straight up CSS framework (which may also be worth looking in to).
To me the best approach would be to take Compass and Sass (or CSS and Blueprint/LESS and something comparable) and to write a very concise and detailed style guidelines which you could develop overtime as you figure out what works best: your first thoughts on the matter, regardless of experience, may be wrong. Once you have these guidelines down you could talk to the people at Sass, Compass, LESS, Blueprint, whatever, about working in some of your well thought out and "researched" guidelines. OR you could start contributing to these wonderful projects which I believe are all under an open source license (Sass is under MIT, LESS is under Apache and I think Compass and Blueprint also under some form of open source license). Fork it and have fun :D
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Why do /**/ comments work in stylesheets but // comments don't?
In CSS there is only one way to create comments: /* I'm a comment */
The problem is that it isn't nestable.
Why don't we have an alternative comment syntax like //?
I think the real answer is that CSS treats newlines like any other whitespace, so it wouldn't make sense to have comments that are terminated by a newline. This is from the CSS1 spec: http://www.w3.org/TR/REC-CSS1
A CSS style sheet, for any version of CSS, consists of a list of statements. There are two kinds of statements: at-rules and rulesets. There may be whitespace (spaces, tabs, newlines) around the statements.
Of course, this also makes a lot of sense in the context of minification, as mentioned here: Why do /**/ comments work in stylesheets but // comments don't?.
It's not in the specification, and because CSS is widely used and supported, adding it in is virtually impossible. You can't just publish a new specification and expect all browsers to magically support it.
Internet Explorer 6, a browser more than 10 years old, is still widely used, so you can safely assume that even if this addition to the specification were made, it'd take another 10 years to be supported enough to bother. The problem with //-style comments is that they don't scale - unlike new HTML tags, which can be safely ignored as long as the rest of the document makes sense, adding a //-comment will break unaware user agents.
So the short answer is, we don't have it because we don't.
If it really means that much to you, write a script or macro that converts //-comments into /* */-comments, and apply it before running your web application.
There is a way to have // comments in CSS. If you use Sass/Compass.
I really like using Compass, because it gives me everything I miss about CSS, like functions, variables and so on...
Here is the Compass home page and the underlying Sass-language.
Compass is very nice, because you just have a program running in the background that compiles your Sass-code into real CSS, so your workflow is exactly as normal, but in other files (SCSS or Sass) and with very extended functionality!