Working on a project where metadata defines a varying number of text inputs to display on a form, where the inputs must have a fixed width, and which must be responsive. Thought it would be simple with FUI’s form-field-input stack – but nope – and here’s why and my grid-based solution.
The requirement
The project requires construction of forms to capture filter values for a DB search. This is a repeated pattern, with a number of searches on different subjects which might have a different number of filter inputs per subject.
The way forward is to define the details of each search and its filters in metadata, then use this to generate the search forms. Need a new subject search – define the details in metadata – no code! But the issue has been how to make a responsive form displaying this varying number of inputs. Also I should mention that we’ve settled on having the inputs uniformly be of ‘four wide column’ size. Here’s the link to FUI’s forms docs in case you need it as we go along, and you can enjoy the full example of all of these approaches in the CodePen at the end of this article.
Lets take a look at the standard FUI approach to static forms layout.
The standard, static, form-fields-field-input approach
FUI uses a specific construction for side-by-side form inputs. First there is the ‘form’, a child ‘fields’, then a child ‘field’ and then its child ‘label’ and ‘input’, as shown below. The inclusion of the ‘fields’ element allows the individual ‘field’ elements to appear on the same line across the page – if you omit it the individual ‘field’ elements will stack.
<div class="ui form">
<div class="fields">
<div class="four wide field">
<label>Input #1</label>
<input type="text" placeholder="4 Wide">
</div>
...
So if you use that approach and add 5 inputs all set with class ‘four wide field’ you get what you see below. First point to note is that in wide-mode we can see there are five inputs. FUI uses a 16 column grid, and 5 x 4 = 20 so something is not right here. What is happening is that, because there is no built-in wrapping process for the ‘fields’ class, the inputs are compressed evenly to fit on the line. Remembering that the requirement is for a varying number of inputs, this is not viable for us. What if there are 7, or 12, or 15 inputs – clearly unworkable.
On the plus-side, this basic approach does benefit from the full-width switch when the viewport reaches mobile proportions. We’ll aim to ensure we get that behaviour in the end solution.
Let’s move on to look at the grid solution.
The grid-based approach
The FUI grid system (link to docs), like all others, divides horizontal space into indivisible units called “columns”. All columns in a grid must specify their width as proportion of the total available row width. All grid systems choose an arbitrary column count to allow per row. FUI’s default theme uses 16 columns.
FUI’s grid can contain ‘row’ elements. For our project, we could write code so that for every 4 inputs we need to display we generate another row. Whilst this is possible I want to keep any special code to a minimum so wondered if I could just declare a single row and rely on it’s wrapping abilities. What this produces is shown below. At least this respects the 16-column grid and wraps the fifth input. However, the vertical spacing for wrapped content is uneven.
Fortunately, the FUI grid also provides an automatic flow option which you get by leaving out the ‘row’ elements. This gives a more pleasing and event layout for the wrapped inputs as shown below.
All of the above approaches are illustrated in this CodePen.
Summary
We seem to have identified a means of meeting the defined requirement for laying out an unknown number of ‘four wide’ inputs whilst keeping consistent sizing, spacing and wrapping behaviours and without special code to generate row-breaks. I will now move on to utilising this technique in the project and report back on subsequent hurdles or issues.
Thanks for reading.
VW June 2020
Coding for the long view 