atom/language-sass

Sass package for Atom

Atom and all repositories under Atom will be archived on December 15, 2022. Learn more in our official announcement

Sass/SCSS language support in Atom

Adds syntax highlighting and snippets to Sass/SCSS files in Atom.

Originally converted from the Sass TextMate bundle.

Contributions are greatly appreciated. Please fork this repository and open a pull request to add snippets, make grammar tweaks, etc.

language-sass's Issues

Sass *.sass files have no auto completion

While .scss file extension has auto complete working quite well, working at a couple of projects that use .sass files, I have noticed that there is no auto completion for properties and values.

link to gh issues is wrong

Issueception:

Media queries over multiple lines

language-sass seems to have the same issue as language-css had.

atom/language-css#4

Media queries over multiple lines are treated as normal text.

custom tag coloring problems

Im using Angular and custom-tags but it does not get the right colors

Autocomplete issue with punctuation

I'm not sure if this is an autocomplete-plus issue or a language-sass issue, but I'm getting suggestions popping up after hitting characters like comma, semicolon, and space. If I try to hit enter quickly after, say, a semicolon, doing so adds "align-content:" (I suppose matching from the top of the suggestions list) instead of breaking to a new line.

Incorrect scoping of css attributes

See attached:

The scss file can be downloaded here: http://cl.ly/code/2v0E0O3y3k3n/dswp.scss

Syntax bug with property names

If you look at this screenshot, you can see the tags and a few of the attributes are the same color. It's because the scope .entity.name.tag.scss applies to both tags (such as label here) and to some attributes (like margin-top here).

I noticed that most of those errant attributes were scoped as .entity.name.tag.custom.scss so I added that to my theme css along with the other selectors for css/scss property names.

From and to keywords highlight inside @keyframes definition

from and to keywords aren't being colored properly:

I think the right way to do it is matching them only when inside @keyframes definitions, but I don't know how to do it.

Numbers used in maps are scoped css css number values

For example, this code:

$chord1: (color1:$pb-dark-orange, color2: $pb-magenta, color3: $pb-light-gray, color4: $pb-yellow);

The numbers in the map (e.g. the "2" in "color2") are scoped constant numeric scss like "regular" numbers (e.g. "2px") in a css value instead of matching the rest of the list item title.

The list item title does not have its own scope either (I realize this is a very new sass feature):

TypeError: Error linting

Every time I try to save a scss file, I keep getting this error. Used to work fine, so I'm wondering if there was a recent breaking change? Running Mac OS X 10.10.5 Yosemite.

Relative protocol highlights as if it were commented out

