Mock-up to valid XHTML: how to build a web page – part 2

Posted on May 3, 2009 in Design, Web Dev | 0 comments

This is the second in a two-part series on the proper way to create a standards-based webpage from a designed mock-up. The first post dealt with one common method for doing so, the Photoshop slice-and-dice, and what’s wrong with that approach. This post will focus on the steps I took to create a page for Quadrant Homes for an event called “Opportunity Knocks.”

As a web designer who receives a mock-up (usually in PDF format) and is tasked with creating a web page from it, there are a few steps to the process:

1. Break the design down into components
2. Input the text associated with each component
3. Structure the text with XHTML mark-up
4. Style the marked-up text (including images)
5. Test your styled mark-up in all browsers
6. Add (and test) any javascript interactivity

See? It’s easy, only six steps. But of course, each one has some lots of detail. To ground this process with a concrete example, I’ll be using this PDF mock-up to create this result. Continue reading after the jump.

Break the design down into components

This initial step is like squinting at the design from arm’s length. What broad sections stand out? Is there an obvious header, sidebar, content area, footer, callouts, etc.? In my example mock-up, I found three main sections listed below along with the IDs I later assigned them:

1. Header (“top”)
2. Left sidebar (“sidebar”)
3. Main content area (“details”)

Before continuing, a word of explanation about the page structure. Since this design was to be integrated into Quadrant’s existing site, I had to retain the top-level navigation and footer information. That’s also the reason why you’ll see (gasp!) tables used for layout in the design. Sometimes you have to work within contraints like that, and it simply made more sense to do things properly within the table’s content cell rather than break the page’s server-side include files and have to do everything from scratch.

As I styled the mark-up, I found it easier to sub-divide the header into two divs (“top” and “stripe”), but essentially I had these three structural components to work with.

Input the text associated with each component

This is the easiest of the steps, really: just enter the text into each component. You can copy-and-paste it from the PDF (which usually requires some touch-up and removal of line breaks, etc.) or type it in again. If you’re really lucky the designer may provide a document with straight text. After this, your code should consist of some structural divs with a lot of plain text between them.

Structure the text with XHTML mark-up

To borrow (and mix) a metaphor, if this entire process is a meal, structuring the text with XHTML mark-up is the “meat.” (Styling the mark-up with CSS is the “potatoes.”) Marking up text isn’t really glamorous, but it’s important and makes life so much easier later. You can take a look at the XHTML I wrote for this page.

If you’re reading this post, chances are you know HTML and how tags work, so I’ll just touch on the high-level concepts of good, structured XHTML mark-up:

• All tags must be closed – Paragraphs should start with <p> and end with </p> as should your list elements <li> and other tags that regular ol’ HTML lets you get away with not closing. Even stand-alone tags like <br> and <img> need to “closed” using their XHTML cousins <br /> and <img … />
• All tags should be lowercase – As should their attributes. I’ve always preferred that aesthetically, but it’s required under XHTML.
• Important tags should have IDs or classes – With proper mark-up it’s usually pretty easy to style elements (paragraphs, list elements, headings, etc.) through basic CSS selectors. But you will need to be able to pick out important tags—such as structural divs or re-occurring design treatments like callouts—by adding “hooks” to your elements with IDs or classes.
  • IDs are unique within the document. For example, you can only have one “header” or “footer” per page. They’re used like this: <div id=”header”>
  • Classes are not unique. They can be re-used whenever necessary, such as to indicate inactive navigation elements or identify special paragraphs. They’re used like this: <p class=”callout”>
• Rely on existing tags whenever possible – HTML provides a wealth of tags to style your content. Use them rather than wrapping content in span tags with arbitrary tag names. For example, use <em>, <strong>, <blockquote>, etc. rather than <span class=”important”>, <span class=”bigger”>, or <div class=”indented”>. Don’t worry if you don’t like the default italics, bold, or margins these tags introduce: you can override them later in your CSS.
  Why does tag choice matter if we’re going to override the tag anyway? Don’t forget about accessibility! A “user agent” that doesn’t understand spans or divs (or a visitor who has CSS turned off) won’t see any formatting if you chose to use <span class=”important”> rather than <em>. The built-in tags have semantic meaning separate from any visual information they impart; you lose that when you have dozens of spans or divs with class names. (Not to mention that <em> tag weighs in at four characters; using <span=”important”> is 23!)

For further detail on XHTML in real-life use, there’s a good summary of how the w3schools converted to XHTML. And of course Wikipedia has all the info you could hope for on XHTML.

Style the marked-up text (including images)

There’s a lot to this step. In fact, I’d say I spend roughly half to three-quarters of my total development time creating and tweaking styles. But it’s also the most fun!

Of course, you need to know CSS. If you’re reading this, chances are you know that means Cascading Style Sheets. If not, here’s a primer. CSS is like the instruction sheet that comes with your Legos (and many other analogies). It’s a set of style definitions that are “hooked” onto your marked-up text. Want that headings to be blue? Set your heading tags like this:

h1, h2, h3, h4 {
color: blue;
}

How about a sidebar? Set a class like this:
.sidebar {
padding: 1em;
background-color: #eee
}

