Working with forms
Video: Working with formsIf there's one area that frameworks consistently seem to focus a good bit of effort on, it's forms. Since form elements are some of the most difficult elements to style across multiple browsers, it just makes sense that most frameworks would attempt to make the process of structuring and styling forms easier. And to explore how a framework works with forms we're going to take a closer look at the Foundation framework. If I was to scroll down in the source code around line 60 or so you can see that we have a contact form. And I normally really like to structure forms using unordered lists because the form elements all relate to each other.
- Additional resources
Viewers: in countries Watching now:
Have you wondered if using a CSS framework will speed up your site development? In this course, senior author James Williamson introduces the types of frameworks available—including the most popular choices among working web developers—and provides an honest assessment of the pros and cons to using a framework. He guides you through downloading a framework, setting up a directory structure, and building a framework-based site, such as structuring the HTML and working with forms. A separate chapter explores layout grids, often included with CSS frameworks, which provide a simple system for laying out page content.
- Understanding boilerplates, grids, and frameworks
- Choosing a framework
- Building your own framework
- Crafting a deployment strategy
- Modifying files
- Customizing typography and color
- Filling in framework gaps
- Exploring grid-based syntax
- Nesting grids
- Using mobile grids
Working with forms
If there's one area that frameworks consistently seem to focus a good bit of effort on, it's forms. Since form elements are some of the most difficult elements to style across multiple browsers, it just makes sense that most frameworks would attempt to make the process of structuring and styling forms easier. And to explore how a framework works with forms we're going to take a closer look at the Foundation framework. If I was to scroll down in the source code around line 60 or so you can see that we have a contact form. And I normally really like to structure forms using unordered lists because the form elements all relate to each other.
An unordered list is a good way to show that sort of relationship in a semantic way, and it also gives me additional styling hooks. But in this case, since I have made the decision to use a framework, the first thing that I wanted to do was to see how the framework treated forms, how it styled it, and how it structured them. So I spent a good bit of time in the documentation of the Foundation framework, which we're going to take a look at in a moment to see how it deals with forms, so I would know how to structure my forms to fit the framework. So sometimes you do have to kind of make those trade offs. So you can see we have some labels for the form elements, then we have the form elements themselves.
So there really isn't any extraneous markup in here, there's just probably some structure that I would normally give a form that I didn't give in this case. If I preview this page in my browser and start scrolling down, you can see that other than the page layout, which is going to controlled a little while later when we tackle using a grid. You can see that the form itself looks pretty good. I really like the look of their form elements. I like the way that they arrange the labels in the form element itself, stacking them on top of each other. Now if I switch over to the foundation of the documentation and look at the Forms section, I have got some nice information here, that you can read through that talks about some of the basics of form elements styling.
One of the things that really attracted me to foundation versus other frameworks is the fact that rather than dealing with classes and a lot of frameworks out there deal with these types of classes that you have to apply to every form element, if you want their framework's default styling. Foundation uses the type attribute. So input type=search or input type=text. So that's a nice way of doing that without having to apply a lot of classes to it as well. It talks about the different types of layouts that you can get. If you want to align the inputs to the right of the labels, it tells you how to accomplish that, it shows you sort of how default field set styling has handled. And it has some little extras in it so that you could do things like these prefixes and postfixes.
You can also do a postfix that has an action or a button if you want to put those two right beside each other like that, error states if you're doing form validation. How large forms can be handled and things like this custom inputs where instead of dealing with the browser's default form elements, you can sort of do these custom ones. So there's a lot of things that you can do here, that are pretty cool. So what I'm going to do is I'm just going to switch back to my form, and I'm just going to start working with this and tweaking it a little bit. I'm going to scroll down into my form code, and I'm going to go down to the submit button because one thing I would really like for that to do is rather than having the input button rely on the browser for its formatting, I would really like it's formatting to be more consistent with the sites.
So what I'm going to go is I'm going to give it a formatting of button. So I'm going to go right after my tab index here and create a new class attribute and the class attribute that I'm going to apply is simply button. Now as soon as I save this, go back out to my page and refresh this, if I scroll down and look at the submit button, you can see that I'm getting the default button formatting coming right from the Foundation framework. So that's just one class application that can really enhance the way that my form looks, which is awesome. Now another thing that I would like to do is again, rather than having the browser default radio buttons here, I would really like to kind of go back into this forms and take a look at the custom inputs. I really like the way these look.
So I wouldn't mind using those instead, and just a quick read through the documentation and a look at the sample code shows me kind of how this code needs to be laid out and what needs to happen to the form. In this case, for example, the class custom applied to the form itself. So what I'm going to do is I'm going to go back into my page, go up to the parent form tag, and I'm going to give it a class as well. In this case, I'm going to say class="custom", and that's going to tell Foundation that I wanted to replace the default form the with the new custom form elements.
So if I save that and preview it. Now rather than the default radio buttons, I get the Foundation radio button, which that styling is a little bit more in line with what I'm doing for the rest of the site. So it's sort of that very simple flat styling that I have gone on everywhere it's now reflected in my radio buttons as well, which is really nice and is really easy for me to do. Now I do want to point out one thing here, that's pretty important. If I look back at my code I really like to keep my labels and my input elements separate, and I use the for attribute to let any type of device or user assistive agent know who the label refers to.
So it's accessible, it's a little easier for me to style because I have two separate elements that I can write styles for. So I really like that rather than wrapping the entire thing in a label tag. However, for the radio buttons you are going to notice that, I have the label tag wrapping, the entire input and the reason that I had to do that is because I want the labels to appear right beside the form elements to the right, and there really wasn't any other way for me to get that to happen without overwriting a lot of form styles within the framework itself.
So sometimes you do have to make some of those trade-offs. Now another thing that I would like to do, you can see that the default nature of the Foundation forms is to take the inputs and stretch them to 100% of the width which looks really, really weird right now. Well, remember, we're going to control page layout a little bit later on, by using the grid that comes with Foundation. So that's not something I'm going to fix at the moment or even style. I'm going to let the grid handle that, knowing that whatever column I put this form moment that's in unless I tell them otherwise you're going to stretch to 100% of it.
So I kind of already know that about my forms, that's awesome. It's actually really easy for me to control now the width of these form elements, by just using the grid and telling it how wide I want it to be based on the grid that it's sitting inside of. That will become a lot clearer in the next chapter, if you have never worked with grids before, you'll understand exactly what I'm talking about, once we start getting in there and working with it. But the grid isn't the only method we have available to us in the Foundation framework in terms of lining grouping and presenting content. As a matter of fact, if I go back to the documentation site and take a look at the page about grids and layouts.
One of the things that I notice is they have a little section here for Block grids and they have some examples here of Two-up, Three-up, Five-up, Four-up. If you take an element, and you arrange it in an unordered list, you can give the unordered list the class style block-grid and then pass in how many up you want, and it will go ahead and arrange this sort of grid pattern for you. They also have mobile styles too so that you can make them responsive. So maybe you're having Five-up on desktop and maybe Two-up on the mobile space, and it's really super simple to use.
So rather than having to lay out the entire form using the grid system, I could go ahead, for example, and take these radio buttons and just create a block grid out of them. To do that, I just go right back into my form. I'm going to find all of those radio buttons. So it starts right here with the label for speaking and goes all the way down through the label for weather. So I'm just going to highlight all of those, and I'm going to wrap them in an unordered list tag. Again, if you're using a different editor you might have to use a slightly different method, but that's probably the easiest way for me to do those, and then each label I'm going to wrap in an individual list item.
So essentially I'm just taking these radio buttons and adding a little bit of additional structure to them. You might be saying, well, that's all not that semantic, but actually grouping these guys together in a list is perfectly semantic. It lets any user agent know that these elements do relate to each other, they do belong together and to be quite honest with you, this is typically how I lay out my forms. I use unordered lists to do that. So remember, all we have to do is apply a class in order to get sort of that grouping. So what I'm going to do is I'm going to do a UL. I'm going to give it a class of block-grid and then do a space and then I'm going to do four-up and then another space and then do mobile-two-up.
So let me talk about what those classes are, and this is all part of the Foundation framework. I'm saying, hey, I want to create a block grid, a grid out of these elements. I want the initial layout to be four-up and then when it breaks down to the mobile design, I want it to go down to a two-up. So if I save this, preview this in my browser. You can see exactly, what it does, it goes ahead and puts all those radio buttons four-up, and if I resize my page, and go down to say the mobile context, let me just go ahead and resize this. You can see that since I get down to mobile, it goes to a two-up block which is really nice.
I think it goes back to four-up when I go back to desktop. If I don't like the four-up, I can go ahead and change that, I might change the default one to two-up as well. If I do that, I have to leave the mobile two-up in here, because the mobile-two-up is a class that applies only within the mobile media query. So it's one of the things that it's sort of baked into the framework, and you have to understand obviously how these classes work. So anytime, that you are going to work with your framework, you need to spend a good bit of time looking at these custom classes, looking at these custom capabilities and understanding what your framework is capable of.
So I save that and preview at, I can see that even in the desktop my radio button elements are aligned in this sort of two-up block, and that's going to persist even when I go down to say, mobile size of the screen. So one of the things that I want you to take away from this was that although our sample framework gives us a ton of form options. If we go to the Foundation documentation and spend some time on that Forms page, you are going to see that there's a lot of options there. We really didn't have to do a lot to customize our forms. Pretty much we just lay the form out using the structure that the Foundation framework expects and the styling just happens automatically.
If I didn't like the styles that I have here as far as like the way that the labels look and the text fields look and things like that, I would have to overwrite those and overwriting those default form styles would take a considerable amount of work. So I really recommend making sure that whatever framework you choose has forms styling that you're happy with right out of the box. As always you are probably faced with some amount of trade-off when adopting a framework. As I have mentioned already, and I typically place all my form elements in unordered list to structurally indicate they are related since Foundation doesn't really allow for that in the default form styles.
I have to decide exactly how important that bit of semantics is to my overall site development. Now that's likely a choice you are going to face no matter which framework you use.
There are currently no FAQs about CSS: Frameworks and Grids.