Buttons and their containers
The most important thing to keep in mind about buttons and similar low level DOM elements is that they have very limited opinions about their palette and even some structure. This is because the container of buttons has nearly all of the required context to structure and style the buttons.
Consider the difference in the interface between a content header buttons and content footer button in this example. Most of the structure (alignment, padding, font-size, margin) are all defined by the content header container or content footer container elements. Additionally, all of the theme is defined by those parent elements. What is shared by all buttons is the fundamental cursor behaviors, and a default display opinion. A glance at the defined css for buttons reveals this fact:
.c-button { @include pseudo-button(); @include normalize-buttons(); display: inline-block; }
The pseudo-button
mixin source confirms the limited cursor style opinions:
&:hover { cursor: pointer; &:disabled, &.is-disabled, &:active, &.is-active { cursor: default; } }
So, if buttons are not styled mostly by the c-button
class, how do we style buttons?
Allowing cross coupling
Buttons and links are extremely popular UI element, so much so that we have made a pragmatic decision to depart from our normal convention of tight BEM naming, and instead prefer to use the low level block classes to style elements.
Let's consider the following css snippet used to style the content footer buttons:
.c-content { .c-content-footer { .c-button { @include pill-button; align-items: center; + .c-button { margin-left: $inv-base-spacing * 2; } } } }
In this example, we do not see an element class for button under the content footer element. That is, with our typical naming convention, we would expect something like this:
.c-content { .c-content-footerbutton { @include pill-button; align-items: center; + .c-button { margin-left: $inv-base-spacing * 2; } } }
However, because buttons are such a popular element, and buttons are also low-level in the DOM (that is, they typically do not operate as containers of many other elements), we allow the content footer to use the button class directly.
We do this as an important factor for our authoring is readability of classes in markup. Namespaces are an example of adding something on top of the BEM syntax to increase readability. Using the c-button
class is yet another:
Without our convention:
<div class="c-content"> <div class="c-content-container"> <div class="c-content-footer"> <a href="#" class="c-button c-content-footerButton">Cancel</a> <button class="c-button c-button--primary c-content-footerButton">Submit Form</button> </div> </div> </div>
With our convention:
<div class="c-content"> <div class="c-content-container"> <div class="c-content-footer"> <a href="#" class="c-button">Cancel</a> <button class="c-button c-button--primary">Submit Form</button> </div> </div> </div>
It is also worth noting the other components that follow this cross-coupling pattern:
c-icon
c-link
Button Variables and mixins
Although we expect containers of buttons to define the button structure and palette via CSS, there will be some sharing of similar button style. To achieve this, we utilize variables and mixins to ensure consistent implementations.
For the list of these variables and mixins see the variable and mixins sections of the guide.