(edited by @nex3)

• [x] Proposal
• [x] Specs
• [x] Documentation
• [x] Dart Sass
• [ ] LibSass

I've recently wanted to start including .css files and have them parsed as Sass. The idea behind this is that a component might be added to the project as a third-party component and I'll want to import their CSS for use in Sass.

This would allow us to have project in Bower (and other package managers) for reusable CSS components that would work with or without Sass. Take the Normalize.css file for example, I would like to be able to add this to a project using Bower and import it into the project as I would an SCSS file rather than creating a vanilla CSS import.

I imagine this would mean letting this syntax:

@import "normalize"

look for normalize.sass, normalise.scss or normalize.css and pull it in. Currently it will ignore it if it only finds a css file.

Would there be any downsides to this?

/cc @chriseppstein

• [x] Proposal
• [x] Specs
• [x] Documentation
• [x] Dart Sass
• [x] LibSass

Mixin content is great and has done wonders for code implementing wrapper and context abstractions. However, there is often some setup done in the mixin and that setup needs to be available to the content when it is included. The current strategy is to use global variables, which works, but is obviously not ideal.

I'd like to introduce a way for mixins to include their content block and to pass arguments to the content.

Calling the content with arguments

In order to pass arguments to content blocks an argument list can be passed to the content directive. This accepts positional and keyword arguments for passing to a content block. Variable argument semantics are allowed.

@mixin accepts-content {
  @for $i from 1 to 5 {
    @content ($i, 360deg * $i / 5);
  }
}

Receiving arguments within a content block

A content block receives arguments using a new directive called @receive. The directive allows an argument list declaration that is the same as for functions and mixins. Positional arguments, default values, and variable arguments are all allowed.

@include accepts-content {
  @receive ($number, $hue);
  .color-#{$number} {
    background-color: hsl($hue, 75%, 90%);
  }
}

It would be great if SASS output could be configured to more intelligently compress output. Here are some examples:

