2200cde988
From an engineers perspective, whenever specifying colors from now on we should use the form: ``` color: rgb(var(--tone-red-500)); ``` Please note: - Use rgb. This lets us do this like rgb(var(--tone-red-500) / 10%) so we can use a 10% opacity red-500 if we ever need to whilst still making use of our color tokens. - Use --tone-colorName-000 (so the prefix tone). Previously we could use a mix of --gray-500: $gray-500 (note the left hand CSS prop and right hand SASS var) for the things we need to theme currently. As we no longer use SASS we can't do --gray-500: --gray-500, so we now do --tone-gray-500: --gray-500. Just for clarity after that, whenever specifying a color anywhere, use rgb and --tone. There is only one reason where you might not use tone, and that is if you never want a color to be affected by a theme (for example a background shadow probably always should use --black) There are a 2 or 3 left for the code editor, plus our custom-query values |
||
---|---|---|
.. | ||
README.mdx | ||
debug.scss | ||
index.scss | ||
layout.scss | ||
skin.scss |
README.mdx
--- class: css state: needs-love --- # inline-alert CSS component for giving inline feedback to the user, generally used for form element feedback like errors and suchlike. Potentially an improvement here could be that this could make use of `%horizontal-kv-list`, and do we really need a placeholder per state, can we just use a class? ```hbs preview-template <label class="type-text"> <span>Input some text</span> <input type="text" /> <strong class={{or this.type "info"}}>{{capitalize (or this.type "info")}}</strong> </label> <figure> <figcaption>Provide a widget to change the <code>class</code></figcaption> <select onchange={{action (mut this.type) value="target.value"}} > <option>info</option> <option>success</option> <option>warning</option> <option>error</option> </select> </figure> ``` ```css strong.info { @extend %inline-alert-info; } strong.success { @extend %inline-alert-success; } strong.warning { @extend %inline-alert-warning; } strong.error { @extend %inline-alert-error; } ```