There's been a lot of talk, for many years about the coming of "the semantic web" - all markup will include semantics that automated systems can read and understand for as-yet-undefined purposes, though prognosticators will speculate on all manner of technical advances that could come from semantics. What about the here and now, though? Right now, today, semantic markup can help you. Semantic markup does one very useful thing: it makes building and styling web pages a heck of a lot easier, if done right.
So, how do you do it right, and reap those benefits? Starting from a
blank slate, start filling in your content. Don't even think about layout or styling - worry only about organizing the content in a clean and sensible way. Your headings should be in h* tags, with lower-level headings using lower-level heading tags. Your content should be in p tags, with no br's. Enclose the main content in an article tag, enclose sidebars in aside tags, and so on. Enclose your header, navigation, and footer in the appropriate tags.
Load the page. It'll look like crap. All you're looking for right now is a sensible document flow. The page should read cleanly from top to bottom with no styling. If not, reorganize your markup until it does.
Now that you have a well-organized, semantically-tagged document, start identifying the parts of the page that are specific to your document. Add id's to unique elements on the page. Add classes to just about every container on the page to identify its purpose - even if it already has an ID (more on this later.) Name your IDs and classes based on what they identify,
not how it's supposed to look. For example, don't use "small" or "bold" as class names; if you want your copyright footer to be small, name it "copyright" and worry about the appearance later. If you want text to be bold, use the strong tag if it's appropriate (e.g. a bold segment of body text), or use a class name that says what the thing is that you want to be bold (e.g. class="announcement" or class="specialOffer".)
Try to use a consistent naming scheme. I use CamelCase for all classes and IDs, with IDs starting with a capital letter and classes starting with a lowercase letter. This is just what makes sense to me personally; it doesn't matter what your standard is, as long as you find it intuitive and you
stick to it.
After all this, your page looks exactly like it did before. Excellent. Now that you've got semantic tags identified with semantic classes and IDs, you're ready to start styling your document. It doesn't really matter what you start with, but I tend to start with typographic styling. The reason behind this is that typographic styling will change the font metrics, and many parts of a responsive design will be relative to your font metrics, so starting with typography gives you a solid foundation on which to build your layout.
For typography, start at the bottom and work your way up: start by applying your default font style to body, and then use that as a base to style any other elements you need to style - headers, paragraphs, strong/emphasis, a, blockquote, and so on. Start with the most generic styles, where you can apply the style to the tag globally, with no class name or ID specified. Work your way in deeper, first with those cases where you can still identify with only tag names, but based on ancestry; for example, you may want list elements inside nav to look one way, list elements inside article to look another way, and list elements inside an aside to have a third, different styling. This is still global based on document structure, not based on classes or IDs.
View your document again; the layout still sucks, but the document should be readable, and your typography should be pretty close to what you want in the finished product. Identify the places where certain uses of an element - which should already be identified by semantic classes and IDs - should be styled a certain way, and start defining those styles in CSS. Avoid using IDs in your CSS; identifying elements by class rather than by ID lends more flexibility to your code.
Once you have your typography more or less like you want it (at least the font families and sizes), start thinking about layout. Your document is already well-organized, but the layout is very 1995. Now is the time to fix that. Presumably you already have a final design in mind, but if not, take the time to quickly sketch out a rough layout for the page, where you want everything to be, and how you want the document to flow in its final incarnation.
You should conveniently already have all of the blocks that you want to lay out in appropriate tags with appropriate classes, so it should be easy to identify them in CSS. If not, review your markup and clean it up. Again, start with the big chunks and work your way deeper from there. Adjust the layout of the main page elements: header, footer, body, columns/grid. View your page, and start tweaking the layout of the elements within those main containers; adjust the layout of inline elements like sidebars and images, adjust the layout of your navigation items, and so on.
Now that your typography is set, and your layout is looking good, you can start on the fancy stuff, like borders, backgrounds, rounded corners, drop shadows, spriting, and so on and so forth: all of the interface fluff that takes a site from usable to beautiful. We're on the home stretch now!
If you're building a modern website, you're probably going to be implementing some fancy UI behaviors using something like jQuery. Depending on the complexity of what you want to achieve, this may be quick and easy, or it may be weeks worth of iteration. Regardless, you've already given yourself a significant advantage: all of that semantic markup, the careful selection and classing of elements, gives you a huge boost using a tool like jQuery, for a couple of reasons. First, it makes it easier to identify the elements you're trying to control in your scripts. Second, it makes your code more readable automatically, because you can quickly tell from the way you've identified an element what you're trying to do. "$('p.boldRed')" doesn't tell you much, but "$('p.callToAction')" tells anyone reading the code that you're manipulating the call to action paragraph on the page. They know what to look for in the HTML, they know what to look for when they're looking at the page in the browser, it's all immediately clear from the identifier used.
This is the basic process for building a
semantic web page. This doesn't cover the finer points of
responsive design, which is a whole can of worms that I look forward to opening in a future post.
