Ready to watch this entire course?
Become a member and get unlimited access to the entire skills library of over 4,900 courses, including more Web and personalized recommendations.Start Your Free Trial Now
- View Offline
- Reviewing the box model
- Calculating em and percentage values
- Controlling how elements display
- Creating fixed, fluid, and responsive layouts
- Structuring content with HTML5
- Floating elements
- Using relative, absolute, or fixed positioning
- Defining column spacing
- Creating grid-based assets and layouts
- Considering mobile-design-specific issues
- Working with multi-column text
- Enhancing page design CSS Sprites
Skill Level Beginner
I want to finish this chapter by taking some time to discuss many of the decisions that you'll be faced with, regarding page layout and page structure. So we're still working with the index.htm file, but this time I've opened it from the 02_08 directory. And a quick glance at the code shows us that we have a lot more content here than the last time we looked at this file. Well, the goal of this movie isn't simply to add all the remaining content; rather, I want to focus on how certain layout decisions will affect the page structure, and how you're going to need to have a strategy in place to help you make those decisions consistently across your site.
Now, to help us with this, I also have the homepage mockup open, and I'm going to switch over to that. Now, this is the Illustrator file that you'll find in the Assets directory. It's the mockup_home.ai. If you don't have Illustrator, there's also a PDF file you can open up that's the same exact file, and at the end of the day, you don't really need to open them up at all, because we're not going to do anything to the mockup; we're just using it to compare the design to the actual structure of the page that we're building. Okay. The first thing I want to do is I want to zoom up on our menu so we can talk about the structure of our menu based on the design that we've created here. Okay.
So each of these links has link text. In the case of our first one here, Galleries, it has an icon right beside it, and then below that we have a little tagline that is descriptive of the link. In this case, this one says, "explore our photos." Now, when we design something like this, one of the first things we have to think about in terms of creating this page is how we're going to structure and code these menu items. For example, does the icon get its own element? The tagline, "explore our photos," is that going to need to be a separate element in order for us to style it the way that we want? And this is what I was talking about when I said you need to have a consistent strategy in place, so that whenever you are faced with something like this, you kind of have an idea already of how you're going to structure this.
And the rule of thumb that I used for this site, and it's one that I actually recommend that everybody uses, which is, you write the cleanest markup you possibly can. You want your markup, above anything else, to be semantic, meaning the tags actually mean something, and you only want to represent the content that needs to be represented or passed off onto any other device. As designers, we think so much about presentation and design that we forget the fact that HTML is a markup language that is designed to essentially identify content within a document and structure that.
So in this case, I'm going to switch back over to our code, and I'm going to scroll down to about line 19 or so, so we can find that menu. Now, you can see that I've used an unordered list to structure the menu, and that is extremely common. Most people do that. Most menus you'll find are structured within an unordered list, for a couple of reasons. It groups all of our links together and it indicates that they're related, and it also gives us some styling hooks. We have the unordered list tag. We have the list item tags. We have the anchor or a tags, and all three of those are styling hooks for us.
Now, it terms of those icons, a policy that I use for images is that if the image is purely decorative in nature, meaning it doesn't really need to be passed on to any other user agent that doesn't understand styles, if it's just for decoration, then it shouldn't really be represented by an element if you can avoid it. In this case we don't have to. We have the list item tags. We have the a tags. That icon could be a background graphic for either of those, and we could use that to style it. Now, the taglines, on the hand, that's a totally different story. We have to have a different styling hook on those; we have to have some way of separating them visually from the rest of our links.
So I'm going to highlight the first tagline right here, "explore our photos," and we're going to wrap this in a tag. Now, what tag we're going to wrap it in, that matters as well. When you're faced with the decision like this where you have content that you need to structure in order to style it the way that you want to style it, if you can do that in a way that still uses semantic markup, then really it's the best of both worlds. So I'm going to go ahead and wrap that in an em tag, or an emphasis tag. And again, that does two things for us. It gives us a styling hook necessary to move the tagline down and format it the way I want to format it, but it also emphasizes the text, and within that larger link, it lets other user agents know that this particular section of text stands apart and is different than the actual link text itself. All right! So I'm going to save the file and I'm going to switch back over to my mockup.
Now, next I want to focus on the area right below the menu, and that's where we have this headline, "WE LOVE URBAN PHOTOGRAPHY." We have some descriptive text to the right of that, and behind all that we have this big skyline image, and the text that's sitting on top of a box is sort of semi-translucent. So from a design perspective, it almost looks like we have four separate elements: we have the image; we have the headline; we have the text; and we have the blue box. A lot of people that are new to web design, when they have a mockup that they design or they grab a mockup from somebody else, they tend to try to put every single element within their design into an element within code, and it doesn't really have to work that way.
So if you look at this, it is a distinct section--and I'm going to call this banner, so it is a distinct banner section--but really there's only two elements that really need to be represented here, and that would be the headline and the paragraph. We'll talk about how we're going to deal with the image in just a moment. I'm going to switch back over to the code, and if I scroll down, I can see that we have our text here, "We love urban photography," and then the copy right below that, but it is wrapped in a div tag. Now, a div tag is an anonymous block of content. So this one has a class of banner to identify as being the banner.
We're not using a section or article tag here because it doesn't really rise to that level of importance. Now, the text, "We love urban photography," that's clearly a headline, but regarding the use of headings and paragraphs and things like that, you also need to have policies in place that determine when it's appropriate to use one heading over another. Now, the policy that I created for this site basically says, if you're the first or main headline within a distinct section of content, you're allowed to be an h1 tag, but it has to be an important section of content. In this case, remember we're using an anonymous container here, the div tag, so that tells us that the section, while distinct, really isn't that important, in terms of the actual content of the page.
So in that case I'm going to go ahead and wrap that in an h2 tag instead of an h1. Now, I'm sure there's some of you out there that are like, "Oh, well, you know, I read a thing on Google that says you can only use one h1 per page." That is not the way the HTML5 specification puts it, and in fact, it's not even the way Google does their algorithm anymore, so that is not altogether accurate. Okay. The next thing I'm going to do is move down to our text, "We're betting you do to." So that is a single block of text, and since it's not a heading, it just make sense to go ahead and wrap that in a paragraph tag. Now, you may have not noticed this in the mockup, so let me switch back real quick.
You can see the word Welcome right there looks a little bit bolder than the rest of the text. So we want to emphasize that as well. So I'm going to highlight the word Welcome there and I'm going to wrap that in a strong tag. Perfect! We have well-structured semantic code that is identifying this content exactly the way that we want it to, based on the strategy that we have for the site. Now, you might be saying to yourself, "Yes, yes, yes, but what about that image, and what about that blue box?" Well, again, go back to the box model properties that we've been working on. This div tag is a wrapper that surrounds all of that content, so it would be very easy to place that image as a background graphic, give it a width and height, and then just have the content sit on top of it.
As for the paragraph itself, it's very easy to also give that a width and a height, assign it a color, and make the color semi-transparent, and then using some techniques that we're going to learn in upcoming chapters, move it over to the right-hand side so that it's sitting to the right of the image. So we don't really need any extraneous markup here whatsoever. Now, that would be lovely if we could structure the entire site the same way, without any extraneous markup, and when you put a strategy in place like that, you really should try your best to make sure that you follow it. However, you're always going to have to make exceptions to the rule.
I'm going to go back into the mockup for just a moment and I'm going to scroll down, and I want to turn your attention to our gallery previews. So our gallery previews, we have three of them, Philadelphia, Chicago, and New York, and you can see they're structured exactly the same. We have a headline. We have the date. But what I want to really talk about here is this image. So we have an image here that lets us preview what's in the gallery. Now, I don't have it available in this particular mockup, but let's say we're going to have several different versions of this page. Eventually, later on in the title, we'll be creating what we call responsive designs, where we have one layout for desktop, another layout for tablet, and another layout for mobile devices.
This image is going to change dramatically. In the tablet layout, for example, this image is going to be on one side and all the text is going to be lined up on the other side. So the practice that we've been using, which is to structure images as background images and just sort of use the semantic elements that we have already in place to put the image in, really doesn't work here. It's also decorative in nature here, so I don't really want to use an image tag, and there's actually several different reasons for that, a lot of which has to do with some responsive design stuff that we'll cover a little bit later on. So if I go back into our code, if I scroll down, I'm going to show you what we're doing in these sections.
So here, you can see we have an empty div tag, and that div tag has a class of preview, and inside of it there's actually a link, so you can click on that image and go to that particular gallery. Now, that's non-semantic markup. It's extraneous markup. If you were to write really just clean code, that probably wouldn't be there. So it's one thing to have your policies in place, but every now and then you're going to have to deviate from those policies in order to get your layout to look exactly the way you want it to. You just want to make sure that that is the exception and not the rule.
So when you have to resort to that, that's fine, but if you find yourself doing that over and over and over again, perhaps your page isn't structured quite as well as you need it to be. Now, more than anything else, I'm hoping that this exercise illustrates how your page structure is actually going to be the results of dozens of small decisions that you're going to have to make based on the coding standards that you've set for your page and the layout goals that your mockup is giving you. There is no one-size-fits-all, and if you gave the same exact mockup, if I took that Illustrator file and gave it to three different web designers, I would bet you money that we would get back three different page structures in terms of the HTML code.
That is why it's so important to learn the rules for creating standards- compliant code and for learning as many different layout techniques as possible. That way you'll have the ability to make really good decisions regarding page structure while having several different options available to you to achieve the desired layout.