mirror of
https://github.com/danog/sass-site.git
synced 2024-12-16 19:37:21 +01:00
193a124050
Logdown seems to be basically unmaintained, its servers are unreliable, and it's been causing some mixed-content errors lately. This moves all blog posts to sass-lang.com itself; I'll set up redirects from the blog as best I can once this lands. Closes #401 Closes #402 Closes #403
103 lines
5.4 KiB
Markdown
103 lines
5.4 KiB
Markdown
---
|
|
title: "Request For Comments: Importing CSS Files"
|
|
author: Natalie Weizenbaum
|
|
date: 2018-07-09 11:19 PST
|
|
---
|
|
|
|
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.
|
|
|
|
## Background
|
|
|
|
Historically, the reference implementations of Sass—first Ruby Sass, then Dart
|
|
Sass—only supported importing other Sass files. However, LibSass supported
|
|
importing CSS files as well, interpreting them as though they were SCSS.
|
|
Although this technically violated the [implementation guide][]'s prohibition on
|
|
unilaterally extending the language, these CSS imports were useful and were
|
|
widely adopted in the Node.js community.
|
|
|
|
[implementation guide]: /implementation
|
|
|
|
This became particularly clear when, at the language team's urging, LibSass
|
|
added [deprecation warnings][libsass#2611] for CSS imports and users were left
|
|
without a suitable replacement. The language team came together to discuss the
|
|
problem, and decided to move towards allowing CSS imports but forbidding the use
|
|
of non-CSS features in the imported files. The proposal describes the specifics
|
|
of that idea.
|
|
|
|
[libsass#2611]: https://github.com/sass/libsass/issues/2611
|
|
|
|
LibSass's behavior at time of writing is to import files with the extension
|
|
`.css` at the same precedence level as those with the `.scss` and `.sass`
|
|
extensions, and to throw an error if an import is ambiguous between a `.css`
|
|
file and a `.scss` or `.sass` file.
|
|
|
|
## Summary
|
|
|
|
The proposal seeks to strike a balance between preserving compatibility with
|
|
LibSass's existing behavior and moving towards a more principled scheme for
|
|
loading CSS. This is particularly important as we intend to allow `@use` to load
|
|
CSS files without Sass features, so we want the existing CSS loading support to
|
|
be as similar as possible.
|
|
|
|
Locating CSS files for import works similarly under the proposal as it does in
|
|
LibSass currently: a relative `.css` file takes precedence over files with any
|
|
extension on the load path, a `.css` file earlier on the load path takes
|
|
precedence over a file with any extension later on the load path, and `foo.css`
|
|
takes precedence over `index/foo.scss`.
|
|
|
|
The only difference in loading scheme occurs when an import is ambiguous between
|
|
a `.css` file and a `.scss` or `.sass` file at the same path. LibSass currently
|
|
produces an error here, but in order to maximize compatibility with existing
|
|
Dart Sass (and Ruby Sass) behavior, the proposal has the `.scss` or `.sass` file
|
|
taking precedence. This is not a breaking change to LibSass's behavior, since it
|
|
only applies in situations that would previously have produced an error.
|
|
|
|
The proposal diverges significantly from LibSass in parsing the imported CSS
|
|
files, though: it forbids all use of SCSS features in the parsed files. Most
|
|
SCSS features produce errors (rather than compiling to plain, likely-invalid
|
|
CSS) in order to help users who accidentally wrote SCSS in their CSS realize
|
|
what's going wrong. However, features like `@import` that overlap with plain CSS
|
|
continue to be rendered as CSS.
|
|
|
|
In order to avoid a sudden backwards-incompatible change in LibSass, this also
|
|
includes a proposal for a set of deprecation warnings that can be added to
|
|
LibSass's existing behavior to steer users away from using Sass features in
|
|
their imported CSS without entirely breaking their build process.
|
|
|
|
## Giving Feedback
|
|
|
|
If you want more details on exactly how the proposed behavior will work, [head
|
|
over to the `sass/language` repo and read the full
|
|
proposal](https://github.com/sass/language/blob/master/accepted/css-imports.md).
|
|
You can skip the Background and Summary sections, since they're included above.
|
|
Be aware, though, that it's written to be a specification; it's a great for
|
|
figuring out how exactly an edge case should work, but it's not as
|
|
conversational as the sections quoted above.
|
|
|
|
If you have any issues with the proposal as written, or if it doesn't cover a
|
|
use-case that's important to you, [please bring that up in the `sass/language`
|
|
issue
|
|
tracker](https://github.com/sass/language/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3A%22proposal%3A+CSS+imports%22).
|
|
We'll be leaving it open for discussion for at least two weeks before we mark
|
|
the proposal as "accepted" and move on to the implementation phase.
|
|
|
|
Please be aware, though, that while we welcome community feedback, the design of
|
|
Sass is ultimately in the hands of the language team. We'll absolutely consider
|
|
the perspectives and use-cases of users who speak up, but it's also our job to
|
|
consider all the users who are new to Sass or even to CSS and who don't yet know
|
|
to read blogs or comment on issue trackers. Remember that our careful
|
|
decision-making made Sass what it is today, and have patience with us if we
|
|
don't make the decisions you would have!
|