b++ Episode Three: Mark it up!
This is the third part of the series, “Environmental friendly CSS”
In the previous episodes we’ve created a creative/technical brief and then mocked-up design in Photoshop. The next step in a process is creating solid XHTML markup. Let’s open it up with a question:
How to markup category cloud?
There are two simple approaches that usually comes to mind at first: a paragraph and an unordered list.
If we use paragraph with links, we wouldn’t probably miss it in terms of the default presentation across the range of User Agents. The thing is — if one is marking-up a ‘cloud’, it’s natural that all the links are inline, one after another.
— Let me think about it! Yea, I will just set
text-alignment: centerto that paragraph and I’m done. Great!
<div id="category-cloud">
<h4>Most popular joke types and categories</h4>
<p>
<a href="#">Political jokes</a>
<a href="#">Professional humor</a>
<a href="#">Mathematical jokes</a>
<a href="#">Ethnic jokes</a>
<a href="#">British tell jokes</a>
<a href="#">Self-deprecating humor</a>
<a href="#">Blonde jokes</a>
<a href="#">Redneck jokes</a>
</p>
</div>
Not great! The above code is wrong. The ‘cloud’ is a visual cue, not the structural element. The category cloud is — in its essence — a list of categories, so the more suitable XHTML element would be unordered list.
It’s not a cloud, it’s a list
Cloud as typography or XHTML element doesn’t exist. Tag or category cloud is a visual representation of the list of categories. So let’s try semantically correct markup — an unordered list.
<div id="categories">
<h4>Most popular joke types and categories</h4>
<ul>
<li><a href="#">Political jokes</a></li>
<li><a href="#">Professional humor</a></li>
<li><a href="#">Mathematical jokes</a></li>
<li><a href="#">Ethnic jokes</a></li>
<li><a href="#">British tell jokes</a></li>
<li><a href="#">Self-deprecating humor</a></li>
<li><a href="#">Blonde jokes</a></li>
<li><a href="#">Redneck jokes</a></li>
</ul>
</div>
Some novice CSS developers in the past argued that they were having troubles with list-items in tag clouds. In the last article (coming up next week) we will explain it throughout. But, it’s very important to learn how to shift from visual/CSS mindset to semantic/contextual XHTML mindset.
A little practice will get you there
When deciding on the XHTML structure for any given element, try to ignore the design at first. You will easily modify markup later if you find no other way to accomplish layout only with CSS.
Instead, dive-in under the surface and check the bare-naked content and context to decide what markup should do the job.
If creating XHTML snippets is a second nature to you, please share how do you fight your thoughts about how it’s going to look when choosing appropriate markup?
001—2008.12.12.14:54
Great article – code semantics are so important these days and are a good indication of the difference between a novice and experienced web developer. Clouds are, as you say, quite clearly a list of items and hence should be coded as such.
For me, the easiest way to tackle something like this when you have a design is to ignore the graphical side of the design altogether.
Instead, break the design down into sections – header, main body, footer. Then break each of these down further still – logo, page title, main navigation, etc. Often I code all the XHTML without even thinking about the CSS, then style it at the end. This way I only have to concentrate on making the XHTML semantically correct at first, and I can worry about the visual appearance later. As you said in the article, if there is something you really can’t do purely with CSS, then you can always tweak the XHTML mark-up if you have to.
002—2008.12.13.04:54
Matthew, thanks for sharing — breaking the design into sections is great approach indeed.
003—2008.12.13.12:14
As a designer I must say that for me thinking about markup starts already when designing a layout. I draw first everything on paper and before that I make a clear structure of the site. When thinking about some elements on the site in a way how they will look like I also think about how will the markup look like.
Maybe this is not the right way, correct me, bit it works for me.
After I’m done with designing I already know how to code it and if something doesn’t go by plan (meaning markup) I make some alternatives.
004—2008.12.14.23:39
I also use “layering method” – XHTML markup first, CSS styling second, then JavaScript behavior last. Of course, most of the time there are some changes to be made to the markup/styling/behavior, be it some necessary workarounds or fresh new ideas :).
Marko, what do you think about using lists for calendar representation? Common practice is to use tables for this things, but since calendar is list of dates, is it correct to use them as calendar alternative? I’ve seen some examples, but don’t think there are too much pros to using them.
Also, naming conventions in CSS: using header and footer IDs for XHTML elements, for example. They all describe where the elements are placed, but not what information they actually contain or represent. Some other semantically correct alternatives?
005—2008.12.15.12:53
@Marko: Do you feel restrained in the design phase if you have to think about markup and CSS all the time.
@Ivan: Using tables is appropriate markup for calendar, especially if you think of rows as weeks and days as columns. If written in full, such table would have starting cell in a rows marked-up as
<th scope="row">Week 01</th>006—2008.12.15.15:47
Restrained? Well in some cases, yes. I could talk now about that a lot here but I wont. It’s not that I think about markup all the time, it’s just simply that in the design process I make some compromises on behalf of better or should I say easier to make markup and css, for me of course :). Those compromises never interfere with my overall design.