scss - akcdotorg/akc.org GitHub Wiki
We're attempting to standardize a few behaviors in our new SCSS, to wit:
The final css will be split into the following 3 files, used to build separation between use-cases:
- wrapper.css: contains styles for the page-wrapper, especially the header and footer.
- normalize.css: contains styles to normalize browser behaviors across different browsers and browser versions.
- screen.css: general styles for akc.org.
The goal is to have the default appearance of a particular kind of DOM element be as-close-as-possible to the most common use of that kind of DOM element. Classes, pages, and context can be used to refine the appearance for specific uses, but the goal remains that, in the absence of other context, a naked < p > tag would appear with the most-commonly desired appearance -- presumably in the case of a < p > tag, we'd want it to be a paragraph in a story.
A quick set of examples:
p {
// Naked p tag, default appearance
&.myclass {
// p class="myclass" appearance
}
}
#akcorg-header {
p {
// Appearance of p within the <div id="akcorg-header">
&.myclass {
// p class="myclass" appearance within the <div id="akcorg-header">
}
}
}
body.embeds_media_list {
p {
// Appearance of p on a page generated from the embeds_media_list template
}
#akcorg-header {
p {
// Appearance of p within the <div id="akcorg-header"> on a page generated from the embeds_media_list template
&.myclass {
// p class="myclass" appearance within the <div id="akcorg-header"> on a page generated from the embeds_media_list template
}
}
}
}
@media #{$large} {
p {
// Appearance of p in the large breakpoint
}
body.embeds_media_list {
p {
// Appearance of p on a page generated from the embeds_media_list template, in the large breakpoint
}
#akcorg-header {
p {
// Appearance of p within the <div id="akcorg-header"> on a page generated from the embeds_media_list template, in the large breakpoint
&.myclass {
// p class="myclass" appearance within the <div id="akcorg-header"> on a page generated from the embeds_media_list template, in the large breakpoint
}
}
}
}
}
We should practice to use of @extend as much as possible. A quick set of examples:
%media-social-btn {
ul.social {
// Common-style
}
}
.class-a {
@extend %media-social-btn;
// Add more style
}
.class-b {
@extend %media-social-btn;
// Add more style
}
We're defining the breakpoints themselves in one place, and referencing from there: public_html/assets/akcorg/scss/_2-variables.scss. There are variables set there, such as $small, $small-to-medium, etc. To use breakpoints in css rules, do it like so:
#akcorg-header {
.logo {
font-size:4.72222em;
position:absolute;
color:$teal;
@media #{$small} {
// Rules for the small breakpoint here
}
}
}
The way that we're intending to expose/hide various elements at various breakpoints is by applying a series of classes to the elements of the DOM:
- small-only, medium-only, large-only: appear only at that breakpoint.
- no-small, no-medium, no-large: exclude rule from that breakpoint.
- no-portrait, no-landscape: apply only to that orientation.
- portrait-only, landscape-only: exclude rule from the opposite orientation.
Do NOT replicate the functionality of these with additional classes. If you see a need for anything else, let's discuss.
Colors are also defined in one place, and referenced from there: public_html/assets/akcorg/scss/_settings.scss
When coming across another color NOT included there, let's discuss, and we'll add as-needed.
Use colors like so, with the variable name rather than the hexadecimal value:
.open .secondary-nav {
background-color:$teal;
}
Doing so allows us to update $teal in one place, rather than tracking down umpteen million instances of #01d4b4
When wanting to ensure that something is hidden, or that something which might be hidden otherwise is not hidden, use the element-visible and element-invisible mixins:
.large-only { @include element-visible; }
.no-large { @include element-invisible; }
When you want to know what exactly a mixin does, search the codebase within public_html/assets/akcorg for the definition of the mixin. The same applies to questions of the usage of them: look through the codebase to see how they have been used successfully.