The Styleguide
and You
HTML & CSS at Attune
Olex, Oct 2020
This Talk...
- Attune's philosophy around HTML/CSS
- Gotchas (readme overview)
- What's in the styleguide?
- How and when to add to the styleguide?
-
What's next?
Philosophy
- HTML should be terse
-
Do not mess with specificity, use it!
- Use the cascade
- Assume styles are global within an app
- CSS should be deletable
Specificity
Attune's Styleguide targets default, "unstyled" elements with broad selectors such as element selectors.
<h1>This is a headline</h1>
Attune's Styleguide provides "utility" classes to override some defaults, mainly for typography.
<h1 class="h3">This is a headline</h1>
This looks like an h3, as classes are more specific
Specificity
Some looks require more than the bare html, e.g. to distinguish a label that wraps a checkbox, from a label above a text input. This is done via classes.
<label for="cool-beans" class="checkbox">
<input id="cool-beans" type="checkbox">
<span>Cool beans</span>
</label>
<label for="spill-beans">Spill the beans:</label>
<input id="spill-beans" type="text" placeholder="...">
note the class="checkbox"
Specificity
Styleguide uses lower levels of specificity and classes
Application CSS should be loaded after Styleguide CSS
Application CSS should be 90% class selectors, which will always override the styleguide defaults
Modified / special-cases of components should use a second class to increase specificity
Deletable CSS
.is-active {
border: 2px dashed orange;
filter: contrast(120%);
}
.hab-carousel-active {
border: 2px dashed orange;
filter: contrast(120%);
}
A good gut-check: looking only at this selector,
do you know when it might get removed from the repo?
Modifier Syntax
/* Bad */
.coverage-info-box {
&.hidden {
/* ... */
}
}
/* Good */
.coverage-info-box {
&.coverage-info-box__hidden {
/* ... */
}
}
Avoid Parent Selectors
It's always better to create a novel, modified version of a component instead of relying on parents' classes
/* 2x specificity, bad */
.cool-sidebar {
.button {
...
}
}
/* 2x specificity, good */
.button {
&.button__cool-sidebar {
...
}
}
/* e.g. class="button button__cool-sidebar" */
1-class vs Modifier
/* Specificity too low */
.cool-sidebar-button {
}
/* Correct */
.button {
&.button__cool-sidebar {
...
}
}
Modifying components with existing class names should be done using modifier classes, not a novel class.
Otherwise, your novel class will be lower specificity than existing modifiers.
the styleguide and you
By Olex Ponomarenko
the styleguide and you
- 301