mirror of
https://github.com/danog/sass-site.git
synced 2025-01-22 05:41:42 +01:00
Switching links to absolute paths, updating headsUp tags and compat tags
This commit is contained in:
Sana Javed
parent
07dcbbe201
commit
fd2899c732
@ -1,7 +1,7 @@
|
||||
---
|
||||
title: "@forward"
|
||||
introduction: >
|
||||
The `@forward` rule loads a Sass stylesheet and makes its [mixins](../mixin), [functions](../function), and [variables](../../variables) available when your stylesheet is loaded with the [`@use` rule](../use). It makes it possible to organize Sass libraries across many files, while allowing their users to load a single entrypoint file.
|
||||
The `@forward` rule loads a Sass stylesheet and makes its [mixins](/documentation/at-rules/mixin), [functions](/documentation/at-rules/function), and [variables](/documentation/variables) available when your stylesheet is loaded with the [`@use` rule](/documentation/at-rules/use). It makes it possible to organize Sass libraries across many files, while allowing their users to load a single entrypoint file.
|
||||
---
|
||||
{% markdown %}
|
||||
The rule is written `@forward "<url>"`. It loads the module at the given URL
|
||||
@ -11,19 +11,19 @@ module. Those members aren't available in your module, though—if you want that
|
||||
you'll need to write a `@use` rule as well. Don't worry, it'll only load the
|
||||
module once!
|
||||
|
||||
[public]: ../use#private-members
|
||||
[public]: /documentation/at-rules/use#private-members
|
||||
|
||||
If you *do* write both a `@forward` and a `@use` for the same module in the same
|
||||
file, it's always a good idea to write the `@forward` first. That way, if your
|
||||
users want to [configure the forwarded module][], that configuration will be
|
||||
applied to the `@forward` before your `@use` loads it without any configuration.
|
||||
|
||||
[configure the forwarded module]: ../use#configuration
|
||||
[configure the forwarded module]: /documentation/at-rules/use#configuration
|
||||
|
||||
{% funFact %}
|
||||
The `@forward` rule acts just like `@use` when it comes to a module's CSS. Styles from a forwarded module will be included in the compiled CSS output, and the module with the `@forward` can [extend][] it, even if it isn't also `@use`d.
|
||||
|
||||
[extend]: ../extend
|
||||
[extend]: /documentation/at-rules/extend
|
||||
{% endfunFact %}
|
||||
{% endmarkdown %}
|
||||
|
||||
@ -74,7 +74,7 @@ Because module members are usually used with [a namespace][], short and simple n
|
||||
|
||||
This is written `@forward "<url>" as <prefix>-*`, and it adds the given prefix to the beginning of every mixin, function, and variable name forwarded by the module. For example, if the module defines a member named `reset` and it's forwarded `as list-*`, downstream stylesheets will refer to it as `list-reset`.
|
||||
|
||||
[a namespace]: ../use#loading-members
|
||||
[a namespace]: /documentation/at-rules/use#loading-members
|
||||
{% endmarkdown %}
|
||||
|
||||
{% codeExample 'prefix' %}
|
||||
@ -175,12 +175,12 @@ $horizontal-list-gap: 2em
|
||||
{% markdown %}
|
||||
## Configuring Modules
|
||||
|
||||
{% # Arguments are (in order): `dart`, `libsass`, `ruby`, optional feature name, additional details within %}
|
||||
{% compatibility '1.24.0', false, false %}{% endcompatibility %}
|
||||
{% # Arguments are (in order): `dart`, `libsass`, `node`, `ruby`, optional feature name, additional details within %}
|
||||
{% compatibility '1.24.0', false, null, false %}{% endcompatibility %}
|
||||
|
||||
The `@forward` rule can also load a module with [configuration][]. This mostly works the same as it does for `@use`, with one addition: a `@forward` rule's configuration can use the `!default` flag in its configuration. This allows a module to change the defaults of an upstream stylesheet while still allowing downstream stylesheets to override them.
|
||||
|
||||
[configuration]: ../use#configuration
|
||||
[configuration]: /documentation/at-rules/use#configuration
|
||||
{% endmarkdown %}
|
||||
|
||||
{% codeExample 'configuration' %}
|
||||
|
||||
@ -67,7 +67,6 @@ We've written a [migration tool][] that automatically converts most
|
||||
|
||||
[migration tool]: /documentation/cli/migrator
|
||||
{% endheadsUp %}
|
||||
|
||||
{% endmarkdown %}
|
||||
|
||||
{% codeExample 'import' %}
|
||||
@ -159,11 +158,13 @@ Unlike some other languages, Sass doesn't require that you use `./` for relative
|
||||
As a convention, Sass files that are only meant to be imported, not compiled on their own, begin with `_` (as in `_code.scss`). These are called *partials*, and they tell Sass tools not to try to compile those files on their own. You can leave off the `_` when importing a partial.
|
||||
|
||||
### Index Files
|
||||
{% endmarkdown %}
|
||||
|
||||
{% # Arguments are (in order): `dart`, `libsass`, `ruby`, optional feature name, additional details within %}
|
||||
{% compatibility true, '3.6.0', '3.6.0' %}{% endcompatibility %}
|
||||
{% # Arguments are (in order): `dart`, `libsass`, `node`, `ruby`, optional feature name, additional details within %}
|
||||
{% compatibility true, '3.6.0', null, '3.6.0' %}{% endcompatibility %}
|
||||
|
||||
{% markdown %}
|
||||
If you write an `_index.scss` or `_index.sass` in a folder, when the folderitself is imported that file will be loaded in its place.
|
||||
|
||||
{% endmarkdown %}
|
||||
|
||||
{% codeExample 'index-files' %}
|
||||
@ -289,7 +290,7 @@ Nested imports are very useful for scoping third-party stylesheets, but if you'r
|
||||
[mixin]: /documentation/at-rules/mixin
|
||||
{% endfunFact %}
|
||||
|
||||
{% headsUp %}
|
||||
{% headsUp, false %}
|
||||
{% markdown %}
|
||||
The CSS in nested imports is evaluated like a mixin, which means that any [parent selectors][] will refer to the selector in which the stylesheet is nested.
|
||||
|
||||
@ -340,8 +341,7 @@ ul li
|
||||
{% markdown %}
|
||||
## Importing CSS
|
||||
|
||||
{% # Arguments are (in order): `dart`, `libsass`, `ruby`, optional feature name, additional details within %}
|
||||
{% compatibility '1.11.0', 'partial', false %}
|
||||
{% compatibility '1.11.0', 'partial', null, false %}
|
||||
LibSass supports importing files with the extension `.css`, but contrary to
|
||||
the specification they're treated as SCSS files rather than being parsed as
|
||||
CSS. This behavior has been deprecated, and an update is in the works to
|
||||
@ -390,8 +390,7 @@ rendered as-is. It can even be [extended][]!
|
||||
|
||||
## Plain CSS `@import`s
|
||||
|
||||
{% # Arguments are (in order): `dart`, `libsass`, `ruby`, optional feature name, additional details within %}
|
||||
{% compatibility true, 'partial', true %}
|
||||
{% compatibility true, 'partial', null, true %}
|
||||
By default, LibSass handles plain CSS imports correctly. However, any [custom importers][] will incorrectly apply to plain-CSS `@import` rules, making it possible for those rules to load Sass files.
|
||||
|
||||
[custom importers]: /documentation/js-api/interfaces/LegacySharedOptions#importer
|
||||
@ -508,7 +507,7 @@ To make this easier, Sass also supports *import-only files*. If you name a file
|
||||
{% markdown %}
|
||||
#### Configuring Modules Through Imports
|
||||
|
||||
{% compatibility '1.24.0', false, false %}{% endcompatibility %}
|
||||
{% compatibility '1.24.0', false, null, false %}{% endcompatibility %}
|
||||
|
||||
You can [configure modules][] that are loaded through an `@import` by defining global variables prior the `@import` that first loads that module.
|
||||
|
||||
|
||||
@ -7,51 +7,51 @@ introduction: >
|
||||
---
|
||||
|
||||
{% markdown %}
|
||||
* [`@use`](./use) loads mixins, functions, and variables from other Sass
|
||||
* [`@use`](/documentation/at-rules/use) loads mixins, functions, and variables from other Sass
|
||||
stylesheets, and combines CSS from multiple stylesheets together.
|
||||
|
||||
* [`@forward`](./forward) loads a Sass stylesheet and makes its mixins,
|
||||
* [`@forward`](/documentation/at-rules/forward) loads a Sass stylesheet and makes its mixins,
|
||||
functions, and variables available when your stylesheet is loaded with the `@use`
|
||||
rule.
|
||||
|
||||
* [`@import`](./import) extends the CSS at-rule to load styles, mixins,
|
||||
* [`@import`](/documentation/at-rules/import) extends the CSS at-rule to load styles, mixins,
|
||||
functions, and variables from other stylesheets.
|
||||
|
||||
* [`@mixin` and `@include`](./mixin) makes it easy to re-use chunks of
|
||||
* [`@mixin` and `@include`](/documentation/at-rules/mixin) makes it easy to re-use chunks of
|
||||
styles.
|
||||
|
||||
* [`@function`](./function) defines custom functions that can be used in
|
||||
* [`@function`](/documentation/at-rules/function) defines custom functions that can be used in
|
||||
[SassScript expressions][].
|
||||
|
||||
* [`@extend`](./extend) allows selectors to inherit styles from one
|
||||
* [`@extend`](/documentation/at-rules/extend) allows selectors to inherit styles from one
|
||||
another.
|
||||
|
||||
* [`@at-root`](./at-root) puts styles within it at the root of the
|
||||
* [`@at-root`](/documentation/at-rules/at-root) puts styles within it at the root of the
|
||||
CSS document.
|
||||
|
||||
* [`@error`](./error) causes compilation to fail with an error message.
|
||||
* [`@error`](/documentation/at-rules/error) causes compilation to fail with an error message.
|
||||
|
||||
* [`@warn`](./warn) prints a warning without stopping compilation
|
||||
* [`@warn`](/documentation/at-rules/warn) prints a warning without stopping compilation
|
||||
entirely.
|
||||
|
||||
* [`@debug`](./debug) prints a message for debugging purposes.
|
||||
* [`@debug`](/documentation/at-rules/debug) prints a message for debugging purposes.
|
||||
|
||||
* Flow control rules like [`@if`][], [`@each`][], [`@for`][], and [`@while`][]
|
||||
control whether or how many times styles are emitted.
|
||||
|
||||
[SassScript expressions]: ../syntax/structure#expressions
|
||||
[`@if`]: ./control/if
|
||||
[`@each`]: ./control/each
|
||||
[`@for`]: ./control/for
|
||||
[`@while`]: ./control/while
|
||||
[SassScript expressions]: /documentation/syntax/structure#expressions
|
||||
[`@if`]: /documentation/at-rules/control/if
|
||||
[`@each`]: /documentation/at-rules/control/each
|
||||
[`@for`]: /documentation/at-rules/control/for
|
||||
[`@while`]: /documentation/at-rules/control/while
|
||||
|
||||
Sass also has some special behavior for [plain CSS at-rules][]: they can contain
|
||||
[interpolation][], and they can be nested in style rules. Some of them, like
|
||||
[`@media`][] and [`@supports`][], also allow SassScript to be used directly in
|
||||
the rule itself without interpolation.
|
||||
|
||||
[plain CSS at-rules]: ./css
|
||||
[interpolation]: ../interpolation
|
||||
[`@media`]: ./css#media
|
||||
[`@supports`]: ./css#supports
|
||||
[plain CSS at-rules]: /documentation/at-rules/css
|
||||
[interpolation]: /documentation/interpolation
|
||||
[`@media`]: /documentation/at-rules/css#media
|
||||
[`@supports`]: /documentation/at-rules/css#supports
|
||||
{% endmarkdown %}
|
||||
|
||||
@ -4,7 +4,7 @@ table_of_contents: true
|
||||
eleventyComputed:
|
||||
before_introduction: "{% render 'documentation/snippets/module-system-status' %}"
|
||||
introduction: >
|
||||
The `@use` rule loads [mixins](../mixin), [functions](../function), and [variables](../../variables) from other Sass stylesheets, and combines CSS from multiple stylesheets together. Stylesheets loaded by `@use` are called "modules". Sass also provides [built-in modules](../../modules) full of useful functions.
|
||||
The `@use` rule loads [mixins](/documentation/at-rules/mixin), [functions](/documentation/at-rules/function), and [variables](/documentation/variables) from other Sass stylesheets, and combines CSS from multiple stylesheets together. Stylesheets loaded by `@use` are called "modules". Sass also provides [built-in modules](/documentation/modules) full of useful functions.
|
||||
complementary_content: |
|
||||
<nav aria-labelledby="page-sections" class="page-sections sl-c-list-navigation-wrapper sl-c-list-navigation-wrapper--collapsible">
|
||||
|
||||
@ -35,14 +35,12 @@ compiled CSS output, no matter how many times those styles are loaded.
|
||||
{% endmarkdown %}
|
||||
|
||||
{% headsUp %}
|
||||
{% markdown %}
|
||||
A stylesheet's `@use` rules must come before any rules other than `@forward`,
|
||||
including [style rules][]. However, you can declare variables before `@use`
|
||||
rules to use when [configuring modules][].
|
||||
|
||||
[style rules]: ../../style-rules
|
||||
[style rules]: /documentation/style-rules
|
||||
[configuring modules]: #configuration
|
||||
{% endmarkdown %}
|
||||
{% endheadsUp %}
|
||||
|
||||
{% codeExample 'use' %}
|
||||
@ -111,7 +109,7 @@ Members (variables, functions, and mixins) loaded with `@use` are only visible i
|
||||
own `@use` rules if they also want to access them. This helps make it easy to figure out exactly where each member is coming from. If you want to load members
|
||||
from many files at once, you can use the [`@forward` rule][] to forward them all from one shared file.
|
||||
|
||||
[`@forward` rule]: ../forward
|
||||
[`@forward` rule]: /documentation/at-rules/forward
|
||||
|
||||
{% funFact %}
|
||||
Because `@use` adds namespaces to member names, it's safe to choose very
|
||||
@ -120,7 +118,7 @@ different from the old [`@import` rule][], which encouraged that users write
|
||||
long names like `$mat-corner-radius` to avoid conflicts with other
|
||||
libraries, and it helps keep your stylesheets clear and easy to read!
|
||||
|
||||
[`@import` rule]: ../import
|
||||
[`@import` rule]: /documentation/at-rules/import
|
||||
{% endfunFact %}
|
||||
{% endmarkdown %}
|
||||
|
||||
@ -262,8 +260,8 @@ single module, just don't [forward its module][] from any of your package's
|
||||
entrypoints (the stylesheets you tell your users to load to use your package).
|
||||
You can even [hide that member][] while forwarding the rest of its module!
|
||||
|
||||
[forward its module]: ../forward
|
||||
[hide that member]: ../forward#controlling-visibility
|
||||
[forward its module]: /documentation/at-rules/forward
|
||||
[hide that member]: /documentation/at-rules/forward#controlling-visibility
|
||||
{% endfunFact %}
|
||||
|
||||
{% codeExample 'private-members', , false%}
|
||||
@ -308,7 +306,7 @@ configurable. To load a module with configuration, write `@use <url> with
|
||||
(<variable>: <value>, <variable>: <value>)`. The configured values will override
|
||||
the variables' default values.
|
||||
|
||||
[`!default` flag]: ../variables#default-values
|
||||
[`!default` flag]: /documentation/variables#default-values
|
||||
{% endmarkdown %}
|
||||
|
||||
{% render 'code-snippets/example-use-with' %}
|
||||
@ -324,8 +322,8 @@ once, pass [maps][] as configuration, or update the configuration after the
|
||||
module is loaded, consider writing a mixin to set your variables instead and
|
||||
another mixin to inject your styles.
|
||||
|
||||
[`@import` rule]: ../import
|
||||
[maps]: ../../values/maps
|
||||
[`@import` rule]: /documentation/at-rules/import
|
||||
[maps]: /documentation/values/maps
|
||||
{% endmarkdown %}
|
||||
|
||||
{% codeExample 'with-mixins' %}
|
||||
@ -591,7 +589,7 @@ don't accidentally write Sass in their CSS, all Sass features that aren't also
|
||||
valid CSS will produce errors. Otherwise, the CSS will be rendered as-is. It can
|
||||
even be [extended][]!
|
||||
|
||||
[extended]: ../extend
|
||||
[extended]: /documentation/at-rules/extend
|
||||
|
||||
## Differences From `@import`
|
||||
|
||||
@ -614,6 +612,6 @@ between the two:
|
||||
|
||||
* `@use` requires quotes around its URL, even when using the [indented syntax].
|
||||
|
||||
[`@import` rule]: ../import
|
||||
[indented syntax]: ../../syntax#the-indented-syntax
|
||||
[`@import` rule]: /documentation/at-rules/import
|
||||
[indented syntax]: /documentation/syntax#the-indented-syntax
|
||||
{% endmarkdown %}
|
||||
|
||||
@ -2,20 +2,20 @@
|
||||
title: Interpolation
|
||||
table_of_contents: true
|
||||
introduction: >
|
||||
Interpolation can be used almost anywhere in a Sass stylesheet to embed the result of a [SassScript expression](../syntax/structure#expressions) into a chunk
|
||||
Interpolation can be used almost anywhere in a Sass stylesheet to embed the result of a [SassScript expression](/documentation/syntax/structure#expressions) into a chunk
|
||||
of CSS. Just wrap an expression in `#{}` in any of the following places:
|
||||
---
|
||||
{% markdown %}
|
||||
* [Selectors in style rules](style-rules#interpolation)
|
||||
* [Property names in declarations](style-rules/declarations#interpolation)
|
||||
* [Custom property values](style-rules/declarations#custom-properties)
|
||||
* [CSS at-rules](at-rules/css)
|
||||
* [`@extend`s](at-rules/extend)
|
||||
* [Plain CSS `@import`s](at-rules/import#plain-css-imports)
|
||||
* [Quoted or unquoted strings](values/strings)
|
||||
* [Special functions](syntax/special-functions)
|
||||
* [Plain CSS function names](at-rules/function#plain-css-functions)
|
||||
* [Loud comments](syntax/comments)
|
||||
* [Selectors in style rules](/documentation/style-rules#interpolation)
|
||||
* [Property names in declarations](/documentation/style-rules/declarations#interpolation)
|
||||
* [Custom property values](/documentation/style-rules/declarations#custom-properties)
|
||||
* [CSS at-rules](/documentation/at-rules/css)
|
||||
* [`@extend`s](/documentation/at-rules/extend)
|
||||
* [Plain CSS `@import`s](/documentation/at-rules/import#plain-css-imports)
|
||||
* [Quoted or unquoted strings](/documentation/values/strings)
|
||||
* [Special functions](/documentation/syntax/special-functions)
|
||||
* [Plain CSS function names](/documentation/at-rules/function#plain-css-functions)
|
||||
* [Loud comments](/documentation/syntax/comments)
|
||||
{% endmarkdown %}
|
||||
|
||||
{% codeExample 'interpolation' %}
|
||||
@ -45,18 +45,18 @@ introduction: >
|
||||
{% markdown %}
|
||||
## In SassScript
|
||||
|
||||
{% # Arguments are (in order): `dart`, `libsass`, `ruby`, optional feature name, additional details within %}
|
||||
{% compatibility true, false, '4.0.0 (unreleased)', 'Modern Syntax' %}
|
||||
{% # Arguments are (in order): `dart`, `libsass`, `node`, `ruby`, optional feature name, additional details within %}
|
||||
{% compatibility true, false, null, '4.0.0 (unreleased)', 'Modern Syntax' %}
|
||||
LibSass and Ruby Sass currently use an older syntax for parsing interpolation in SassScript. For most practical purposes it works the same, but it can behave strangely around [operators][]. See [this document][] for details.
|
||||
|
||||
[operators]: ../operators
|
||||
[operators]: /documentation/operators
|
||||
[this document]: https://github.com/sass/language/blob/master/accepted/free-interpolation.md#old-interpolation-rules
|
||||
{% endcompatibility %}
|
||||
|
||||
Interpolation can be used in SassScript to inject SassScript into [unquoted strings][]. This is particularly useful when dynamically generating names (for example for animations), or when using [slash-separated values][]. Note that interpolation in SassScript always returns an unquoted string.
|
||||
|
||||
[unquoted strings]: ../values/strings#unquoted
|
||||
[slash-separated values]: ../operators/numeric#slash-separated-values
|
||||
[unquoted strings]: /documentation/values/strings#unquoted
|
||||
[slash-separated values]: /documentation/operators/numeric#slash-separated-values
|
||||
{% endmarkdown %}
|
||||
|
||||
{% codeExample 'interpolation-sass-script' %}
|
||||
@ -105,14 +105,12 @@ it to just use a variable in a property value. Instead of writing `color: #{$acc
|
||||
{% endfunFact %}
|
||||
|
||||
{% headsUp %}
|
||||
{% markdown %}
|
||||
It's almost always a bad idea to use interpolation with numbers. Interpolation
|
||||
returns unquoted strings that can't be used for any further math, and it avoids Sass's built-in safeguards to ensure that units are used correctly.
|
||||
|
||||
Sass has powerful [unit arithmetic][] that you can use instead. For example, instead of writing `#{$width}px`, write `$width * 1px`—or better yet, declare the `$width` variable in terms of `px` to begin with. That way if `$width` already has units, you'll get a nice error message instead of compiling bogus CSS.
|
||||
|
||||
[unit arithmetic]: ../values/numbers#units
|
||||
{% endmarkdown %}
|
||||
[unit arithmetic]: /documentation/values/numbers#units
|
||||
{% endheadsUp %}
|
||||
|
||||
{% markdown %}
|
||||
@ -121,7 +119,7 @@ Sass has powerful [unit arithmetic][] that you can use instead. For example, ins
|
||||
In most cases, interpolation injects the exact same text that would be used if the expression were used as a [property value][]. But there is one exception: the quotation marks around quoted strings are removed (even if those quoted strings are in lists). This makes it possible to write quoted strings that contain syntax that's not allowed in SassScript (like selectors) and interpolate
|
||||
them into style rules.
|
||||
|
||||
[property value]: ../style-rules/declarations
|
||||
[property value]: /documentation/style-rules/declarations
|
||||
{% endmarkdown %}
|
||||
|
||||
{% codeExample 'quoted-strings' %}
|
||||
@ -134,9 +132,7 @@ them into style rules.
|
||||
{% endcodeExample %}
|
||||
|
||||
{% headsUp %}
|
||||
{% markdown %}
|
||||
While it's tempting to use this feature to convert quoted strings to unquoted strings, it's a lot clearer to use the [`string.unquote()` function][]. Instead of `#{$string}`, write `string.unquote($string)`!
|
||||
|
||||
[`string.unquote()` function]: ../modules/string#unquote
|
||||
{% endmarkdown %}
|
||||
[`string.unquote()` function]: /documentation/modules/string#unquote
|
||||
{% endheadsUp %}
|
||||
|
||||
@ -24,7 +24,7 @@ complementary_content: |
|
||||
{% markdown %}
|
||||
A variable declaration looks a lot like a [property declaration][]: it's written `<variable>: <expression>`. Unlike a property, which can only be declared in a style rule or at-rule, variables can be declared anywhere you want. To use a variable, just include it in a value.
|
||||
|
||||
[property declaration]: ../style-rules/declarations
|
||||
[property declaration]: /documentation/style-rules/declarations
|
||||
{% endmarkdown %}
|
||||
|
||||
{% codeExample 'variable' %}
|
||||
@ -42,11 +42,11 @@ $border-dark: rgba($base-color, 0.88)
|
||||
border: 1px solid $border-dark
|
||||
{% endcodeExample %}
|
||||
|
||||
{% headsUp %}
|
||||
{% headsUp, false %}
|
||||
{% markdown %}
|
||||
CSS has [variables of its own][], which are totally different than Sass variables. Know the differences!
|
||||
|
||||
[variables of its own]: ../style-rules/declarations#custom-properties
|
||||
[variables of its own]: /documentation/style-rules/declarations#custom-properties
|
||||
|
||||
- Sass variables are all compiled away by Sass. CSS variables are included in the CSS output.
|
||||
|
||||
@ -88,7 +88,7 @@ Normally when you assign a value to a variable, if that variable already had a v
|
||||
|
||||
To make this possible, Sass provides the `!default` flag. This assigns a value to a variable *only if* that variable isn't defined or its value is [`null`][]. Otherwise, the existing value will be used.
|
||||
|
||||
[`null`]: ../values/null
|
||||
[`null`]: /documentation/values/null
|
||||
|
||||
### Configuring Modules
|
||||
|
||||
@ -96,7 +96,7 @@ To make this possible, Sass provides the `!default` flag. This assigns a value t
|
||||
|
||||
Variables defined with `!default` can be configured when loading a module with the [`@use` rule][]. Sass libraries often use `!default` variables to allow their users to configure the library's CSS.
|
||||
|
||||
[`@use` rule]: ../at-rules/use
|
||||
[`@use` rule]: /documentation/at-rules/use
|
||||
|
||||
To load a module with configuration, write `@use <url> with (<variable>: <value>, <variable>: <value>)`. The configured values will override the variables' default values. Only variables written at the top level of the stylesheet with a `!default` flag can be configured.
|
||||
{% endmarkdown %}
|
||||
@ -108,7 +108,7 @@ To load a module with configuration, write `@use <url> with (<variable>: <value>
|
||||
|
||||
Variables that are defined by a [built-in module] cannot be modified.
|
||||
|
||||
[built-in module]: ../modules
|
||||
[built-in module]: /documentation/modules
|
||||
{% endmarkdown %}
|
||||
|
||||
{% codeExample 'built-in-variables', , false %}
|
||||
@ -217,9 +217,9 @@ $variable: first global value
|
||||
value: $variable
|
||||
{% endcodeExample %}
|
||||
|
||||
{% headsUp %}
|
||||
{% # Arguments are (in order): `dart`, `libsass`, `ruby`, optional feature name, additional details within %}
|
||||
{% compatibility "2.0.0", false, false%}
|
||||
{% headsUp, false %}
|
||||
{% # Arguments are (in order): `dart`, `libsass`, `node`, `ruby`, optional feature name, additional details within %}
|
||||
{% compatibility "2.0.0", false, null, false%}
|
||||
Older Sass versions allowed `!global` to be used for a variable that doesn't exist yet. This behavior was deprecated to make sure each stylesheet declares the same variables no matter how it's executed.
|
||||
{% endcompatibility %}
|
||||
|
||||
@ -236,7 +236,7 @@ don't shadow variables at the same level as the flow control rule. Instead, they
|
||||
just assign to those variables. This makes it much easier to conditionally
|
||||
assign a value to a variable, or build up a value as part of a loop.
|
||||
|
||||
[flow control rules]: ../at-rules/control
|
||||
[flow control rules]: /documentation/at-rules/control
|
||||
{% endmarkdown %}
|
||||
|
||||
{% codeExample 'flow-control' %}
|
||||
@ -272,9 +272,7 @@ $accent-color: #6a1b9a !default
|
||||
{% endcodeExample %}
|
||||
|
||||
{% headsUp %}
|
||||
{% markdown %}
|
||||
Variables in flow control scope can assign to existing variables in the outer scope, but new variables declared in flow control scope won't be accessible in the outer scope. Make sure the variable is already declared before you assign to it, even if you need to declare it as `null`.
|
||||
{% endmarkdown %}
|
||||
{% endheadsUp %}
|
||||
|
||||
{% markdown %}
|
||||
@ -282,15 +280,15 @@ Variables in flow control scope can assign to existing variables in the outer sc
|
||||
|
||||
The Sass core library provides a couple advanced functions for working with variables. The [`meta.variable-exists()` function][] returns whether a variable with the given name exists in the current scope, and the [`meta.global-variable-exists()` function][] does the same but only for the global scope.
|
||||
|
||||
[`meta.variable-exists()` function]: ../modules/meta#variable-exists
|
||||
[`meta.global-variable-exists()` function]: ../modules/meta#global-variable-exists
|
||||
[`meta.variable-exists()` function]: /documentation/modules/meta#variable-exists
|
||||
[`meta.global-variable-exists()` function]: /documentation/modules/meta#global-variable-exists
|
||||
{% endmarkdown %}
|
||||
|
||||
{% headsUp %}
|
||||
{% headsUp, false %}
|
||||
{% markdown %}
|
||||
Users occasionally want to use interpolation to define a variable name based on another variable. Sass doesn't allow this, because it makes it much harder to tell at a glance which variables are defined where. What you *can* do, though, is define a [map][] from names to values that you can then access using variables.
|
||||
|
||||
[map]: ../values/maps
|
||||
[map]: /documentation/values/maps
|
||||
{% endmarkdown %}
|
||||
|
||||
{% codeExample 'advanced-variable-functions' %}
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user