Why no custom CSS?

You're not gonna need it.

November 27, 2019

Formsort was built from the ground up to be flexible enough to accomodate most themes, branding, or designs that you see in form flows.

Why then, don't we support custom CSS? And why do we think you don't need it?

CSS is too low-level for most forms

CSS can let you do pretty much anything. But in the realm of forms, the specific style attributes are too low-level to let you build flows that look the way that you want without hitting the minefield of attendant corner cases and browser incompatibility issues.

It's much nicer to say something high-level like put the form in the middle of the page or I want my buttons to look like these rather than have to apply a bunch of CSS attributes and selectors just to get something looking decent.

The state-of-the-art changes often

Product forms, like signup flows and registrations, can live for years—and web browsers are evolving faster than ever, thanks to the adoption of auto-updates and the abandonment of non-standards-compliant browsers like Internet Explorer.

We're here for the long term, and don't want to be stuck to the best way of doing things today. We keep your flows rendering in the state-of-the-art far into the future by migrating approaches when they change.

Example: centering an element

While conceptually dead simple, implementing centering an element within another element has changed dramatically over the years.

Put me in the middle!


Back in the day, the <table> element was the only reliable way to lay out elements in rows. So you had to use table styling to center items.

<div style="display: table">
  <div style="display: table-cell; vertical-align: middle; text-align: center">


Tables as a container were too inflexible for the era of responsive design, so the box model started getting better - and <div> elements had better handling of margins. This approach works, as long as the inner content has a defined size:

<div style="position: relative;">
  <div style="margin: auto; position: absolute; top: 0; left: 0; right: 0; bottom: 0; width: 100px; height: 20px; text-align: center">

Absolute positioning

Then browser adoption of the transform property increased, and you could do things like the following instead that would work irrespective of the content size.

<div style="position: relative">
  <div style="position: absolute; left: 50%; top: 50%; transform: translate(-50%, -50%)">


The Flexbox model ushered in a new approach to layout entirely, and so centering became as simple as:

<div style="display: flex; justify-content: center; align-items: center">


Here in 2019, CSS Grid is the up-and-coming two-dimensional layout. This approach plays particularly well if you have other content within the container, as it defines regions and then you place the content within a region.

<div style="display: grid; justify-content: center; align-items: center">

Which approach is best?


There's no single answer that's correct today and will continue to be correct in the future.

That's why we'd rather not let your forms get stuck on the flavor of the day but instead let us keep your flows up to date with the latest.

Migrating CSS is error-prone

We're continually pushing updates to our code to fix bugs, add features, and improve performance. As part of maintaining the look and feel of our customer's forms, we often migrate existing styles into new formats so that we continue to iterate quickly.

Because of CSS's flexibility, it's almost impossible to migrate CSS that describes an old page layout to a new page layout.

While we could just pin existing forms to the particular code that existed at the time the form was initially published, we don't think this is an approach, as the benefits of the latest and greatest code far outweigh the costs of staying static in an ever-changing browser environment.

It's too easy to break things with CSS

Due to its low-level nature and the diversity of browser implementations, there are hundreds of little issues in forms that can be exacerbated by using CSS without considering the whole.

Example: mobile browsers faking hover events

Here's a button.

If we want to apply a background color when a user moves their mouse over the button, it's pretty straightforward in CSS:

button:hover {
  background-color: lightblue;


But what happens on mobile? You'd think that since there's no mouse, there'd be no hover state, so you'd be all good. But it turns out that so many websites are completely unusable without hover states on mobile phones (think: menus that only open on hover states), that many mobile browsers fake a hover event when you tap an element. That means that you'll get weird hovered element styles on a phone that don't make any sense, unless you use the CSS hover media selector to only apply the hover rule in browsers that actually support hover.

@media (hover: hover) {
  button:hover {
    background-color: blue

The twist is that the hover media query doesn't have good browser support yet, so you need to conditionally apply it depending on whether the user's browser even supports it. Not fun.

Now it works, supporting hover on desktop but not faking it on mobile:

While it's relatively low-hanging fruit, it's is just one of hundreds of pieces of low-hanging fruit that plague form user experience, from layout issues, to scroll positioning issues, through to loading fonts correctly.

Exposing custom CSS exposes you to hurting yourself if you aren't extremely careful.

The Formsort studio is expressive enough

You'll find that you can express the vast majority of the design ideas you can imagine directly within the Formsort Studio, without writing a single line of CSS.

  • hello@formsort.com
  • Jobs
  • Security
  • Formsort Inc
    © 2020