Sass Blog

Page 5 of 8

Previous page

• Request For Comments: Module System

  Posted 27 November 2018 by Natalie Weizenbaum

  Many of the most frequently-requested features for Sass have to do with its imports. The import system that we’ve had since the very early releases of Sass is, to put it simply, not great. It does little more than textually include one Sass file in another, which makes it hard to keep track of where mixins, functions, and variables were defined and hard to be sure that any new additions won’t happen to conflict with something elsewhere in the project. To make matters worse, it overlaps with CSS’s built-in @import rule, which forces us to have a bunch of heuristics to decide which is which.

  Because of these problems and others, we’ve wanted to do a full overhaul of the way Sass files relate to one another for a long time. Over the last few years, I’ve been working with the Sass core team and Sass framework maintainers to create a proposal for a module system that’s fit to replace @import. That proposal is now in a place that…

• Feature Watch: Content Arguments and Color Functions

  Posted 14 November 2018 by Natalie Weizenbaum

  Dart Sass 1.15, released today and available on npm and all other distribution channels, brings with it a number of highly-anticipated new Sass features. This is also the first release of Dart Sass with major new language features that aren’t just for CSS compatibility. That’s a big accomplishment, and we intend to continue that pattern moving forward!

  @content Arguments@content Arguments permalink

  Mixins that take @content blocks can now pass arguments to those blocks. This is written @content(<arguments...>). If a mixin passes arguments to its content block, users of that mixin must accept those arguments by writing @include <name> using (<arguments...>). The argument list for a content block works just like a mixin’s argument list, and the arguments passed to it by @content work just like passing arguments to a mixin.

  // style.scss
  @mixin media($types...) {
    @each $type in $types {
      @media #{$type} {
        @content($type);
      }
    }
  }
  
  @include media(screen, print) using ($type)...

• Feature Watch: CSS Imports and CSS Compatibility

  Posted 13 August 2018 by Natalie Weizenbaum

  Dart Sass 1.11 has just been released, and with it a handful of new features. This is an exciting moment, because it marks the first major new feature that’s been added to the language since Dart Sass was launched. It’s also the first release with features that have gone through the new process, from proposal to tests to implementation.

  CSS ImportsCSS Imports permalink

  The biggest feature in Dart Sass 1.11 is support for importing plain CSS files. This is a long-awaited feature, and while we’d initially planned on waiting on it until we launched the upcoming module system, we ended up deciding to implement it earlier.

  You can now import a CSS file, say styles.css, just by writing @import "styles". That file will be parsed as plain CSS, which means that any Sass features like variables or mixins or interpolation will be disallowed. The CSS it defines will become part of your stylesheet, and can be @extended just like any other styles.

  There are…

• Request For Comments: Importing CSS Files

  Posted 9 July 2018 by Natalie Weizenbaum

  As Dart Sass catches up with Ruby Sass in terms of usability, we’re starting work on adding new features to the language. The first feature we’re looking at is one that’s long been requested by users: adding support for importing plain CSS files without having to rename them to .scss. Not only do we expect this to be very useful, it’s already partially implemented in LibSass, so this will help bring the implementations more in line with one another.

  We’re also trying out a new process with this feature. In order to help keep the behavior of different implementations in sync, we’re starting with a prose specification of the feature before moving on to writing code. We’re also taking this as an opportunity to solicit feedback from you, the Sass community! We want to hear your thoughts on the new feature while we have a chance to revise it based on that feedback.

  BackgroundBackground permalink

  Historically, the reference implementations of Sass—first Ruby Sass, then Dart Sass—only supported importing…

• Ruby Sass is Deprecated

  Posted 2 April 2018 by Natalie Weizenbaum

  With the release of Dart Sass 1.0.0 stable last week, Ruby Sass was officially deprecated. I’ll continue to maintain it over the next year, but when 26 March 2019 rolls around it will reach its official end-of-life. I encourage all users to start migrating away sooner rather than later.

  The Deprecation PeriodThe Deprecation Period permalink

  Over the next year, I’ll continue to work on Ruby Sass in a limited capacity. I’ll triage and fix any bugs that are reported, unless they’re minor or obscure enough to be unlikely to pose a practical problem over the next year. I’ll also add support for any new CSS features that require changes to the Sass parser or other parts of the language.

  I won’t be working on language features that aren’t necessary for CSS support, though. The latest and greatest features will be appearing exclusively in Dart Sass and LibSass from here on out.

  I also won’t be accepting pull requests for new Ruby Sass features. While pull requests are a great…

Next page