Brad points out some UX problems with a variety of apps that are doing things a little outside of the norm when it comes to their login forms. There is already a bunch of things to get right with forms to begin with (e.g. use the right input types, label your inputs, don’t have whack password requirements, use SSL, etc.)… OMG why complicate it even more?!
A “password manager test” should be a development best practice here. Does it work cleanly with the built-in browser password manager? How about 1Password and LastPass? No? Give it some love, please and thank you.
I love the idea of programmatically generated images. That power is close at hand these days for us front-end developers, thanks to the concept of headless browsers. Take Puppeteer, the library for controlling headless Chrome. Generating images from URLs is their default use case:
That ought to get the ol’ mind grape going. What if we had URLs on our site that — with the power of our HTML and CSS skills — created perfect little designs for sharing using dynamic data… then turned them into images and used them for our meta tags?
Since the design part is entirely an HTML/CSS adventure, I’m sure you could imagine a setup where the URL passed in parameters that did things like set copy and typography, colors, sizes, etc. Zeit built exactly that!
Kind of amazing that you can spin up an entire browser in a cloud function! Netlify also offers cloud functions, and when I mentioned this to Phil Hawksworth, he told me he was already doing this for his blog!
So on a blog post like this one, an image like this is automatically generated:
instant.page is a pretty cool project from Alexandre Dieulot. Alexandre has been at this idea for half a decade now, as InstantClick is his and is essentially the same exact idea.
The idea is that there is a significant delay between hovering over a link and clicking that link. Say it takes you 300ms of delay. That 300ms could have been spent preloading the next page. And if you do use that time preloading, that page loads that much faster.
This new project makes use of newer tech to get it done. It’s hardly any code., the core of which is appending a <link rel="prefetch" href=""> to the document of the link you’re about to click/touch.
The page encourages you to hotlink the script, which means possible cache-hits in case you’ve already visited a page using this. It’s not risky in the way other third-party JavaScript can be because the integrity attribute means that if you trust the code as it is now, it can’t ever change unless you change that attribute along with it. It also cleverly uses the type="module" to prevent it from loading anything in browsers that don’t support prefetching anyway.
Still, you could self-host it if you wanted. I have no idea who’s ponying up the for the bandwidth here, so another risk is a hung script should it stop responding one day.
You could argue that it doesn’t do the prefetching as absolutely responsibly as it could. Google’s similar quick link library (which we covered here) does two interesting things in which to attempt to be more responsible with prefetching: 1) wait for requestIdleCallback and 2) respects info from navigator.connection, like a user enabling data-saver mode.
CSS has a neat feature that allows us to test if the browser supports a particular property or property:value combination before applying a block of styles — like how a @media query matches when, say, the width of the browser window is narrower than some specified size and then the CSS within it takes effect. In the same spirit, the CSS inside this feature will take effect when the property:value pair being tested is supported in the current browser. That feature is called @supports and it looks like this:
Why? Well, that’s a bit tricky. Personally, I find don’t need it all that regularly. CSS has natural fallback mechanisms such that if the browser doesn’t understand a property:value combination, then it will ignore it and use something declared before it if there is anything, thanks to the cascade. Sometimes that can be used to deal with fallbacks and the end result is a bit less verbose. I’m certainly not a it’s-gotta-be-the-same-in-every-browser kinda guy, but I’m also not a write-elaborate-fallbacks-to-get-close kinda guy either. I generally prefer a situation where a natural failure of a property:value doesn’t do anything drastic to destroy functionality.
That said, @supports certainly has use cases! And as I found out while putting this post together, plenty of people use it for plenty of interesting situations.
A classic use case
The example I used in the intro is a classic one that you’ll see used in lots of writing about this topic. Here it is a bit more fleshed out:
/* We're gonna write a fallback up here in a minute */ @supports (display: grid) { .photo-layout { display: grid; grid-template-columns: repeat(auto-fill, minmax(200px, 1fr)); grid-gap: 2rem; } }
Nice grid! Repeating and auto-filling columns is a sweet feature of CSS grid. But, of course, there are browsers that don’t support grid, or don’t support all the specific features of it that I’m using above there.
For example, iOS shipped support for CSS grid in version 10.2, but iOS has had flexbox support since version 7. That’s a decent gap of people with older iOS devices that do support flexbox but not grid. I’m sure there are more example gaps like that, but you probably get the idea.
I was running on an older version of mobile safari and many many many many many sites were flat out broken that used grid
I’m waiting another year or so before messing about with it
It may be acceptable to let the fallback for this be nothing, depending on the requirements. For example, vertically stacked block-level elements rather than a multi-column grid layout. That’s often fine with me. But let’s say it’s not fine, like a photo gallery or something that absolutely needs to have some basic grid-like structure. In that case, starting with flexbox as the default and using @supports to apply grid features where they’re supported may work better…
The “fallback” is the code outside of the @supports block (the properties above the block in the example above), and the grid code is either inside or after. The @supports block doesn’t change any specificity, so we need the source order to help make sure the overrides work.
Notice I had to reset the margin on the divs inside the @supports block. That’s the kind of thing I find a bit annoying. There is just enough crossover between the two scenarios that it requires being super aware of how they impact each other.
Doesn’t that make you wish it could be entirely logically separated…
There is “not” logic in @supports blocks, but that doesn’t mean it should always be used
/* Considered a BAD PRACTICE, at least if you're supporting IE 11 and iOS 8 and older */ @supports not (display: grid) { /* Isolated code for non-support of grid */ } @supports (display: grid) { /* Isolated code for support of grid */ }
Notice the not operator in the first block. That’s checking for browsers that do not support grid in order to apply certain styles to those browsers. The reason this approach is considered bad practice is that the browser support for @supports itself has to be considered!. That’s what makes this so dang tricky.
It’s very appealing to write code in logically separated @supports blocks like that because then it’s starting from scratch each time and doesn’t need to be overriding previous values and dealing with those logical mind-benders. But let’s go back to the same iOS situation we considered before… @supports shipped in iOS in version 9 (right between when flexbox shipped in iOS 7 and grid shipped in iOS 10.2). That means any flexbox fallback code in a @supports block using the not operator to check for (display: grid) {} support wouldn’t work in either iOS 7 or 8, meaning the fallback now needs a fallback from working in browsers it otherwise would have. Phew!
The big reason to reach for @supports is to account for very different implementations of something depending on feature support where it becomes easier to reason and distinguish between those implementations if the blocks of code are separated.
We’ll probably get to a point where we can use mutually-exclusive blocks like that without worry. Speaking of which…
@supports is likely to be more useful over time.
Once @supports is supported in all browsers you need to support, then it’s good to start using it more aggressively and without having to factor in the complication of considering whether @supports itself is supported. Here’s the support grid on that:
This browser support data is from Caniuse, which has more detail. A number indicates that browser supports the feature at that version and up.
Desktop
Chrome
Opera
Firefox
IE
Edge
Safari
28
12.1
22
No
12
9
Mobile / Tablet
iOS Safari
Opera Mobile
Opera Mini
Android
Android Chrome
Android Firefox
9.0-9.2
46
all
4.4
71
64
Basically, IE 11 and any iOS device stuck on iOS 8 are the pain points. If your requirements are already past those, then you’re good to use @supports more freely.
The irony is that there hasn’t been a ton of CSS features shipping that have big clear @supports use cases — but there are some! Apparently, it’s possible to test new fancy stuff like Houdini:
Using it on my wedding website to check for Houdini support 🎩🐰
On some level, that makes perfect logical sense. If transforms are supported, use them. But it’s unnecessary if nothing different is happening in a non-support scenario. In this case, the transform can fail without the @supports block and the result is the same.
They are both centered around the idea that we can write @supports blocks in CSS and then toggle them on and off as if we’re looking at a rendering of the code in a browser that does or doesn’t support that feature.
Here’s a video of Keith’s tool applied to the scenario using grid with a flexbox fallback:
This is fun to play with and is very neat tech. But in this exact scenario, if I was able to pull off the layout identically with flexbox, then I’d probably just do that and save that little bit of technical debt.
Ire’s tool, which she wrote about in the article Creating The Feature Queries Manager DevTools Extension, has a slightly different approach in that it shows the feature queries that you actually wrote in your CSS and provides toggles to flip them on and off. I don’t think it works through iframes though, so I popped open Debug Mode to use it on CodePen.
@supports (transform: rotate(1turn)) and (opacity: 0) { /* all the styling for Erik's custom checkboxes and radio buttons */ }
Here are several more I’ve come across:
Joe Wright and Tiago Nunes mentioned using it for position: sticky;. I’d love to see a demo here! As in, where you go for position: sticky;, but then have to do something different besides let it fail for a non-supporting browser.
Keith Grant and Matthias Ott mention using it for object-fit: contain;. Matthias has a demo where positioning trickery is used to make an image sort of fill a container, which is then made easier and better through that property when it’s available.
Ryan Filler mentions using it for mix-blend-mode. His example sets more opacity on an element, but if mix-blend-mode is supported, it uses a bit less and that property which can have the effect of seeing through an element on its own.
Rik Schennink mentioned the backdrop-filter property. He says, “when it’s supported the opacity of the background color often needs some fine tuning.”
Nour Saud mentioned it can be used to detect Edge through a specific vendor-prefixed property: @supports (-ms-ime-align:auto) { }.
Amber Weinberg mentioned using it for clip-path because adjusting the sizing or padding of an element will accommodate when clipping is unavailable.
Ralph Holzmann mentioned using it to test for that “notch” stuff (environment variables).
Stacy Kvernmo mentioned using it for the variety of properties needed for drop capping characters. Jen Simmons mentions this use case in her article as well. There is an initial-letter CSS property that’s pretty fantastic for drop caps, but is used in conjunction with other properties that you may not want to apply at all if initial-letter isn’t supported (or if there’s a totally different fallback scenario).
Here’s a bonus one from Nick Colley that’s not @supports, but @media instead! The spirit is the same. It can prevent that “stuck” hover state on touch devices like this:
@supports (initial-letter: 4) and (transform: scale(2)) { }
Or:
@supports (initial-letter: 4) or (-webkit-initial-letter: 4) { }
Combos:
@supports ((display: -webkit-flex) or (display: -moz-flex) or (display: flex)) and (-webkit-appearance: caret) { }
JavaScript Variant
JavaScript has an API for this. To test if it exists…
if (window.CSS && window.CSS.supports) { // Apparently old Opera had a weird implementation, so you could also do: // !!((window.CSS && window.CSS.supports) || window.supportsCSS || false) }
To use it, either pass the property to it in one param and the value in another:
At the time of this writing, only Firefox supports this sort of testing (behind an experimental flag), but there is a way to test the support of selectors with @supports. MDN’s demo:
@supports selector(A > B) { }
You?
Of course, we’d love to see Pens of @supports use cases in the comments. So share ’em!
If you work on web applications that support older browsers, and have lusted after CSS Grid from the sidelines like I have, I have some good news: I’ve discovered a clever CSS-only way to use grid auto-placement in IE10+!
Now, it’s not actually CSS Grid, but without looking at the code itself, you wouldn’t be able to tell. The HTML structure looks like CSS Grid. It has a defined set of columns with an undefined amount of rows and it has gutters that support borders and shadows on the cells without hacks. But what’s actually happening behind the scenes is a combination of flexbox and margins.
In this article, I’ll walk through the approach. Here’s a demo of what we’re looking at:
Getting the basic grid setup is very simple. If you’re at all familiar with flexbox, I’m certain you’ve already guessed flex-wrap: wrap is the trick here. And you’d be right.
Let’s get the HTML markup in place before we write any CSS. We want it to resemble the same structure as if we were using auto-placement — a .grid container and an undefined number of .grid__cells.
We set three grid breakpoints. A single-column, two-column, and three-column layout for mobile-devices, small screens, and medium screens, respectively. I’m using the breakpoints used in Bootstrap for this article, though we’d want to define them at actual points where the layout breaks if we were working with real content.
A mobile-first approach means our single-column layout is already complete since each .grid__cell is already a block. We set .grid to become a flexbox container after the first breakpoint, and wrap cells.
Our two- and three-column layouts need explicit widths and flex properties; otherwise they’ll cram onto a single line. While testing IE10, I experienced unexpected behavior with the flex-basis property, and found setting an explicit width with flex-basis: auto was more consistent. This didn’t seem to be a problem with IE11 though.
We don’t need to wrap .grid__cell in a media query since its flex properties won’t have the effect when the parent isn’t a flexbox container. We also define an upper-limit to the two-column media query so it doesn’t affect the three-column grid.
And that’s it! We now have a responsive, fluid, wrapping flexbox grid. The easy part is done… well, as long as we only ever have items that are multiples of two and three. With flex: 1 1 auto, the last item will always take up any remaining space in the last row.
Two-column grid on smaller screensThree-column grid on large screens
Aligning cells in the last row
The elusive last row is why we’re here, right? By default, each cell will stretch to the end of the row in a flexbox layout, but grid leaves a blank spot. How do we do that in flexbox? With pseudo-elements!
The trick is to add a pseudo-element to the .grid container and set it like a cell. We define the :after pseudo-element cell at each of our breakpoints with the same width as a real cell.
This creates a fake cell that will push against our real cells and align our two-column grid when the cells are odd. Leaving its height undefined allows it to collapse to nothing when the cells are even.
Two-column grid with odd cells, snapping into place
Our three-column grid is a bit more complex because we need to handle multiple states, like when there is one empty cell and when there are two empty cells.
Three-column grid with one empty cell
Our one empty cell state is already handled because it isn’t really any different from one empty cell in two columns. The :after cell has its width set and completes the row. The story changes when there are two empty cells though because flex: 1 1 auto rears its head again: the last cell now stretches across 50% of the width when pushed against the pseudo-element.
Three-column grid with two empty cells
Using CSS :nth-of-type selectors, we can target the first column in each row. Since our rows are multiples of three, we target them with 3n then count backwards by 2 to get the first element in each row.
We’re broadly targeting all the cells in the first column, but we need to limit the selection to only the last row. Actually, we need to limit it to when it’s the last cell in the first column of the last row. Luckily, there’s a handy pseudo-selector for targeting the last item of its kind. We chain :last-of-type to create the logical statement.
Now that we have the last cell in the first column of the last row selected, we use a margin to push the :after cell to the last column and fill the middle cell.
Here’s our flexbox-defined-auto-placement-grid-imitator in full. Look at its beautifully lined up rows. I bet you can’t even tell it’s not CSS Grid!
Our complete three-column grid.
Adding gutters with margins
CSS Grid’s spec has a column and row gap to provide space between each cell. Creating gutters in flexbox is much more challenging. It looks like it’s coming to flexbox, but we’re not there yet…and IE will never be.
In Daniel Tonon’s guide on CSS Grid in IE, he used an inner-cell div with negative margins, borders, a bit of padding, and overflow: hidden. While maybe a bit hacky, the effect works, but it breaks our desire to maintain CSS Grid-like HTML structure. The approach I prefer might feel a bit crude, but I also found it the easiest to read and understand. Further, it continues using :nth-of-type pseudo-selectors which makes the overall approach feel consistent.
We want gaps between the cells, but not around the outside. We also want our cells to sit flush with the container.
Gaps between the cells, not on the outside.
Our mobile or single-column grid only needs a bottom margin on the cells. We add that and override the very last cell with margin-bottom: 0 so the cell fits flush against the container. Normally I’d use initial, but there’s no support in IE.
Our two- and three-column grids need margins on the right of the cells, no right margins in the last column, and no bottom margins on any of the last row’s cells. Because of the margins, we’ll also need to recalculate our widths since the cells will wrap if they don’t fit.
In a two-column layout, getting the right (or second) column is fairly easy with :nth-of-type(2n) or :nth-of-type(even). I prefer an n-multiplier for consistency with our three-column grid and for calculating the last row.
Our last row is a bit more tricky. When we have odd cells our mobile-first CSS takes care of removing the bottom margins since the cell is the :last-of-type and our :after cell doesn’t have margins applied.
Two-columns with even cells
When we have even cells we need to target the second last cell, but only when it is in the first column position. If we didn’t qualify it, the second last cell will grow vertically with to match the height of the second last row. We can target it with :nth-of-type(2n-1):nth-last-of-type(2).
@media (min-width: $ screen-sm-min) and (max-width: $ screen-sm-max) { $ width: calc(50% - #{$ col-gap}); .grid__cell { ... margin-right: $ col-gap; // Remove margin in last column &:nth-of-type(2n) { margin-right: 0; } // For when the last row is complete // . . // * . &:nth-of-type(2n-1):nth-last-of-type(2) { margin-bottom: 0; } } }
Two-columns with even cells that sit flush against the container
Our three-column gutters take the same approach. We add margin-right to all of them, remove it from the third column, and remove bottom margins from the last row. Again our last cell is handled by our mobile-first approach, but now we need to cover when there are two cells in the last row and when when there are three cells. We can qualify our selectors with nth-of-type and nth-last-of-type.
@media (min-width: $ screen-md-min) { $ width: calc(33% - #{$ col-gap}); .grid__cell { ... margin-right: $ col-gap; // Remove margin in last column &:nth-of-type(3n) { margin-right: 0; } // For when there two items in the last row // . . . // * . &:nth-of-type(3n-2):nth-last-of-type(2) { margin-bottom: 0; } // For when the last row is complete // . . . // * * . &:nth-of-type(3n-1):nth-last-of-type(2), &:nth-of-type(3n-2):nth-last-of-type(3) { margin-bottom: 0; } } }
Three-column grid with gutters and an empty cell
We need to adjust the margin of last cell in the last row when it’s alone because of the columns. We use 33% plus a gutter on each side.
@media (min-width: $ screen-md-min) { $ width: calc(33% - #{$ col-gap}); .grid__cell { ... // When there is only one item in the last rpw // Fill the margin so it's like the last item is // double the width // . . . // *-> &:nth-of-type(3n-2):last-of-type { margin-right: calc(33% + #{$ col-gap * 2}); } } }
Now our gutters are installed and the grid is complete! Fill them borders, shadows, or whatever your heart desires.
Complete three-column grid with gutters using flexbox.
I believe this technique could also support IE9 with minor adjustments, like using inline-blocks instead of flexbox. We could also expand to a four-column grid by adding another breakpoint and using the same approach as the three-column grid. Feel free to use this approach and I hope it helps!
You know about the State of JavaScript survey, where thousands upon thousands of developers were surveyed about all-things-JS, from frameworks to testing and many other things in between? Well, Sacha Greif has launched one focused entirely on CSS.
This is super timely given a lot of the content we and other sites have been posting lately centered around learning, complexity, changing roles, and more. Sacha captures it nicely:
This is especially interesting since it comes at a time where many are talking about a “Great Divide” between the “front” of the front-end (HTML, CSS) and the “back” of the front-end (JavaScript and its many frameworks and libraries). […] [T]he survey will be a great chance to take a snapshot of the community as it currently exists, and see how this evolves over the next couple years.
Sounds like a good goal. Let’s help by putting some responses in there!
One way to deal with long, complex forms is to break them up into multiple steps. You know, answer one set of questions, move on to another, then maybe another, and so on and so forth. We often refer to these as multi-step forms (for obvious reasons), but others also take to calling it a “wizard” form.
Multi-step forms can be a great idea! By only showing a few inputs on a screen at a time, the form may feel more digestible and prevent users from feeling overwhelmed by a sea of form fields. Although I haven’t looked it up, I’m willing to say no one enjoys completing a ginormous form — that’s where multiple steps can come in handy.
The problem is that multi-step forms — while reducing perceived complexity on the front end — can feel complex and overwhelming to develop. But, I’m here to tell you that it’s not only achievable, but relatively straightforward using React as the base. So, that’s what we’re going to build together today!
The easiest way to create a multi-step form is to create a container form element that contains all the steps inside of it as components. Here’s a visual showing that container (<MasterForm/>), the components inside of it (<Step1/>, <Step2/>, <Step3/>) and the way states and props are passed between them.
<MasterForm/> serves as the container while three child components inside of it act as each step of the form.
Although it seems to be more complex than a regular form, a multi-step form still uses the same principles as a React form:
State is used for storing data and user inputs.
Component is used for writing methods and the interface.
Props are used for passing data and function into elements.
Instead of having one form component, we will have one parent component and three child components. In the diagram above, <MasterForm/> will send data and functions to the child components via props, and in turn, the child components will trigger a handleChange() function to set values in the state of <MasterForm/>. It’s one big happy family over here!
We’ll need a function to move the form from one step to another as well, and we’ll get to that a little later.
The step child (get it?) components will receive props from the <MasterForm/> parent component for value and onChange props.
<Step1/> component will render an email address input
<Step2/> will render a username input
<Step3/> will render a password input and a submit button
<MasterForm/> will supply both data and function into child components, and child components will pass user inputs back to the parent using its props.
Creating the step (child) components
First, we’ll create the form’s child components. We’re keeping things pretty barebones for this example by only using one input per step, but each step could really be as complex as we’d like. Since the child components look almost similar between one another, I’m just gonna show one of them here. But be sure to take a look at the demo for the full code.
class Step1 extends React.Component { render() { if (this.props.currentStep !== 1) { // Prop: The current step return null } // The markup for the Step 1 UI return( <div className="form-group"> <label htmlFor="email">Email address</label> <input className="form-control" id="email" name="email" type="text" placeholder="Enter email" value={this.props.email} // Prop: The email input data onChange={this.props.handleChange} // Prop: Puts data into state /> </div> ) } }
Now we can put this child component into the form’s render() function and pass in the necessary props. Just like in React’s form documentation, we can still use handleChange() to put the user’s submitted data into state with setState(). A handleSubmit() function will run on form submit.
Next up, the parent component
Let’s make the parent component — which we’re all aware by now, we’re calling <MasterForm/> — and initialize its state and methods.
We’re using a currentStep state that will be initialized with a default value of 1, indicating the first step (<Step1/>) of the form. We’ll update the state as the form progresses to indicate the current step.
class MasterForm extends Component { constructor(props) { super(props) // Set the initial input values this.state = { currentStep: 1, // Default is Step 1 email: '', username: '', password: '', } // Bind the submission to handleChange() this.handleChange = this.handleChange.bind(this) } // Use the submitted data to set the state handleChange(event) { const {name, value} = event.target this.setState({ [name]: value }) } // Trigger an alert on form submission handleSubmit = (event) => { event.preventDefault() const { email, username, password } = this.state alert(`Your registration detail: n Email: $ {email} n Username: $ {username} n Password: $ {password}`) } // Render UI will go here... }
OK, that’s the baseline functionality we’re looking for. Next, we want to create the shell UI for the actual form add call the child components in it, including the required state props that will be passed from <MasterForm/> via handleChange().
render() { return ( <React.Fragment> <h1>A Wizard Form!</h1> <p>Step {this.state.currentStep} </p> <form onSubmit={this.handleSubmit}> // Render the form steps and pass in the required props <Step1 currentStep={this.state.currentStep} handleChange={this.handleChange} email={this.state.email} /> <Step2 currentStep={this.state.currentStep} handleChange={this.handleChange} username={this.state.username} /> <Step3 currentStep={this.state.currentStep} handleChange={this.handleChange} password={this.state.password} /> </form> </React.Fragment> ) }
One step at a time
So far, we’ve allowed users to fill the form fields, but we’ve provided no actual way to proceed to the next step or head back to the previous one. That calls for next and previous functions that check if the current step has a previous or next step; and if it does, push the currentStep prop up or down accordingly.
class MasterForm extends Component { constructor(props) { super(props) // Bind new functions for next and previous this._next = this._next.bind(this) this._prev = this._prev.bind(this) } // Test current step with ternary // _next and _previous functions will be called on button click _next() { let currentStep = this.state.currentStep // If the current step is 1 or 2, then add one on "next" button click currentStep = currentStep >= 2? 3: currentStep + 1 this.setState({ currentStep: currentStep }) } _prev() { let currentStep = this.state.currentStep // If the current step is 2 or 3, then subtract one on "previous" button click currentStep = currentStep <= 1? 1: currentStep - 1 this.setState({ currentStep: currentStep }) } }
We’ll use a get function that will check whether the current step is 1 or 3. This is because we have three-step form. Of course, we can change these checks as more steps are added to the form. We also want to display the next and previous buttons only if there actually are next and previous steps to navigate to, respectively.
// The "next" and "previous" button functions get previousButton(){ let currentStep = this.state.currentStep; // If the current step is not 1, then render the "previous" button if(currentStep !==1){ return ( <button className="btn btn-secondary" type="button" onClick={this._prev}> Previous </button> ) } // ...else return nothing return null; } get nextButton(){ let currentStep = this.state.currentStep; // If the current step is not 3, then render the "next" button if(currentStep <3){ return ( <button className="btn btn-primary float-right" type="button" onClick={this._next}> Next </button> ) } // ...else render nothing return null; }
All that’s left is to render those buttons:
// Render "next" and "previous" buttons render(){ return( <form onSubmit={this.handleSubmit}> {/* ... other codes */} {this.previousButton} {this.nextButton} </form> ) }
Congrats, you’re a form wizard! 🧙
That was the last step in this multi-step tutorial on multi-step forms. Whoa, how meta! While we didn’t go deep into styling, hopefully this gives you a solid overview of how to go about making complex forms less… complex!
Here’s that final demo again so you can see all the code in it’s full and glorious context:
React was made for this sort of thing considering it makes use of states, property changes, reusable components and such. I know that React may seem like a high barrier to entry for some folks, but I’ve written a book that makes it a much lower hurdle. I hope you check it out!
We’ve talked quite a bit about project management and workflows around here at CSS-Tricks, not because it’s the core of what we do as designers and developers, but because we all play a role in it as part of a team and because it impacts the quality of our work at the end of the day.
That’s why having a good system in place is such a benefit both to us and to teams as a whole. Where can you find a system like that? You might want to start by looking at monday.com. Yes, it’s a project management tool but it actually goes way beyond that. Where some other platforms out there stop at task lists, calendars, and milestones, monday.com does those plus team collaboration.
If you’ve ever felt out of the loop on a project, had a surprise change in scope, or even been curious what other folks on your team have been up to, that’s where monday.com really shines. It’s people-centric, giving you and others insight into activity across an entire project through news feeds, messaging, shared assets, clearly defined user roles, among any other things. It’s what a healthy, transparent, and collaborative team environment looks like.
We’ve only scratched the surface here, but lucky for you, there’s a free 14-day trial to check out everything that monday.com has to offer. Go for it!
