-
Notifications
You must be signed in to change notification settings - Fork 39
Styleguide: Forms
This document is supplemental to our main styleguides:
- General Front End Styleguide
- Accessibility Styleguide
- HTML Styleguide
- Forms Styleguide
- Sass & CSS Styleguide
- JavaScript Styleguide
Forms allow users to interact with the interface, set preferences, and enter any necessary personal information. They also form the base of individual exercises within each class. The examples below demonstrate how to use each type of form control and provides any applicable display options.
Note the markup in each case to get a sense of semantics and structure.
We've covered all of the basics here, plus a few additional HTML5 controls. They are:
-
input
text
email
tel
checkbox
radio
range
select
textarea
progress
In a few cases, we've provided alternate visual presentations for some fields, which give the control an enhanced or alternate presentation.
For certain inputs
and selects
we're offering options to use either the default browser-rendered control or a replaced control, either rendered by JS or CSS or both. The idea for the radio buttons and checkboxes came from Heydon Pickering and an article on Sitepoint. The form controls with enhanced options are:
-
radio
buttons -
checkbox
buttons -
select
menus
To enable the enhanced version of a radio button or a checkbox, do the following:
<input type="radio" class="replace-radio">
<input type="checkbox" class="replace-checkbox">
Replacing radio buttons and checkboxes uses an accessible CSS-only approach that hides the default control, replacing it with a CSS rendered one. Interactions with the control still happen on the default control which maintains full accessibility and browser methods.
To enable the enhanced version of a select menu, do the following:
<select class="replace-select">
Replacing select menus uses an accessible JavaScript and CSS approach. JavaScript hides the default control, replacing it with a styled wrapper using the selected value. Interaction still happens with the default control which maintains complete accessibility and compliance.
To provide a nice set of options both for us internally and the Open edX community, We've created various sizes for form controls.
Height primarily relates to textareas
. To use a height, choose one of the following:
short
-
base
our default height tall
Width can be set for any form control. To use a width, choose one of the following:
short
-
base
our default width wide
-
block
which fills the entire width of the parent container
The slider control allows "notched" or fixed selections along a track. There is no "before/after" or "complete/incomplete" which was the discrepancy in the UI. We've included styles for this that makes the handle increase in size when it's hovered over, making the click target/control more usable.
Unlike slider controls, progress bars do have a "before/after" or a "complete/incomplete" state. This matches the UI a little closer, but progress bars don't have drag handles.
In many cases we're using nested styles. The aim here is to slightly reduce modularity but promote a semantic structure. The following is an example of our suggested structure.
<form class="form">
<fieldset class="form-group">
<legend class="form-group-hd">Profile information</legend>
<div class="field">
<label class="field-label" for="full-name">Full name</label>
<input class="field-input input-text" type="text" id="full-name" name="full-name">
</div>
<div class="field">
<label class="field-label" for="email-address">Email address</label>
<input class="field-input input-text" type="email" id="email-address" name="email-address">
</div>
<div class="field">
<label class="field-label" for="username">Username</label>
<input class="field-input input-text" type="text" id="username" name="username">
</div>
<div class="form-controls">
<button class="btn btn-primary btn-base" type="submit">Save information</button>
<button class="btn btn-secondary btn-base" type="button">Cancel</button>
</div>
</fieldset>
</form>