35 Matching Annotations
  1. Aug 2023
  2. Jun 2021
    1. 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.
  3. Mar 2021
  4. Feb 2021
    1. 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.
    1. 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.

  5. Jan 2021
  6. Dec 2020
    1. 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:
  7. Nov 2020
    1. 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).
    1. 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.

    1. 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.


      • root namespace (so no prefix is required), but
      • locally scoped (to the current document)
    2. Internal Sass features have also moved into the module system, so we have complete control over the global namespace.
    3. 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?

    4. The new @use is similar to @import. but has some notable differences:
    5. 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.
    6. When you use a function like color(). it’s impossible to know exactly where it was defined. Which @import does it come from?
  8. Nov 2019
    1. 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

  9. May 2018
  10. Feb 2017
  11. Feb 2016
    1. 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.

    2. 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.

    1. 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.