That, and so much more. Want to add a line between two floated columns? That’s a job for the child selector (+). CSS is a language unto itself, and once you know the syntax for setting colors, fonts, borders, positioning, and the myriad other things CSS can do it’ll become second nature. And then you’ll become obsessed with “optimizing” your CSS with shorthand (well, maybe; I usually don’t bother). Reality check: this may take some time. Understanding the nuances of CSS implementation across browsers takes a while. Ooh, and understanding the float property so you can ditch table-based layouts for good can be mind-bending (trust me, you’ll need this article, and this one too). You need to put in that time to really be able to make the magic happen on screen (and on print, if you set up a stylesheet for printing!). Let me save you 30 minutes of frustration right off the bat: don’t start IDs and classes with a number—like “5list” or “100percent—they’re not recognized.

As you style your content, keep a few things in mind:

• Write CSS in the head – No, not your head—the tag of the document you’re working on. Yes, your final CSS should be in an external file and linked to from your document. But when you’re developing CSS and tweaking your markup, it’s much quicker to save (and then upload, depending on your development configuration) one file instead of two.
• Get help – There are a lot of visual CSS-generating programs out there. I don’t use them so I can’t say too much about them. I prefer a good HTML editor that understands CSS with syntax highlighting and contextual pop-ups that feed you possible values. I sometimes forget how to set text in all caps (is it text-transform: italic or font-style: italic?). Great editors like Panic’s amazing Coda will guide the way. Of course you can always just Google it, but that’s slower.

Along with the XHTML for the document above, I wrote this CSS to style it all. Note the use of background images for divs. By using heading tags (h1, h2, etc.) inside those divs and using CSS to hide their display with display: none; you can create a graphical display that works perfectly for browsers without CSS and allows search engines not only to see the text, but recognize their importance through the use of heading tags. Win-win!

Test your styled mark-up in all browsers

Once I’d built a great site all in CSS, including its layout. I even had some groovy rounded corners on elements. Then I saw it in IE on the PC… what a mess. Fixed some things, and took a look again in an older version of Safari. Not too pretty. So I Iearned it’s better to review your design in all the major browsers (IE 6, 7, 8; Firefox 2, 3; Safari 2, 3, 4 as of this writing) so you don’t get an unpleasant surprise later. This is especially true of layouts with floats and if you’re doing anything with CSS expressions.

What browsers you test for depends on two factors:

1. Audience – Who’ll be using your site? PC or Mac? (The answer is both, but to varying degrees.) Do you need to support older browsers like Netscape 4? Should your design work on smaller screens? The answer to these questions can be found from your webserver logs or, more likely, Google Analytics or Mint. You have one of those installed, right? Right?! Take a look at the Visitors > Browsers and OS display from my Google Analytics account:
2. Design complexity – If your site is informational and consists mainly of bulleted lists and paragraphs organized by headings, chances are you won’t have to test much. If you’ve got a liquid, mulit-column layout with nested elements, rounded corners, sIFR, CSS rollovers, etc.—you’ve got some testing to do!

One issue with testing is having both a Mac and PC handy, each laden with multiple versions of IE, Firefox, and more obscure browsers (iCab or Konqueror, anyone?). Though it’s in your best interest to have easy access to both platforms, there are great tools for Mac-based developers to test their designs in popular PC browsers (and vice-versa, I’m sure). Browsershots.com has helped me find issues with older versions of IE that I wouldn’t have otherwise caught.

Add (and test) any javascript interactivity

In my example document there was no need for any interactivity, such as form inputs, auto-updating content, etc. But if your site does require that, it’s best to take the same “progressive enhancement” (PE) approach to javascript that you should (and have, right?) with CSS.

There’s a lot to the topic so I won’t go into a ton of detail here (the wonderful A List Apart already has). But in a nutshell, PE is the approach of building a site with good, semantic markup as I’ve described above. From there, you “enhance” the markup with CSS, also described above. (CSS can also be applied in PE style, as this article explains). The next layer is the application of “unobtrusive” javascript by way of hooking scripts onto your pages’ elements through the DOM rather than inline “javascript: myFunc();” calls. So you’re building a site that give a better user experience (such as live validation of form input, drag and drop re-ordering of table columns, AJAX-based data updating, etc.) to browsers that can support it, while retaining full functionality for older browsers.

The last thing to remember—though by no means least important—is to test your design in many browsers. PE is great but the fancy stuff still needs to be tested. I’ve built functionality that works fine in Firefox and think I’m done, only to find that the same code fails in IE. It’s then a matter of altering the code to ensure it works in both. So don’t forget to test!

Yes, building a standards-based webpage takes a lot of work. But I stand by my statement that doing so is a better approach to cutting corners by slicing-and-dicing a mock-up in Photoshop. And if the steps in this article didn’t make sense, let me know with a comment. There are many approaches; the one I’ve outlined here is but one. Thanks for reading, and happy coding.

Related: If you liked this, check out:

1. Mock-up to valid XHTML: how to build a web page – part 1 What an auspicious title! I recently had an opportunity to...
2. M-dashes not allowed in XHTML comments I found out today that one of my favorite punctuation...
3. Why Photoshop Isn't A Web-Design Tool If you’ve never had the pleasure of using a web...
4. Hyphenation on the web If you're not a print designer who commonly works with...
5. Link icons through CSS After a dearth of design-related posts, I finally have a...