- Aug 2023
- Jun 2021
-
sass-lang.com sass-lang.com
-
Today, Sass uses complex heuristics to figure out whether a / should be treated as division or a separator. Even then, as a separator it just produces an unquoted string that’s difficult to inspect from within Sass.
-
- Mar 2021
-
github.com github.com
-
I am finally getting usable source maps for SCSS, wow!
Tags
Annotators
URL
-
- Feb 2021
-
sass-lang.com sass-lang.com
-
Sass variables, like all Sass identifiers, treat hyphens and underscores as identical. This means that $font-size and $font_size both refer to the same variable. This is a historical holdover from the very early days of Sass, when it only allowed underscores in identifier names. Once Sass added support for hyphens to match CSS’s syntax, the two were made equivalent to make migration easier.
-
-
github.com github.com
Tags
Annotators
URL
-
-
www.youtube.com www.youtube.com
-
Sass
Define variables, such as colors (e.g. $primary: #337ab7) in Sass (styles.scss) then compile to css for web.
R library "bootstraplib" built on foundation of "sass".
Use "run_with_themer()" to get a live preview GUI for customizing bootstrap theme.
Also, use "shinyOptions(plot.autocolors=TRUE)" at top of app to get plot outputs that respect Dark Mode.
Tags
Annotators
URL
-
- Jan 2021
- Dec 2020
-
-
node-sass may be faster than dart-sass, but as of writing this dart-sass is the only library which implements the @use rule, which is strongly recommended over @import. According to the official sass-lang website:
-
- Nov 2020
-
github.com github.com
-
@import url() is a runtime CSS statement, not a Sass @import module.
-
-
github.com github.com
-
github.com github.com
-
To bundle this in your own code, use a Sass processor (not a Sass Svelte preprocessor, but a Sass processor)
-
-
github.com github.com
-
After a few hours experimenting (updated NPM, NODE, ...) I found that renaming _smui-theme.scss to smui-theme.scss (without underscore prefix) solved the problem. I don't understand the mechanics behind (why in documentation is file with prefix).
-
-
github.com github.com
-
Dart Sass has replaced Ruby Sass as the canonical implementation of the Sass language.
-
Sass makes CSS fun again.
-
-
-
-
Dart Sass is the primary implementation of Sass, which means it gets new features before any other implementation. It’s fast, easy to install, and it compiles to pure JavaScript which makes it easy to integrate into modern web development workflows.
-
-
-
sass-lang.com sass-lang.com
-
The rule is written @forward "<url>". It loads the module at the given URL just like @use, but it makes the public members of the loaded module available to users of your module as though they were defined directly in your module. Those members aren’t available in your module, though—if you want that, you’ll need to write a @use rule as well.
Just like how you have to also import (@use) a JS module if you want to use it locally, even if you export (@forward) it.
-
-
-
css-tricks.com css-tricks.com
-
-
Using as * adds a module to the root namespace, so no prefix is required, but those members are still locally scoped to the current document.
distinction:
- root namespace (so no prefix is required), but
- locally scoped (to the current document)
-
Internal Sass features have also moved into the module system, so we have complete control over the global namespace.
-
The file is only imported once, no matter how many times you @use it in a project.
Is this @use sort of like import is in JavaScript (vs require?? does that import file again?)? Or maybe it's more like
require
vs.load
in Ruby? -
The new @use is similar to @import. but has some notable differences:
-
In brief, @import is being replaced with more explicit @use and @forward rules. Over the next few years Sass @import will be deprecated, and then removed.
-
When you use a function like color(). it’s impossible to know exactly where it was defined. Which @import does it come from?
Tags
- where was it defined? where does it come from?
- Sass: @forward
- namespace as prefix
- fine-grained control
- being explicit
- Sass
- Sass: modules
- Sass: @use
- important distinction
- built-in
- differences
- under my control
- global scope
- having enough control over something
- Sass: @import
- internal
- scoping
- polluting the global scope/environment
- namespaces
- replacement for:
- distinction
- deprecated
Annotators
URL
-
-
stackoverflow.com stackoverflow.com
-
What a very strange design decision - to treat the files as the same.
-
-
sass-lang.com sass-lang.com
-
We’ve written a migration tool that automatically converts most @import-based code to @use-based code in a flash.
-
The @import rule has a number of serious issues:
-
- Nov 2019
-
create-react-app.dev create-react-app.dev
-
To share variables between Sass files, you can use Sass imports. For example, src/App.scss and other component style files could include @import "./shared.scss"; with variable definitions
just like we do in other project, say an Angular app. So the React components will use composition but in the sass files, we can use import() and @extends
Tags
Annotators
URL
-
- May 2018
-
css-tricks.com css-tricks.com
-
percentage(5/7);
Sass feature/function
-
- Feb 2017
- Feb 2016
-
csswizardry.com csswizardry.com
-
This is a perfect use-case for @extend. These rulesets are inherently related; their shared traits are shared for a reason, not coincidentally. Further, we aren’t transplanting their selectors hundreds of lines away from their source, so our Specificity Graph stays nice and sane
So a sensible policy might be to use @extend only for related classes in the same source file, where source order is obvious.
-
Some useful notes on the pros and cons of @extend vs mixins in SCSS.
In a nutshell, he suggests avoiding @extend entirely.
My main bugbear is that it prevents local reasoning about the final set of rules that will apply for an element with a given class.
-
-
bensmithett.com bensmithett.com
-
n the Webpack approach, each Sass file is compiled in isolation. This isn't a new idea, but I think it's a much better way of doing Sass. It just means you need to @import dependencies like variables & mixins wherever you use them
Which is a much better thing to be doing anyway in terms of having clear and explicit dependencies.
Tags
Annotators
URL
-