# Combine name-spaced selectors
# SASS                             # Preferred Output                 # Current Output
body {                             body{border:3px solid #ccc;}       body{border-width:3px;border-color:#ccc;border-style:solid;}
  border: {
    width: 3px;
    color: #ccc;
    style: solid
    }
}

# Combine multiple declarations
# SASS                             # Preferred Output                 # Current Output
body { border: solid #ccc; }       body{border:3px solid #ccc;}       body{border:solid #ccc;}
body { border-width: 3px; }                                           body{border-width:3px;}

# SASS                             # Preferred Output                 # Current Output
body { color: #ccc; }              body{color:#ccc;cursor:pointer;}   body{color:#ccc;}
body { cursor: pointer; }                                             body{cursor:pointer;}          

# Ignore overridden declarations
# SASS                             # Preferred Output                 # Current Output
body { border: 2px solid #400; }   body{border:3px solid #ccc;}       body{border:2px solid #400;}
body { border: 3px solid #ccc; }                                      body{border:3px solid #ccc;}

This would allow you to more expressively organise stylesheets and partials without sacrificing on output length. For example, you could have color, typography and layout partials which, when compiled, gave the same output as if they had been written all mixed together.

There maybe gotchas with doing this due to the cascading nature of stylesheets and this effectively changes the ordering of declarations. However, I can't immediately think of specifics and the first case at least does not seem to be problematic.

This should also only apply when the compressed output option has been set as the readability of stylesheets may be impacted. For example, in development, it might be useful for the output to indicate that the designer has intended to split declarations in a particular way.

I'm working with Sass 3.4.

My sass source code is:

#test
  content:  "\f000"

when parsed it got converted to:

#test {
  content: "";
}

I'm using expanded style and sass syntax. I've noticed that switching to scss works correctly, anyway my entire codebase is in sass format :(

Is there any way to preserve original content unicode string?

Thanks in advance

Currently, when a compound selector is extended, Sass will only replace instances of the full extendee with the extender. For example:

.a {x: y}
.b {x: y}
.a.b {x: y}

.c {@extend .a.b}

produces

.a {x: y}
.b {x: y}
.a.b, .c {x: y}

when it should produce

.a, .c {x: y}
.b, .c {x: y}
.a.b, .c {x: y}

according to the semantics of @extend. We should fix this, especially as CSS moves closer to supporting @extend natively.

Tasks:

• [x] Deprecate existing behavior in stable.
• [x] Remove behavior from master.

Currently when using @import, you need to hardcode in uri. I'd like the ability to pass in a variable/function call to get the uri and use that for the @import call, something like the following:

@function drupal-theme($project, $append: '') {
  @return /sites/all/themes/#{$project}/#{$append};
}
…
@import #{drupal-theme('my-theme', 'sass/style)};

Which would be the same as:

@import '/sites/all/themes/my-theme/sass/style';

This would also make it easier for a master import for sub-partials a la Compass framework stuff:

$compass-css3: 'border-radius' 'inline-block' 'opacity' 'box-shadow' 'text-shadow'…;
@each $css3 in $compass-css3 {
  @import 'css3/#{$css3};
}

I'd love Sass style mixins in SCSS, specifically being able to do + in addition to @include. I know a few others mentioned this recently, but I didn't see an official issue for it, so I'm adding one.

If not, I guess I'm going to need to start learning Sass syntax.

• [x] Proposal
• [x] Specs
• [x] Documentation
• [x] Dart Sass
• [ ] LibSass

See also the module system project.

This is a compilation of issues and wishes about @import

Import CSS files #556

@import "normalize";

Would import sass, scss or css file

There's a plugin for that

Import Once #139

@import-once "foo";
@import "foo" !once;
@depend "foo";

Multiple syntax suggestions for one time import

There is a plugin for that

Import Directory #690

@import "foo";

If "foo" is a folder than it tries to import "foo/_module.scss"

reasonable

Namespaces and Aliases #353

@import "foo" as "bar";

This would put every "foo" components (mixins, vars, placeholders...) in a "bar" package.

What would be the separator ? . or / or \ or :: ? Where would go the $ and % ? Before or after the namespace ? What it would look like :

// Mixins
@include bar.baz();
or
@include bar/baz();

// Variables
color: $bar.baz;
or
color: bar.$baz;
or
color: $bar/baz;
or
color: bar/$baz;

// Placeholders
div { @extend %bar.baz; }
or
div { @extend bar.%baz; }
or
div { @extend %bar/baz; }
or
div { @extend bar/%baz; }

// Functions
color: bar.baz();
or
color: bar/baz();

Non-transitive imports #353

if A imports B and B imports C, A shouldn't necessarily see everything from C. A way of getting around non-transitive imports.

Renaming classes #353

This isn't something I'm 100% sold on, but it has been requested. Maybe the correct way to do this is some combination of namespacing and @extend.

Disabling CSS output #353

Both selectively and wholesale. The importer may want to @extend the rules in the importee but not have them concretely present, or it may want to suppress rules matching a certain selector.

This is also related to #320 :

// A.scss
.foo {...}
.bar {...}

// B.scss
@use "A";
.baz { @extend .foo; }

B output would not contain .foo & .bar definition but only .baz;

Conditional imports #451

@if true {
    @import "foo";
}

It "worked" before but never intended.

Paths

A way to setup shortcut paths (like Require.js)

// No syntax intended, only the purpose
@paths (
    "bootstrap": "../components/bootstrap-sass/vendor/assets/stylesheets/bootstrap"
);

@import "bootstrap";

Unless the output format is compressed, we should preserve the format that the author used when creating a color.

Formats being:

• color name
• hex
• rgb/rgba
• hsl/hsla

The format should be sticky to derived values in as much as possible.

When using hsl()/hsla(), it will be converted into hex or rgba. But i want to keep my original hsl/hsla expression. This has different matters:

• hsl accepts floating point numbers like hsl(85.3, 20.3, 75.8). The precision will be lost, when converting to hex.
• when converting from hsla to rgba, precision will be lost, too.
• My applications "reads" the style sheet rules, and want to extract the hsl/hsla expressions, but there are no more.
• My application uses the extracted hsl/hsla expressions for another color manipulations (at runtime, not a compile time!). Precision is very important. I work a lot of with colors.

So, can you offer a command line option, that will keep all plain hsl/hsla expressions? This would be amazing.

PS: I do not support IE8 or below, so don't worry. But even IE9 accepts floating point hsl/hsla-values, all html5 browsers can do this, and my applications requieres html5 only browsers.

Greetings, Sebastian

$ck: #66cc00; $es: #3366cc; $fr: #ff6c00; $bd: #cc0000; $wt: #FFDB00;

@each $brand in ck, es, fr, bd, wt{ .#{$brand}_bg { background-color: $#{$brand}; // <-- I want to call $ck, $es, $fr, $bd, $wt } }

Bumps tj-actions/changed-files from 34.5.3 to 35.2.0.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

In the documentation for @use, it states that

You can access variables, functions, and mixins from another module by writing <namespace>.<variable>, <namespace>.<function>(), or @include <namespace>.<mixin>(). By default, the namespace is just the last component of the module’s URL.

https://sass-lang.com/documentation/at-rules/use#loading-members

However, I could not get @include <namespace>.<mixin>(arguments) or @include <namespace>.<mixin> to work when I used the @use to import my mixin. I originally had this issue in Hugo, but I reproduced it in React with node-sass

post.scss

$var: yellow;
@mixin mix1($arg1, $arg2) {
  background-color: red;
}

@mixin mix2 {
  background-color: blue;
}

App.scss

@use "src/post" as c;

.App {
  @include c.mix2(1px, 2px);
  @include c.mix1;
  background-color: c.$var;
}

Error

Steps to reproduce I'm not familiar how to minimally produce with only node-sass, so React was the quickest option for me

1. Use node-sass version

node-sass       8.0.0   (Wrapper)       [JavaScript]
libsass         3.5.5   (Sass Compiler) [C/C++]

2. Create a new react app with npx create-react-app my-app
3. Replace all .css files with scss and use code blocks above

Steps taken to address

• Tried using with and without different namespace with @use "src/post" as c
• Tried making post.scss private _post.scss like the example in the documentation link

The Color Spaces proposal currently deprecates all channel accesor functions except alpha()/color.alpha(). Was this an oversight or did we have some justification for it?

The Color Spaces proposal currently requires channel names to be unquoted strings for functions like color.channel() and color.is-powerless(). While this matches the requirement that color spaces be unquoted, it raises a serious problem: the channel names red, green, and blue for the various predefined color spaces will be parsed by Sass as color values rather than unquoted strings, making color.channel($color, red) throw an error. While this could be worked around with color.channel($color, unquote("red")), that's obviously infeasible in practice.

I see three basic approaches we could take here:

1. Require quoted strings instead. This avoids any ambiguity issues, but it's inconsistent with color space names which require unquoted strings and aren't ambiguous with predefined colors. We could also take this a step further and change color spaces to require quoted strings as well for consistency, but then that's inconsistent with how they're written in plain CSS (particularly the color() function and the <color-interpolation-method> production, the latter of which we want to accept as-is for the mix function).

2. Switch to CSS's channel terminology. Colors 5 defines relative color syntax which makes explicit reference to channel names, but (other than alpha) they're different than the names we use. In particular, they're all single letters: r, g, b; l, c, h; and so on. While this is less obvious to a reader, there's real value in being consistent with CSS in addition to avoiding ambiguity with color names. If we did go this route, though, we'd need to consider whether to deprecate the existing long-form argument names for color.adjust(), .scale(), and .change().

3. Hack around the issue entirely by defining #f00, #0f0, and #00f as value aliases of the channel names red, green, and blue. This is extremely messy so I'm inclined to dislike it, but it may be the path of least resistance.

The current color spaces proposal PR doesn't explicitly specify how to handle most of the deprecated color functions. It's reasonable to assume they work more or less the same way they always did, but as I get into the weeds of the implementation I'm realizing that because the internal representation of colors has changed so much these functions should probably also get explicitly defined.

Some particular questions I've run into:

• Should functions like adjust-hue() return a color in the original space or in HSL? (Probably original to match our general design principle that only color.to-space() changes the color space.)

• Should hue() return the hue % 360deg? We currently store the hue as written, but taking the mod here would preserve some edge-case backwards compatibility.

• Should channel-access functions like red(), hue(), and so on even allow legacy colors? My current implementation forbids them.

Strange thing happening here. As the title says, I am getting "Could not find an option named "scss".

"scripts": {
    "start": "concurrently \"npm run serve\" \"npm run build:watch\" \"npm run compile:sass\"",
    "compile:sass": "sass ./src/styles:./src/styles -w",
},