Post pobrano z: Boilerform: A Follow-Up
When Chris wrote his idea for a Boilerform, I had already been thinking about starting a new project. I’d just decided to put my front-end boilerplate to bed, and wanted something new to think about. Chris’ idea struck a chord with me immediately, so I got enthusiastically involved in the comments like an excitable puppy. That excitement led me to go ahead and build out the initial version of Boilerform, which you can check out here.
The reason for my initial excitement was that I have a guilty pleasure for forms. In various jobs, I’ve worked with forms at a pretty intense level and have learned a lot about them. This has ranged from building dynamic form builders to high-level spam protection for a Harley-Davidson® website platform. Each different project has given me a look at the front-end and back-end of the process. Each of these projects has also picked away at my tolerance for quick, lazy implementations of forms, because I’ve seen the drastic implementations of this at scale.
But hey, we’re not bad people. Forms are a nightmare to work with. Although better now: each browser treats them slightly differently. For example, check out these select menus from a selection of browsers and OSs. Not one of them looks the same.
Because of these inconsistencies, it’s easy to see why developers bail out of digging too deep or just spin up a copy of Bootstrap and be done with it. Also, in my experience, the design of minor forms, such as a contact form are left until later in the project when most of the positive momentum has already gone. I’ve even been guilty of building contact forms a day before a website’s launch. 😬
There’s clearly an opportunity to make the process of working with forms—on the front-end, at least—better and I couldn’t resist the temptation to make it!
The Planning
I sat and thought about what pain-points there are when working with forms and what annoys me as a user of forms. I decided that as a developer, I hate styling forms. As a user, poorly implemented form fields annoy me.
An example of the latter is email fields. Now, if you try to fill in an email field on an iOS device, you get that annoying trait of the first letter being capitalized by the browser, because it treats it like a sentence. All you have to do to stop that behaviour is add autocapitalize="none" to your field and this stops. I know this isn’t commonly known because I rarely see it in place, but it’s such a quick win to have a positive impact on your users.
I wanted to bake these little tricks right into Boilerform to help developers make a user’s life easier. Creating a front-end boilerplate or framework is about so much more than styling and aesthetics. It’s about sharing your gained experience with others to make the landscape better as a whole.
The Specification
I needed to think about what I wanted Boilerform to do as a minimum viable product, at initial launch. I came up with the following rules:
- It had to be compatible with most front-ends
- It had to be well documented
- It had to be lightweight
- Someone should be able to drop a CDN link to their
<head>and have it just work - Someone should also be able to expand on the source for their own projects
- It shouldn’t be too opinionated
To achieve these points, I had some technology decisions to make. I decided to go for a low barrier-to-entry setup. This was:
- Sass powered CSS
- BEM
- Plain ol’ HTML
- A basic compilation setup
I also focused my attention on samples. CodePen was the natural fit for this because they embed really well. Users can also fork them and play with them themselves.
The last decision was to roll out a pattern library to break up components into little pieces. This helped me in a couple of ways. It helped with organization mainly—but it also helped me build Boilerform in a bitty, sporadic nature as I was working on it in the evenings.
I had my plan and my stack, so got cracking.
Keeping it simple
It’s easy for a project like this to get out of hand, so it’s useful to create some points about what Boilerform will be and also what it won’t be.
What Boilerform will be:
- It’ll always be a boilerplate to get you off to a good start with your project
- It’ll provide high-level help with HTML, CSS and JavaScript to make both developers’ and users’ lives easier
- It’ll aim to be super lightweight, so it doesn’t become a heavy burden
- It’ll offer configurable options that make it flexible and easy to mould into most web projects
What Boilerform won’t be:
- It won’t be a silver bullet for your forms—it’ll still need some work
- It won’t be a framework like Bootstrap or Foundation, because it’ll always be a starting point
- It won’t be overly opinionated with its CSS and JavaScript
- It’ll never be aimed at one particular framework or web technology
The Specifics
I know y’all like to dive in to the specifics of how things work, so let me give you a whistle-stop tour!
Namespacing the CSS
The first thing I got sorted was namespacing. I’ve worked on a multitude of different sites and setups and they all share something when it comes to CSS: conflicts. With this in mind, I wrote a @mixin that wrapped all the CSS in a .boilerform namespace.
// Source Sass
.c-button {
@include namespace() {
background: gray;
}
}
// This compiles to this with Sass:
.boilerform .c-button { background: gray; }The mixin is basic right now, but it gives us flexibility to scale. If we wanted to make the namespacing optional down-the-line, we only have to update this mixin. I love that sort of modularity.
Right now, what it does give us is safety. Nothing leaks out of Boilerform and hopefully, whatever leaks in will be handled by the namespaced resets and rules.
BEM With a Garnish of Prefixes
I love BEM. It’s been core to my CSS and markup for a few years now. One thing I love about BEM is that it helps you build small, encapsulated components. This is perfect for a project like Boilerform.
I could probably target naked elements safely because of the namespacing, but BEM is about more than just putting classes on everything. It gives me and others the freedom to write whatever markup structure we want. It’s also really easy for someone to pickup the code and understand what’s related to what, in both HTML and CSS.
Another thing I added to this setup was a component prefix. Instead of an .input-field component, we’ve got a .c-input-field component. I hope little things like that will help a new contributor see what’s a component right off the bat.
Horror Inputs Get Some Cool Styling
As mentioned above, select menus are awful to style. So are radio buttons and checkboxes.
A trick I’ve been using for a while now is abstracting the styling to other friendlier HTML elements. For example, with <select> elements, I wrap them in a .c-select-field component and use siblings to add a consistent caret.
For checkboxes and radio buttons, I visually-hide the main input and use adjacent <label> elements to display state change. Using this approach makes working with these controls so much easier. Importantly, we maintain accessibility and native events too.
Base Attributes to Make Fields Easier to Use
I touched on it above with my example about email fields and capitalization, but that wasn’t the only addition of useful attributes.
- Search fields have
autocorrect="off"on them to prevent browsers trying to fix spelling. I strongly recommend that you add this to inputs that a user inserts their name into as well. - Number fields have
min,maxandstepattributes set to help with validation. It’s also great for keyboard users. - All fields have blank
nameandidattributes to hopefully speed up the wiring-up process
I’m certainly keen for this to be expanded on, because little tweaks like this are great for user experience.
Going Forward. Can You Help?
Boilerform is in a good place right now, but it has real potential to be useful. Some ideas I’ve had for its ongoing development are:
- Introducing multiple JavaScript library integrations, such as React, Vue, and Angular
- Create some base form layouts in the pattern library
- Create Sass mixins for styling pesky stuff like placeholders
- Improve configurability
- Add new elements such as the range input
- Create multilingual documentation
As you can see, that’s a lot of work, so it would be awesome if we can get some contributors into the project to make something truly useful for our community. Pulling in contributors with different areas of expertise and backgrounds will help us make it useful for as many people as possible, from end-users to back-end developers.
Let’s make something great together. 🙂
Check out the project site or the GitHub repository.
Boilerform: A Follow-Up is a post from CSS-Tricks
