Let's add a key missing element to our form design system - the submit button! Learn how to reset browser styles, and use our theme system to create accessible styles across :hover
, :focus
, and :disabled
states.
Instructor: [0:00] Our completed form field visual styles are looking pretty good, but we're missing a key element for forms, which is a submit button. Let's create a new include for button.njk, and we'll go ahead and comment out our other includes and swap it for the New button, just like our form fields.
[0:22] We're going to go ahead and wrap our button, with the class of form group, which applied some layout spacing to keep it consistent with the rest of our form. Now, the most appropriate element here is the actual button element. We'll give it a value of submit. Then, we'll explicitly type it as the type of submit. You'll see that is now appearing on the page. We'll also go ahead and give it a class of Form button.
[0:47] We're going to want to style a disabled version as well, so we'll duplicate this and add the disabled property, or we can do a quick check over at our various browsers of Chrome, Firefox, and Safari, and see how much these button styles differ between browsers.
[1:04] The first step we'll do is to reset the native styles. In our existing form reset stylesheet, we'll add our form button class, and we'll do a reset of the essential native styles, including border, background color, inheriting of our font family, explicitly setting a font size, removing the default padding, and adding a cursor of pointer.
[1:26] Our reset has successfully reduced all the styles to the same unstyled look across browsers. While we're here, since we'll remove the border, we want to ensure that the button remains visible for users of Windows high contrast mode, which swaps out our applied colors for reduced palette.
[1:44] We also were sensitive to this condition for our focus mixin, where we use the specialized media query that attaches to Microsoft high contrast mode and adds a two-pixel solid border using current color, which means it will pick up the applied color given to it in that mode.
[2:02] Now that our reset is complete, we can create our form button Sass style sheet. Here, we'll begin our form button class. The first thing we'll do is apply display properties. We're going to choose Flex in this instance. This will make our buttons more flexible for alternative variations that may decide to add things like icons.
[2:21] Then we'll add our visual stylings, including a background color, color, border radius, and padding. In order to check that process, we need to import our new stylesheet into our main Sass file. We need to add a couple extra size properties. First, we'll add a minWidth of 10ch. As a reminder, ch is roughly equivalent to the zero character in the applied font. We're also adding a minimum height of 44 pixels, which is based on the Wick Ed recommendation for touch target sizes.
[2:53] Then, to future proof our button, we'll add text-align center, so that any wrapping that occurs ensures the text is center aligned, and we'll add a line height of one, which resolves potential issues in exact centering of the text within the button container. We can gain a quick win on our disabled button by simply applying our field disabled mixin to the form button in the disabled state.
[3:17] The inherited style sufficiently cover what's needed to alter the disabled button. We can complete our primary button by adding the hover and focus state. When the button is being hovered, we're going to choose to darken the background color. We'll do this by using the Sass scale color function on our color primary and reducing the lightness by 40 percent.
[3:38] We can test that, and we see that darkening occur. For our focused state, it's possible that a button could be both focused and in hover, particularly for mouse interaction. You want to ensure that the focused state is distinguishable.
[3:54] Sometimes, you will see a focus and hover applied as the same styles, but an accessible contrast requirement is that a color change for a focused state has a three-to-one contrast different from the default state. This current color change on hover does not meet that requirement, so we need an alternate style.
[4:11] We're going to bring back the box-shadow trick we used on radio buttons and checkboxes to apply a double box-shadow, where the first shadow closest to the element essentially forms a solid border appearance. Then, behind that, is a more standard looking box-shadow that uses our color primary.
[4:29] A quick win to ensure that this remains visible in the Windows high contrast mode we discussed is to set the outline style to solid and the color to transparent to retain that visible focus for those users. The final improvement we can make is to add a transition property to smooth out the difference between states. On our base button class, we'll add transition.
[4:50] Because we are going to be affecting multiple properties, depending on whether the button is being hovered, or focused, or both, we'll use a transition duration of 180ms, applied to all properties and an easing function of ease-in-out. On hover, you can see that color smoothly update between states. On focus, you see the box-shadow animate out from behind the button.
[5:15] In this lesson, we added markup for our submit button that was explicitly tight-submit, and then we reset the properties to give us a consistent starting point across browsers. Then, we created the rest of the visual styles for the primary button, as well as using our existing mixin to apply styles for the disabled state of a button.
[5:35] We learned about the importance of contrast between button states and that focus in particular needs at least three-to-one contrast with the default color. Instead, we chose an alternate method of adding a box-shadow to create a pseudo border around the button when in a focus state.
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
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!