3.9 KiB
| layout | title | published | introduction | color | name | icon | icon_regular |
|---|---|---|---|---|---|---|---|
| post | New field element (for better controls) | true | <p>The <code>.control</code> element has been a very versatile container for form controls. But it came at a cost: it was difficult to combine its <strong>block</strong> characteristics with its <strong>inline</strong> variations.</p> | success | Field element | square | true |
TL;DR: there's a new .field container, and .control has been re-purposed.
Since the beginning, the .control has been a very versatile element that allowed:
- to space controls vertically
- to include an icon alongside inputs, buttons, textareas...
- to append a loading spinner
- to create horizontal forms
- to create control addons
- to create control groups
The problem
The .control element acted as both a block container (for spacing, for other controls in a horizontal form), but also an inline container (for adding an icon, a loader, an addon, and grouping).
It led to issues where you couldn't:
- add a help text horizontally
- add multiple icons or loaders in a group of controls
- add a different icon on addons
The solution
The new .field element becomes the block container for .control elements. As a result, it inherits the .has-addons, .is-grouped, and .is-horizontal modifiers.
Furthermore .control element can only contain a .button, .input, .select, or .textarea, and eventually a .icon. It can no longer contain a .help element or other .control.
But it allows more elaborate designs.
{% highlight sass %} // Before .control .has-addons .has-icon .is-grouped .is-horizontal .is-loading
// After .control .has-icon .is-loading .field .has-addons .is-grouped .is-horizontal .field-label .field-body {% endhighlight %}
{% highlight html %}
Username
This username is available
This username is available
Examples
Addons with multiple icons or states.
Horizontal form with help text
This email is correct