.brand {
    background: transparent url(//placehold.it/350x500) 0 0 / cover no-repeat;
}

It renders completely fine in the output css it just appears to be commented in the editor.

Perhaps there's a way to detect if // is within url() and disable the comment highlighting?

Comments affect syntax highlighting of first non-empty line below them (indented syntax)

The syntax highlighting is slightly bugged for the first non-empty line below a comment. See:

Tested with multiple themes, each has issues: Railscast (pictured), Monokai, Atom Dark, and Atom Light.

syntax highlighting support for extends

Currently not highlighted:

Sass 3.3 parent selector suffixes treated as invalid

Parent selector suffixes are getting .invalid and .illegal classes, but they are valid .scss as of Sass v3.3.

`order` property (flex-box) is highlighted in red

Info on order: https://developer.mozilla.org/en-US/docs/Web/CSS/order

Syntax highlighting with erb

Files with extension css.scss.erb are not highlighted

Syntax highlighting bug with comma-separated @imports

The highlighter doesn't recognize comments between import statements that are comma-separated and on new lines.

translate3d(0, 0, 0) is assumed an RGB value

    div {
         -webkit-transform: translate3d(0, 0, 0);
    }

0, 0, 0 is given the class name constant other color rgb-value scss

@import "blueprint"; overriding @import "$0"; snippet?

I'm new to Atom so there may be a trick I'm not aware of but every time I type import then press tab it completes as:

@import "blueprint";

In language-sass.cson the last two lines are:

  '@import':
    'prefix': 'import'
    'body': '@import "$0";'
  'blueprint':
    'prefix': 'import'
    'body': '@import "blueprint";$0'

And I'm guessing that the last bit is overriding the snippet I want. Is there something I need to do to be able to use the @import "$0"; snippet instead?

Did atom compile css files?

sorry for question, but did atom compile css from scss?

SCSS: Variable in selector / BEM Syntax breaks highlighting

If I use a variable (#{$variable}) in a selector in combination with the BEM syntax (two underscores __ in particular), the code highlighting seems to break:

I tested this with multiple themes, none seems to work.

Parent selectors do not appear in symbols list

.foo
  &-bar
    background: red

It would be very helpful if &-bar appeared in the symbols list when pressing Cmd+R

syntax highlighting support for silent classes

currently breaks at dashes:

Edit: actually it breaks at the percent symbol i guess...

Incorrect highlighting for flexslider css

When rendering this file: https://gist.github.com/kevinansfield/7828567ad5efd9367d55

Sublime text (correct):
Atom (large chunks lose correct colours):

Support autocomplete for referenced parent selectors

Currently if I write .plac it will find only .place class name, and not .place__header.

.place {
  &__header {

  }
}

http://sass-lang.com/documentation/file.SASS_REFERENCE.html#parent-selector

Support for single line comments

When clicking CMD + / the editor creates a multiline comment by default.

It would be great if there was an option to choose between multiline comments and single line comments.

The multiline comments are preserved in the CSS output where possible, while the single-line comments are removed

I believe Sublime Text does the single-line comment behavior by default if you need an idea of intended usage.

Comment issue

When I use cmd + / to comment code it wraps the code in /* */ instead of using // on each line. Is there a way to change this configuration?

italics and bold on lines immediately following a comment

If you have sass directly underneath a comment, the text following the comment becomes bold and italic, if you leave a blank line in between, it behaves as it should. This is happening with Atom v.205 and language-sass v.38.0.

---

meta.selector missing (provided by CSS though.)

When working on a syntax theme I noticed that Less does provide meta.selector for tag {} like CSS, can we please get this so that we can provide consistency across multiple different kinds of CSS source types.

Bracket incorrectly syntax colored

Using Atom's Solarized light:

'text-' properties not syntax coloring properly

v0.19 (for some reason I cannot update to .20 or .21, but see them as releases here)

Changed syntax language to CSS and properties color correctly, so this is not an issue with the Theme.

nth-child inconsistent coloring when using an+b format

the n in the an+b format is badly colored.
Here is an example:

Typo in scope name

See attached typo for "punctuation"

Comment blocks should be `//` not `/* */`

When writing SCSS/SASS, I would expect that the comment command would use the // style instead of the /* */, I think there was a recent change in either the editor or the language bundle to change the style of comments and it is driving me nuts, almost to the point of using another editor for when I write SCSS on projects. There is a big difference in how they treat the normal CSS style comments which are still compiled, and the // comments.

/* .button{
  color: red;
  &:hover,
  &:focus{
    color: darken(red, 10%);
  }
} */

becomes

/* .button{
  color: red;
  &:hover,
  &:focus{
    color: darken(red, 10%);
  }
} */

while

//.button{
//  color: red;
//  &:hover,
//  &:focus{
//    color: darken(red, 10%);
//  }

becomes

@at-root syntax

I got problem when write @at-root ( new syntax in sass 3.3) in scss. Editor highlighting that as invalid syntax.

Inconsistent operator coloring

When you use the addition or subtraction operator with a number, it becomes the same color as the number. The other operators don't do this.

This example is using the Atom Dark syntax theme:

RGB color incorrectly scoped in variable.

In the attached, # is correctly scoped as constant other color rgb-value scss, but the actual hex numbers are scoped as punctuation definition constant scss

The entire color (e.g. #CC0000) should all be constant other color rgb-value scss

Improve support for parentheses in function invocations

The following is highlighted incorrectly:

@include foo((bar: $baz));

.foo {
  margin: foo(n 0 (-$foo) 0);
  margin: foo(n 0 (-20px) 0);
}

Atom example

Note how the part in the inner parentheses and the opening inner parenthesis are all highlighted in red here.

Sublime example

Here, the content in the inner parentheses is highlighted as usual.

box-sizing: border-box is not highlighted correctly.

Looks like border-box is not being identified as a valid symbol.

Single quote in inline comment breaks highlighting for the rest of the file

Nested closing selector brackets are not colored

.Footer {
    background: #000;
    width: 100%;
    text-align: center;
    padding: 34px 0 18px;
    display: block;
    box-sizing: border-box;

    .page--front & {
        @media (min-width: 805px) { display: none; }
    }
}

Neither of the two final closing brackets are syntax highlighted.

No indication on whether or not the current file is being understood as .sass or .scss

In the bottom left indicator that indicates the type of file you're working on, it doesn't tell you whether or not the current file is being interpreted as a .sass file or a .scss one.

This is important since it'll help you understand whether syntax highlighting is not working at a particular time--especially with new files because of incorrect syntax usage on your part.

Crashing Atom

I can't figure out why though. I went through a plethora of plugins (color picker, linter, etc) and almost all of them had no effect. Essentially the moment I start typing characters, after about a second editor complete locks up. I'm on OSX, and when I check the force quit dialogue, atom does not appear as 'not responding' but after 1 minute of waiting atom itself prompts me that it's no longer responding and offers to force close. Disabling this one plugin has proved to allow me to continue working. Is there some way I can get to you debug information?

CSS3 will-change property incorrectly highlights red in SCSS file

Say I have a button.scss with

@mixin btn-gradient($c) {
  background-image: radial-gradient(circle, $c 1%, lighten($c, 15%) 15%, rgba(0,0,0,0) 30%);
  background-color: $c;
}

.btn-raised {
  border-radius: $border-radius-small*0.66;
  box-shadow: $box-shadow-raised;
  @include btn-gradient($secondary-color);
  will-change: box-shadow, background-color;
  color: $secondary-text-color;
  &:hover {
    color: $secondary-text-color;
    box-shadow: $box-shadow-raised-hover;
    background-color: lighten($secondary-color, 5%);
  }
}

Will change currently highlights red, when it is valid:

I believe this should not be highlighted?
(I previously wrongly reported this at atom/atom#8633)

Using brackets inside selector breaks theme?

I've noticed that using brackets inside a class/id will break the theming of code after.

I am on Atom 1.0.11 as of this posting. I switched back to the One Dark UI and theme, but that did not fix the issue. Removing all plugins did not fix it either.

I am at a loss as to what to do next. Any idea why this is happening?

Thanks.

@page directive causes false syntax error highlight

Copy-pastable example:

@include mq(print) {
    font-size: $base-font-size--print;
    @page { 
      size: US-Letter;
    }
  }

and screen shot:

support for toggle-line-comments

When toggling line comments (cmd-/) Atom first places /**/ around an entire definition. Un-commenting the same line by hitting cmd-/ again removes the /**/ but inserts \\ before the line. Example:

body {
    background: $footer-bg;

    &:before {
        position: fixed;
        top: 0;
        right: 0;
|       z-index: -1;
    }
}

Hitting cmd-/ with the caret at the pipe location results in this instead of simply putting // before z-index... :

body {
    background: $footer-bg;

    /* &:before {
        position: fixed;
        top: 0;
        right: 0;
        z-index: -1;
    } */
}

This does un-comments properly.
However...

|   background: $footer-bg;

Results in

    /* background: \$footer-bg; */

Which is kinda fine, although I would expect //' and the`` before $footer...` shouldn't be there.
Un-commenting this results in:

    background: \\$footer-bg;

I'm not sure what the culprit is, but regular CSS does work fine in this regard.

Symbol lookup fails to work at all (⌘+R)

No matter how hard I try, symbol lookup simply fails for my .sass files. I'm using the latest Atom version 0.106.0 at time of writing, I have the grammar enabled, the Symbols View package has Use Editor Grammar As Ctags Language set properly, but ⌘+R fails to match anything relevant.

Symbol lookup in Sublime Text 3 on the same file works fine.

Atom (fails):

Sublime Text 3 (works):

Background snippet

Maybe it is better to make it shorthanded?

background-color: #${1:DDD};$0 -> background: #${1:DDD};$0

Incorrectly assuming property list termination when using ::-webkit-selection

Hi!

    @mixin selection {
        @extend %Font;

        ::selection { @content; }
        ::-webkit-selection { @content; }
    }

The parser seems to be assuming the first colon on the line with -webkit-selection is separating a key-value pair, which is wrong. This also leads it to assume that what comes after is just a selector (for some reason), and that the ending curly on the same line is terminating the property list. The last line is treated as text.