Merge branch 'main' into highlight-styles

This commit is contained in:
Stacy Kvernmo 2023-05-30 15:43:19 -05:00
commit c7ba638b93
13 changed files with 92 additions and 69 deletions

View File

@ -34,10 +34,6 @@
{%- if details | strip -%}
<div class="sl-c-callout sl-c-callout--impl-status">
{% if codeExampleDetails %}
{{ details }}
{% else %}
{{ details | markdown }}
{% endif %}
{% if useMarkdown %}{{ details | markdown }}{% else %}{{ details }}{% endif %}
</div>
{%- endif -%}

View File

@ -4,9 +4,10 @@ introduction: >
The `@at-root` rule is usually written `@at-root <selector> { ... }` and
causes everything within it to be emitted at the root of the document instead
of using the normal nesting. It's most often used when doing [advanced
nesting](/documentation/style-rules/parent-selector#advanced-nesting) with the [SassScript
parent selector](/documentation/style-rules/parent-selector#in-sassscript) and [selector
functions](/documentation/modules/selector).
nesting](/documentation/style-rules/parent-selector#advanced-nesting) with the
[SassScript parent
selector](/documentation/style-rules/parent-selector#in-sassscript) and
[selector functions](/documentation/modules/selector).
---
{% render 'code-snippets/example-advanced-nesting' %}
@ -75,4 +76,4 @@ used in queries:
all at-rules but preserves style rules.
* `all` refers to all at-rules *and* style rules should be excluded.
{% endmarkdown %}
{% endmarkdown %}

View File

@ -3,15 +3,15 @@ title: "@each"
introduction: >
The `@each` rule makes it easy to emit styles or evaluate code for each
element of a [list](/documentation/values/lists) or each pair in a
[map](/documentation/values/maps). Its great for repetitive styles that only have a
few variations between them. Its usually written `@each <variable> in
[map](/documentation/values/maps). Its great for repetitive styles that only
have a few variations between them. Its usually written `@each <variable> in
<expression> { ... }`, where the
[expression](/documentation/syntax/structure#expressions) returns a list. The block is
evaluated for each element of the list in turn, which is assigned to the given
variable name.
[expression](/documentation/syntax/structure#expressions) returns a list. The
block is evaluated for each element of the list in turn, which is assigned to
the given variable name.
---
{% render 'code-snippets/example-each-list' %}
{% render 'code-snippets/example-each-list' %}
{% markdown %}
## With Maps
@ -53,6 +53,9 @@ $icons:
===
$icons: "eye" "\f112" 12px, "start" "\f12e" 16px, "stop" "\f12f" 10px
@each $name, $glyph, $size in $icons
.icon-#{$name}:before
display: inline-block

View File

@ -1,13 +1,13 @@
---
title: "@for"
introduction: >
The `@for` rule, written `@for <variable> from <expression> to <expression>
{ ... }` or `@for <variable> from <expression> through <expression> { ... }`,
The `@for` rule, written `@for <variable> from <expression> to <expression> {
... }` or `@for <variable> from <expression> through <expression> { ... }`,
counts up or down from one number (the result of the first
[expression](/documentation/syntax/structure#expressions)) to another (the result of
the second) and evaluates a block for each number in between. Each number
along the way is assigned to the given variable name. If `to` is used, the
final number is excluded; if `through` is used, it's included.
[expression](/documentation/syntax/structure#expressions)) to another (the
result of the second) and evaluates a block for each number in between. Each
number along the way is assigned to the given variable name. If `to` is used,
the final number is excluded; if `through` is used, it's included.
---
{% codeExample 'for' %}

View File

@ -4,9 +4,10 @@ table_of_contents: true
introduction: >
The `@if` rule is written `@if <expression> { ... }`, and it controls whether
or not its block gets evaluated (including emitting any styles as CSS). The
[expression](/documentation/syntax/structure#expressions) usually returns either
[`true` or `false`](/documentation/values/booleans)—if the expression returns `true`,
the block is evaluated, and if the expression returns `false` its not.
[expression](/documentation/syntax/structure#expressions) usually returns
either [`true` or `false`](/documentation/values/booleans)—if the expression
returns `true`, the block is evaluated, and if the expression returns `false`
its not.
---
{% render 'code-snippets/example-if' %}
@ -55,6 +56,8 @@ $dark-text: #d2e1dd
background-color: $dark-background
color: $dark-text
.banner
@include theme-colors($light-theme: true)
body.dark &
@ -128,6 +131,8 @@ evaluated if every other block fails.
@else
@error "Unknown direction #{$direction}."
.next
@include triangle(5px, black, right)
===
@ -141,4 +146,4 @@ evaluated if every other block fails.
}
{% endcodeExample %}
{% render 'documentation/snippets/truthiness-and-falsiness' %}
{% render 'documentation/snippets/truthiness-and-falsiness' %}

View File

@ -3,19 +3,22 @@ title: Flow Control Rules
introduction: >
Sass provides a number of at-rules that make it possible to control whether
styles get emitted, or to emit them multiple times with small variations. They
can also be used in [mixins](/documentation/at-rules/mixin) and [functions](/documentation/at-rules/function) to write small
algorithms to make writing your Sass easier. Sass supports four flow control
rules:
can also be used in [mixins](/documentation/at-rules/mixin) and
[functions](/documentation/at-rules/function) to write small algorithms to
make writing your Sass easier. Sass supports four flow control rules.
---
- [`@if`](/documentation/at-rules/control/if) controls whether or not a block is evaluated.
- [`@if`](/documentation/at-rules/control/if) controls whether or not a block is
evaluated.
- [`@each`](/documentation/at-rules/control/each) evaluates a block for each element in a [list][] or
each pair in a [map][].
- [`@each`](/documentation/at-rules/control/each) evaluates a block for each
element in a [list][] or each pair in a [map][].
- [`@for`](/documentation/at-rules/control/for) evaluates a block a certain number of times.
- [`@for`](/documentation/at-rules/control/for) evaluates a block a certain
number of times.
- [`@while`](/documentation/at-rules/control/while) evaluates a block until a certain condition is met.
- [`@while`](/documentation/at-rules/control/while) evaluates a block until a
certain condition is met.
[list]: /documentation/values/lists
[map]: /documentation/values/maps

View File

@ -2,9 +2,9 @@
title: "@while"
introduction: >
The `@while` rule, written `@while <expression> { ... }`, evaluates its block
if its [expression](/documentation/syntax/structure#expressions) returns `true`. Then,
if its expression still returns `true`, it evaluates its block again. This
continues until the expression finally returns `false`.
if its [expression](/documentation/syntax/structure#expressions) returns
`true`. Then, if its expression still returns `true`, it evaluates its block
again. This continues until the expression finally returns `false`.
---
{% codeExample 'while' %}
@ -31,6 +31,8 @@ sup {
$value: math.div($value, $ratio)
@return $value
$normal-font-size: 16px
sup
font-size: scale-below(20px, 16px)
@ -41,12 +43,13 @@ sup {
{% endcodeExample %}
{% headsUp %}
Although `@while` is necessary for a few particularly complex stylesheets, you're
usually better of using either [`@each`][] or [`@for`][] if either of them will
work. They're clearer for the reader, and often faster to compile as well.
Although `@while` is necessary for a few particularly complex stylesheets,
you're usually better of using either [`@each`][] or [`@for`][] if either of
them will work. They're clearer for the reader, and often faster to compile as
well.
[`@each`]: /documentation/at-rules/control/each
[`@for`]: /documentation/at-rules/control/for
[`@each`]: /documentation/at-rules/control/each
[`@for`]: /documentation/at-rules/control/for
{% endheadsUp %}
{% render 'documentation/snippets/truthiness-and-falsiness' %}

View File

@ -2,7 +2,9 @@
title: CSS At-Rules
table_of_contents: true
---
{% compatibility '1.15.0', false, null, false, "Name Interpolation"%}
{% # Arguments are (in order): `dart`, `libsass`, `node`, `ruby`, optional feature name, additional details within %}
{% compatibility '1.15.0', false, null, false, "Name Interpolation" %}
LibSass, Ruby Sass, and older versions of Dart Sass don't support
[interpolation][] in at-rule names. They do support interpolation in values.
@ -65,9 +67,10 @@ having to rewrite the style rule's selector.
display: block
{% endcodeExample %}
{{ '## `@media`' | markdown }}
{{ '## `@media`' | markdown }}
{% compatibility '1.11.0', false, null, '3.7.0', 'Range Syntax', true %}
{% # Arguments are (in order): `dart`, `libsass`, `node`, `ruby`, optional feature name, additional details within %}
{% compatibility '1.11.0', false, null, '3.7.0', 'Range Syntax', false %}
{% markdown %}
LibSass and older versions of Dart Sass and Ruby Sass don't support media
queries with features written in a [range context][]. They do support other
@ -76,7 +79,7 @@ standard media queries.
[range context]: https://www.w3.org/TR/mediaqueries-4/#mq-range-context
{% endmarkdown %}
{% codeExample 'range-syntax' %}
{% codeExample 'range-syntax', false %}
@media (width <= 700px) {
body {
background: green;
@ -92,7 +95,8 @@ standard media queries.
background: green;
}
}
{% endcodeExample %}{% endcompatibility %}
{% endcodeExample %}
{% endcompatibility %}
{% markdown %}
The [`@media` rule][] does all of the above and more. In addition to allowing
@ -172,6 +176,8 @@ the declaration queries.
@supports (position: sticky)
position: sticky
.banner
@include sticky-position
{% endcodeExample %}

View File

@ -1,12 +1,14 @@
---
title: "@debug"
introduction: >
Sometimes its useful to see the value of a [variable](/documentation/variables) or
[expression](/documentation/syntax/structure#expressions) while youre developing your
stylesheet. Thats what the `@debug` rule is for: its written
Sometimes its useful to see the value of a
[variable](/documentation/variables) or
[expression](/documentation/syntax/structure#expressions) while youre
developing your stylesheet. Thats what the `@debug` rule is for: its written
`@debug <expression>`, and it prints the value of that expression, along with
the filename and line number.
---
{% codeExample 'debug', false %}
@mixin inset-divider-offset($offset, $padding) {
$divider-offset: (2 * $padding) + $offset;
@ -31,12 +33,11 @@ implementation. This is what it looks like in Dart Sass:
```
test.scss:3 Debug: divider offset: 132px
```
{% endmarkdown %}
{% funFact %}
You can pass any value to `@debug`, not just a string! It prints the same
representation of that value as the [`meta.inspect()` function][].
You can pass any value to `@debug`, not just a string! It prints the same
representation of that value as the [`meta.inspect()` function][].
[`meta.inspect()` function]: /documentation/modules/meta#inspect
[`meta.inspect()` function]: /documentation/modules/meta#inspect
{% endfunFact %}
{% endmarkdown %}

View File

@ -1,11 +1,13 @@
---
title: "@error"
introduction: >
When writing [mixins](/documentation/at-rules/mixin) and [functions](/documentation/at-rules/function) that take arguments,
you usually want to ensure that those arguments have the types and formats
your API expects. If they aren't, the user needs to be notified and your
mixin/function needs to stop running.
When writing [mixins](/documentation/at-rules/mixin) and
[functions](/documentation/at-rules/function) that take arguments, you usually
want to ensure that those arguments have the types and formats your API
expects. If they aren't, the user needs to be notified and your mixin/function
needs to stop running.
---
{% markdown %}
Sass makes this easy with the `@error` rule, which is written
`@error <expression>`. It prints the value of the [expression][] (usually a
@ -53,6 +55,8 @@ tells whatever system is running it that an error occurred.
left: $right-value
right: $left-value
.sidebar
@include reflexive-position(top, 12px)
// ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@ -73,4 +77,4 @@ Error: "Property top must be either left or right."
example.scss 3:5 reflexive-position()
example.scss 19:3 root stylesheet
```
{% endmarkdown %}
{% endmarkdown %}

View File

@ -1,10 +1,11 @@
---
title: "@warn"
introduction: >
When writing [mixins](/documentation/at-rules/mixin) and [functions](/documentation/at-rules/function), you may want to
discourage users from passing certain arguments or certain values. They may be
passing legacy arguments that are now deprecated, or they may be calling your
API in a way thats not quite optimal.
When writing [mixins](/documentation/at-rules/mixin) and
[functions](/documentation/at-rules/function), you may want to discourage
users from passing certain arguments or certain values. They may be passing
legacy arguments that are now deprecated, or they may be calling your API in a
way thats not quite optimal.
---
{% markdown %}
@ -63,4 +64,4 @@ Warning: Unknown prefix wekbit.
example.scss 6:7 prefix()
example.scss 16:3 root stylesheet
```
{% endmarkdown %}
{% endmarkdown %}

View File

@ -14,10 +14,10 @@ write `string.index($string, " ")`. The [`string.index()` function][] returns
`null` if the string isn't found and a number otherwise.
[`string.index()` function]: /documentation/modules/string#index
{% endmarkdown %}
{% headsUp %}
Some languages consider more values falsey than just `false` and `null`. Sass
isn't one of those languages! Empty strings, empty lists, and the number `0`
are all truthy in Sass.
isn't one of those languages! Empty strings, empty lists, and the number `0` are
all truthy in Sass.
{% endheadsUp %}
{% endmarkdown %}

View File

@ -28,7 +28,7 @@ export const compatibility = async (
node: string | boolean | null = null,
ruby: string | boolean | null = null,
feature: string | null = null,
codeExampleDetails: boolean | null = null,
useMarkdown = true,
) =>
liquidEngine.renderFile('compatibility', {
details,
@ -37,7 +37,7 @@ export const compatibility = async (
node,
ruby,
feature,
codeExampleDetails,
useMarkdown,
});
/**