Create Reset Styles to Normalize Form Fields Cross-Browser

Share this video with your friends

Social Share Links

Send Tweet
Published 3 years ago
Updated 3 years ago

Learn how to begin addressing browser inconsistencies by resetting base styles across text inputs, textareas, and selects. We'll also review a few quirks related to mobile browsers and responsive design when dealing with form fields. And we'll uncover how to normalize <select> which was formerly one of the trickiest fields but is vastly easier now thanks to modern CSS through the appearance property.

Instructor: [0:00] Here is our current progress across Chrome, Firefox, and Safari on creating our form-field HTML. As you can see, there's definitely variances in the appearance of the form-field types. As example, Chrome has a strong border on the text inputs, and all of the browsers have quite different appearances for the select fields and multiple selects.

[0:24] The goal of this lesson is to add a style reset to essentially make all of these fields look the same in terms of their box model properties. To get started with this, we'll add a new Sass file and we'll name it form-reset. Currently, this project includes no outside resets. The only one we're going to bring into this project is to ensure that the box-sizing model used is border-box.

[0:51] What this means is that properties such as padding, and border will not change the computer dimensions for the elements box-sizing. Following that, since we have added the class of form-field to our text inputs and the wrapping div around our selects, we will use that to scope the rest of our styles.

[1:10] The first series of properties we can add are to affect the basic box model. We'll add a background-color, bring into alignment the border, and also add a slight border-radius, which we had created a variable for that value, and also define some padding. Before we can see that reflected on the page, we do need to import this new file into our styles.

[1:34] We're going to add this prior to the form-group. That way, as we continue to add field specific styles, if needed, they will override properties we set in our reset. Upon save of that, you can see those essential box properties have been applied. Looking at those across browsers we're already making some progress.

[1:53] One other item that we can't quite see without interacting with the field is that there's a variance in how these inputs apply font-size and even font-family. For our next set of properties, we would like to inherit the font-family and the color. This will take from the root, unless you specifically define something for the form-field itself.

[2:14] With that in place, we can see it has inherited our Roboto font and also, a little bit harder to see, but it is now that blue color that we have set on the body. There's one attribute that you can see has a discrepancy, which is the font-size itself.

[2:29] While generally we want to set font-sizes in rem, there's a particular issue on mobile iOS, where if the field text is not at least 16 pixels, it will cause a zoom into the field, which may not be desirable as it can remove the label out of the viewport.

[2:48] To prevent this bug from happening, we'll first set a fallback font-size of 16px. Then, we'll use a newer, modern CSS property called max, which will set the max value of either 16px or 1em. In other words, if 1em would compute to less than 16px, 16px would be used as the font-size as the max of those values.

[3:12] As the note says, since we are using Sass, and Sass includes a Max function, we are capitalizing it in this case to ensure that it remains in the complied setup styles in order to use the native CSS property. On save, you'll see that our inputs have changed size to match that new font-size property.

[3:30] Another thing that may be a little bit difficult to notice is that the length of the text inputs and text areas is not consistent across browsers. Over here on Safari you will see that the text inputs are a bit longer than the text areas.

[3:45] Before we go setting a particular width, we want to ensure that the fields are responsive to any container they are placed within. First, we'll set a max-width of 100%. We also want to prepare our styles for the possibility of utility styles changing the field width in the future.

[4:02] We will set a local, custom property of form-field-width. We'll set this initially to 30ch. Placing this custom variable within the form-field rule means it is scoped exclusively to this class. Then we'll set our width property using that variable but ensuring that we include a fallback. We'll just manually add that as 30ch. On save you see across our browsers we now have a consistent width across the text inputs.

[4:30] The last item for our core form-field styles is to set an explicit height on text inputs. We want this height to only effect single line text inputs not text areas and also not selects. In order to do this, because our form-field class wraps the native select, we need to, at this point, add an extra class on the multiple selects because we want to allow them to grow beyond a single line worth of height.

[5:00] In our selects, for each multiple select alongside the class and form-field we'll add the class select --multiple. The -- is due to a preference of using the BEM style naming convention where -- signifies a modifier. We'll also be sure to add it to our disabled multi-select.

[5:21] Now that we have a class that helps us know the difference between a regular form-field and one that happens to wrapping a multi-select, we can make use of the not selector and ensure that the explicit height is only applied when the form-field is not a text area and not a select multiple. On save, we see that our text inputs and our non-multi-select have a consistent height.

[5:47] Of course, the last standout item is the native selects themselves. Here I'm still within the form-field class, since we're in Sass, I'm going to use the parent selector and attach this next set of styles to the select native element.

[6:05] The first series of styles that we want to add here are to further remove the box properties stylings from the native select. Most of these will look pretty familiar. The one that is possibly new to you is the appearance property. This is a unique modern property that serves as a one-stop reset of a significant amount of CSS properties. It is applied differently depending on the element that it is used for.

[6:33] In the case of the select, the key thing it will remove is the dropdown arrow. On save, when we look back at our three browsers, the native select has essentially disappeared within that wrapper of the form-field.

[6:45] One thing to note here is that in our build process, we are including autoprefixer, and the appearance property does require prefixing across some browsers. To ensure compatibility of your styles, it is recommended to keep autoprefixer in your process.

[7:01] If we try to interact with the select, we'll see there are still a few properties that we can adjust. You'll see the width between these is still different, and we'd like to span it the whole width. We can quickly take care of that by simply width: 100%. We'll test it here in Chrome. We can see that it goes edge to edge minus the padding been applied on the form-field.

[7:23] When we modified the font properties of the inputs in text areas, those were directly attached to those native elements, but now we need to reapply the same idea to the select specifically. Once again, inherent properties for font-family and size, color, we'll also add cursor into the mix as well as line-height.

[7:42] I'll add a bit of text as comparison, but you'll see that now the visible options within the selects have inherited our blue color and updated their font-family to Roboto and font-size as well. We will be fixing the alignment of the native select within the form-field once we get to the complete custom styling of our select.

[8:02] The last thing to note is that if you do have to support older versions of Edge and IE, the appearance: none won't quite do the trick of removing the dropdown arrow. For that, we'll attach to the specific vendor property of ::-ms-expand and add display: none to that.

[8:19] If we interact with our selects, you'll see that we do get that focus halo. For now, we're also going to reset that by removing it. That's another item we'll be addressing when we do the complete custom select styling. As our last rule here, we'll set outline: none.

[8:35] In summary, our form-reset provided equalization of box model properties across our form fields, as well as font properties. We learned how to remove native select styling with the appearance property, and we learned the power of setting a variety of properties to inherit, to help reset the default browser styles.

[8:56] The result is that all of our fields have a consistent styling that we're ready to further customize in our future lessons.

egghead
egghead
~ 9 minutes ago

Member comments are a way for members to communicate, interact, and ask questions about a lesson.

The instructor or someone from the community might respond to your question Here are a few basic guidelines to commenting on egghead.io

Be on-Topic

Comments are for discussing a lesson. If you're having a general issue with the website functionality, please contact us at support@egghead.io.

Avoid meta-discussion

  • This was great!
  • This was horrible!
  • I didn't like this because it didn't match my skill level.
  • +1 It will likely be deleted as spam.

Code Problems?

Should be accompanied by code! Codesandbox or Stackblitz provide a way to share code and discuss it in context

Details and Context

Vague question? Vague answer. Any details and context you can provide will lure more interesting answers!

Markdown supported.
Become a member to join the discussionEnroll Today