Providing a Front-End API for Form Design
As a website grows, form design can rapidly become a convoluted process of CSS hacks and overwrites. Building a scalable, object-oriented framework from the beginning provides developers and authors a simple API for building their own forms that adhere to style guidelines and development guidelines.
There are a lot of advantages with crafting logical, object-oriented CSS, but few are as powerful as the ability to provide a plug-and-play API to writers and developers.
The concept is similar to a programmatic API. Through class names, design options and functionality extensions are exposed to the page author, providing an arsenal of sanctioned toggles they can flip on and off to control how a widget is displayed and operates on their page. This includes colors, width/height, sub-element positioning, animations, even interactive functionality.
The API can be set at the page level, but is most useful on the “block” level: that is, a chunk of something that needs special attention. The easiest example would be forms, but tables and video/audio components are also candidates.
Macro Options for Forms
Styling forms is never an insignificant amount of work. When a large site accumulates forms in different positions with different fields doing different things (subscriptions, support, lead generation, surveys, yada yada), the tightly wound CSS you crafted for your prototype unravels into a bramble of barbed wire as custom style upon custom style is thrown on top.
Content developers are a finicky bunch. They want options. They should have options. By building our forms API from the ground up, we can “expose” a core set of premeditated options to avoid later importanting all the things. Global form options might include:
- Form color
[options: color-white, color-red, color-blue, color-green; default: color-white]
- Form width
[options: any grid class (i.e. c7, c10, c12); default: 100%]
- Label positioning
[options: labels-top, labels-left, labels-inline; default: labels-top]
- Submit functionality
[options: traditional post to URL, submit-ajax; default: traditional post to URL]
So calling a form with no explicit options called out would produce a “default” design — 100% width, labels on top, plain background — where data would be posted to a URL old school style:
And this HTML would produce a form six grid columns wide, with a blue motif, with labels inline to the fields:
This flexibility gives developers and content authors the flexibility to dictate form design within an established pattern without breaking broader style standards and without getting hands dirty in code.
Micro Options for Forms
But what about more discrete options, like controlling highly specific form types? Survey questions that require a numbered rating system are a good example: they require unique styles, but still need to be easily implemented. We extend the API downward from macro form options to group-level options.
We’ll wrap a
fieldset with a class of “numbered-questions” to explicitly define proper formatting for the
<ol> element. Underneath that, we’ll establish options for each question. Since these are survey questions, we want to allow a rating scale of one to three, or one to five, or one to ten.
- Scale length
[options: one2three, one2five, one2ten; default: none]
In summary: We have a form running full width with a blue background. Inside is fieldset wrapping a series of survey questions. We change the color, dictate the questions should be numbered, announce that the radio buttons should be styled as a survey, and that the rating goes from one to five. Something like this:
The true advantage of this approach lies in the modularity of the rules. We can mix and match colors and layout types as well as blend in more specialized options like survey questions. Example:
We’re extending the semantic value of the
fieldset tag beyond content (that is, the logical clustering of input fields) into the visual presentation.
By approaching complicated CSS projects like forms as modular frameworks that invite usage rather than opaque, inextensible monoliths that can’t budge without complicated workarounds, developers — both of the content type and of the code type — are more likely to play by the rules. This brings faster development, less hacks, less code bloat, and stronger allegiance to visual brand standards.