Elements: Forms and form controls

[downzer0]

This work adds forms and form elements to the pattern library. It consists of:

• input, select, and textarea styles
• scripts that visually replace select, radio, and checkbox controls giving us more control over the UI
• suggested, semantic markup structure
• styling for form elements in general

Form control replacements

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 options are:

• radio buttons
• checkbox buttons
• select menus

Radio buttons and checkboxes

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.

Select boxes

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.

States

For each of the form input controls we've created and demonstrated the following states:

• normal
• active, checked, selected, and hovered
• disabled
• required

User feedback, message handling

This piece of work also includes user feedback messages for form field validation. The cases included are:

• warning
• error
• success

Nested styles

In many cases we're using nested styles. The aim here is to slightly reduce modularity but promote a semantic structure.

Form control heights and widths

To provide a nice set of options both for us internally and the Open edX community, I've created various sizes for form controls.

Height

Height primarily relates to textareas. To use a height, choose one of the following:

• short
• base our default height
• tall

Width

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

Range slider and Progress bars

The visual UI included a slider, but it was a hybrid of a progress bar and a range slider. Since nothing like that is available natively I created two different elements: input type="range" and progress and created styles for these as I found fit.

Slider/Range

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. I've included styles for this that makes the handle increase in size when it's hovered over, making the click target/control more usable.

Progress

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.

---

Browser testing

This work has been tested in the following browsers:

Platform	Browser	Version	Passes
Mac	Chrome	44	Yes
	Firefox	24.3	Yes
	Safari	8	Yes
PC	Chrome	43	Yes
	Firefox	37	Yes
	IE	10	Yes *
		11	Yes *

• Mostly works. See this article for more information.

---

Reviewers:

• @talbs ✅
• @frrrances
• @AlasdairSwan ✅
• @cptvitamin ✅

[frrrances]

Thanks, @clrux! I walked through the work visually and have some feedback below - I'll look through the code next.

Element stuff:

1. placeholder text looks like it should be cool gray, and borders/outlines should be neutral gray
2. disabled field looks like the background should be cool gray but it looks neutral gray now
3. remove background on focused simplified input
4. missing required state of text input (with asterisk)
5. alignment of label and radio/checkbox input - label is a little high
6. radio buttons and checkboxes look different - current style is confusing - can’t tell what’s checked/selected
7. use checkbox checked dark icon, and add radio checked (fa-dot-circle-o) to icons and use that for selected radio state
8. select arrow looks different - use fa-caret-down
9. missing correct and error states (maybe not part of this story?)

Pattern Library stuff:

• Too many headers - change hd-5 to hd-6, remove "Default" for text input section
• Provide descriptive labels, like Brian did in his sketch file, eg. "Your Name (Simplified Label/Field)*"

[frrrances]

change to hd-6 class

[frrrances]

Okay, I made it through all the code! Left a bunch of comments. Once you address those, I can run through again.

One last request: it might be nice to have an example form from start to end at some point - maybe on a standalone page? Not sure if we're ready for that, but it would be really helpful for people using it and to get a sense how it all goes together.

[talbs]

@clrux, just a heads up, locally after I use the gulp command and fire up your branch, I'm getting some local file diffs that I'm not seeing checked in here. Can you check on the following output?

On branch clrux/elements-forms-and-form-controls
Your branch is up-to-date with 'origin/clrux/elements-forms-and-form-controls'.
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   public/pl/css/main-ltr.css
    modified:   public/pl/css/main-rtl.css

no changes added to commit (use "git add" and/or "git commit -a")

[downzer0]

Replaced by #91.