I recently did a chunk of work on the Pulsar design system to improve how we align form elements against a common 12 column grid, and all sorts of fun little things crept out of the woodwork that we’re still tweaking.Normally, when you’re styling up your forms you’d add padding to both the left and right sides, right? It’s pretty much standard practice everywhere.
Previously, we used specific pixel values to set the widths of our inputs which—while great from a consistency point of view—was awful in terms of responsiveness. We worked out a responsive 12 column grid, three of which would be our main form labels, and the remaining 9 made available to form inputs, with the default being set to 4 columns wide.
When we used pixel widths, our inputs were designed with internal padding on both the left and right edges, which was fine when we could rely on a developer choosing the most appropriate width class, like
.form__group--small to suit their expected input widths.
However, that padding caused us a problem when we allowed form inputs to be completely responsive, growing and shrinking based on the widths of the responsive columns, depending on the width of the
value there’s a chance that when the text overflows, the right hand padding hides the fact that the value is overflowing.
Luckily, we’re able to fix this easily by removing the right hand padding, allowing the value to extend right to the edge of the input. If, at some point, we add RTL language support to our software then we’ll need to remove the left instead.
It’s not as visually pleasing, but it makes it much more obvious that the value extends beyond the visual container and does as much as we can to remove ambiguity and the opportunity for error.