Problem description
When creating web pages and applications, a button style is needed to visually emphasize possible user actions. These styles are applied as an addition to already interactive elements such as links and user inputs.
The button style is expected to remain visually consistent across several different HTML elements, including, but not limited to:
The button style relies upon a base class of unit-button. This class provides the default styles for all other button variants but has very few style decisions attached to it. Visual space is provided with some default padding, The background-color is inherited, a border of 1px is defined and the button is set to display as an inline-flex item, which aids in text alignment and icon / trigger placement within a button.
Additional styles are for color / style:
unit-button--light
unit-button--dark
unit-button--simple
for layout:
unit-button--block
for internal elements
unit-button--has-icon-left
unit-button--has-icon-right
unit-button--has-separator-left
unit-button--has-separator-right
and for child elements
unit-button__icon
Additional styles required can be added via utilities as needed (ie. text-lg, bg-black, text-white, md--text-3xl).
Responsive behaviour considerations
By default, the base styles for buttons would have no preference for font-size or line height - these would be inherited by the page styles. Modifications would be applied with utilities. The utilities are responsive in nature, so we can alter any styling or behaviour based on viewport.
Color variables supplied in the button component are not assumed to be final, and are easily overridable by redeclaring the CSS variable. However, as tested, they are AAA accessible.
Alternatives considered
Alternatives considered have been eschewing the additive base-class + modifier-class approach for a more fully-controlled single class payload with all styles defined. This would be preferable if there were a single set of styles, however since we expect these styles to be used in a wide variety of implementations, flexibility is preferred.
Problem description
When creating web pages and applications, a button style is needed to visually emphasize possible user actions. These styles are applied as an addition to already interactive elements such as links and user inputs.
The button style is expected to remain visually consistent across several different HTML elements, including, but not limited to:
abuttoninput[type="button"],input[type="reset"],input[type="submit"]Proposed solution
https://codepen.io/occupant/pen/WNvZrLO
The button style relies upon a base class of
unit-button. This class provides the default styles for all other button variants but has very few style decisions attached to it. Visual space is provided with some defaultpadding, Thebackground-coloris inherited, a border of 1px is defined and the button is set to display as aninline-flexitem, which aids in text alignment and icon / trigger placement within a button.Additional styles are for color / style:
unit-button--lightunit-button--darkunit-button--simplefor layout:
unit-button--blockfor internal elements
unit-button--has-icon-leftunit-button--has-icon-rightunit-button--has-separator-leftunit-button--has-separator-rightand for child elements
unit-button__iconAdditional styles required can be added via utilities as needed (ie.
text-lg,bg-black,text-white,md--text-3xl).Responsive behaviour considerations By default, the base styles for buttons would have no preference for font-size or line height - these would be inherited by the page styles. Modifications would be applied with utilities. The utilities are responsive in nature, so we can alter any styling or behaviour based on viewport.
Accessibility considerations and test conducted
WCAG 2.0 AAA check passes
The title attribute (for a and button tags) is not recommended - instead, descriptive, meaningful text should be used.
Color variables supplied in the button component are not assumed to be final, and are easily overridable by redeclaring the CSS variable. However, as tested, they are AAA accessible.
Alternatives considered
Alternatives considered have been eschewing the additive base-class + modifier-class approach for a more fully-controlled single class payload with all styles defined. This would be preferable if there were a single set of styles, however since we expect these styles to be used in a wide variety of implementations, flexibility is preferred.
Additional context
Feature Review Checklist: