The main cord that was struck, most directly in Luke Wroblewski’s Mobile First! talk, but echoed by most every speaker in Boston, is to design from the mobile version of your site first. This theme occurs in the Mobile Web course as well.

For exercises in the Mobile Web course we have to consider mark up that is mobile friendly. Consider, if you will, a simple data table. In a desktop browser, a table is easy enough to render. See, a simple data table.

However, on a mobile device with its much narrower screen, a table simply won’t fit. Instead, the data may be better presented in an alternate form, such as a definition list. (Please note, this is but one example and does not mean that all tables can be equated to a definition list.)

Call me Marie, but I want to have my cake and eat it to.

Enter the Media Query

So what is a media query? There are lots of resources out there. Let me sum it up: media queries allow you to specify CSS rules base not on a device, but on a set of circumstances.

The following block of code applies to any device that claims to be a screen. It will simply make level 1 headers blue:

@media screen {
  h1 {color: blue;}
}

Let’s through a query into the mix:

@media screen and (max-width: 500px)  {
  h1 {color: red;}
}

Now the style applies to any device that claims to be a screen and has a width of 500px or less. There are several other properties that can be queried, but this works for our demo.

Let’s put a query into play on this simple demo page. You should see a green masthead across the top of the page and two gray boxes sitting next to each other. Now narrow your browser.

When your browser gets to 500px wide you should see the green masthead change to gray and the gray boxes become blue and stack on top of each other. The code is quite simple:

@media all and (max-width: 500px)  {
	#header {background: #ddd;} /* little color change */
	.column {
		float: none; /* linearize */
		width: 95%; /* reset width */
		background: #6374AB;
		color: #FFF;
		}
}

The Trouble with Tables

Let’s take the same page and add our simple table to it. Looks fine so far, right? Now narrow your browser.

Once again at the threshold of 500px you should see the boxes stack and the colors change. But this time there is a horizontal scroll because the table needs to be wide enough for it’s content.

The problem: we came at this from the desktop first. What if we reversed that and thought about the small screen first, then adapted it for the desktop?

Ce n’est pas une table

For our little demo, it isn’t too difficult to re-imaging that tabular data as a definition list (or series of list in this case), which should work nicely on most any mobile device. The code looks something like this:

<dl>
	<dt>Ekström</dt>
	<dd><span class="label">Points: </span>44</dd>
	<dd><span class="race">Race 1: </span>10</dd>
	<dd><span class="race">Race 2: </span>2</dd>
	<dd><span class="race">Race 3: </span>-</dd>
</dl>

So we’ve got our cake. Now to eat it too.

Definition lists are just fine in a desktop browser, but I really want this to be more table-like.

You’ll notice that there are already some class attributes. We just need to add a little more markup to create what will become the table headers:

<div class="head">
  <div class="row">
	<div class="dataHead"><abbr title="position">Pos.</abbr></div>
	<div class="dataHead">Driver</div>
	<div class="dataHead"><abbr title="points">Pt.</abbr></div>
	<div class="dataHead">Hockenheim</div>
	<div class="dataHead">Oscherslebe</div>
	<div class="dataHead">EuroSpeedway</div>
  </div>
</div>

and style with display: table and related properties. For example:

dl, .row {display: table-row;}
.dataHead, dd, dt {display: table-cell;}

(View the complete CSS)

We now have markup that is mobile friendly styled in a desktop friendly way. All that is left is to undo those desktop styles for small screen display using our media query. Mostly this involves display: block to counteract the table display properties.

The end result: a desktop and mobile friendly web page. Once again, with a device wider than 500px you should see green color and a basic table. Narrow your browser to less than 500px … presto! our definition list re-emerges.

I’ve used a similar media query on this site. Narrow your browser and it should revert to one column.

Caveat

No, this is not a perfect solution. It is a solution. If you look at the full code you will see some markup that may be questionable (the first dd in the lists). I merely present this to get us all thinking about they way we think about and markup data.

Your mileage may vary; use at your own risk; objects in mirror may be close than they appear; etc.

During the past year I’ve become interested in using web standards and semantic markup. The idea is to separate content from presentation. For example, I have followed a variety of holy wars over the use of <i> (italics) and <em> (emphasis) elements. Italics are presentations, emphasis describes the content. The <i> element has been depreciated in favor of <em>, but that leaves a few things hanging. For instance, how should I code a book or movie title?

I follow the convention that book titles should be italicized, eg. The Stars My Destination. But if <i> has been depreciated, that leaves <em>, which isn’t the correct choice — I’m not emphasizing the title, I just want to note that it is a book title.

So far I’ve just been talking about a visual distinction. But, as I mentioned at the beginning, I should be separating content from presentation — as well as adding meaning to that content. So, how is a machine to distinguish a book title from the rest of the content? Presumably the <cite> element, which is vaguely defined as "[c]ontains a citation or a reference to other sources." While I’m not convinced that a passing reference to a book constitutes a citation, it is better than using <em> or hacking up a meaningless <span>.

The next problem is that, by default, <cite> renders it’s content in italics. I prefer following MLA style, which calls for books, movies, plays, etc. to be italicize (or underlined), while articles, short stories, poems, etc. are quoted: The Stars My Destination (a novel), Fences (a play), Close Encounters of the Third Kind (a movie), "The Tyger" (a poem), "Bastille Day" (a song), etc. Clearly a basic <cite> element won’t work for all of these variations.

Additionally, at work I have to use AP style for marking up works. AP has a number of quirks, beginning with no italics. Additionally, books, movies, plays, poems, etc. are capitalized and quoted; reference works are not quoted, nor receive any other distinguishing marks.

So, with different types of works and different style guidelines, the <cite> element as-is simply won’t suffice. We’ll need to add some classes in order to distinguish types of work. This will give us hooks for styling — <cite class="book"> can be italicized or underlined, <cite class="poem"> would be render normal and even have quotes automatically added around it (at least in CSS 2 compliant browsers). Of course, if you need to follow AP or other style, changing just a couple of properties in the style sheet will take care of that. In the end, we’ve managed to visually style elements to our desire and added a bit of meaning.

Enter Microformats

With the advent of microformats, I now see a way to add more meaning to the classes I would have used simply for styling purposes. We can add meaningful values the <cite> (or other) element that indexers and others can make use of, all without adding, changing or otherwise hacking existing (X)HTML.

Dougal Campbell brought up the idea of a microformat for music tracks and other media on the microformats mailing list. I gather that there are others interested in this as well.

His idea goes far beyond what I was thinking (he mentions track name, running time, etc., ala ID3 tags) and that’s a good thing. Mention has been made of coming up with a format that would capture ISBN, author, editor, pages, etc. for books, magazines, et al. I’d like to see this microformat get created, as long as it is done in a modular format.

In other words, Amazon.com could use the full format for marking up books, but in a blog entry, I can use just a minimum of mark up to distinguish that I’m referring to a book; i.e. <cite class="scific novel">The Stars My Destination</cite>.

I’d also like to keep it element independent. In other words, I may implement this using the <cite> element, but if you feel strongly about using <em> or definition lists, you can do that. In fact, a definition list is probably a good way for Amazon.com to mark up titles (a block of title-related information) versus a passing reference (an inline mention).

I think that this is an exciting proposition and am interested to hear from others. What are your thoughts?

Since I have recently been changing the way I code by paying more attention to semantics and using the best, cleanest CSS that I can, this has gotten me to thinking.

To sum up the various arguments, the bold and italic attributes shouldn’t be used (according to the Semantic Coders Guild) because they are purely presentational (ie: visual) and provide no meaning. Instead, they say that we should use the “semantically correct” <em> (emphasis, typically italics) and <strong> (strong, typically bold) elements. These elements are useful for things like screen readers for the visually impaired. They literally tell the reader to add emphasis when reading, just like you do when talking.

So how do we convey that via the visual media of the web? CSS allows us to style <em> and <strong> anyway we want to add visual emphasis.

So far so good.

But I began thinking. Is <strong> really a necessary element? It seems redundant and/or meaningless to me. The point of marking something out in bold/strong type is to add emphasis. So why not just use <em>? It would be just as easy, and I would argue just as semantically correct, to use something like <em class=”italic”> and <em class=”bold”> to change the visual nature of the element while still retaining the semantic emphasis. [Note: the classes mention would, of course, be properly styled in the style sheet with font-style: italic and font-weight: bold. Call the classes whatever you'd like.]

My thoughts snowballed from there to the ever-present <span> element. Does it ever serve any semantic purpose? I think the only time I use it is when I need a hook in order to visually style a section of text. (See the note in the previous paragraph.) So, if the Semantic Coders Guild is calling for the end of all non-semantic markup, what do we do with spans? I’m sure that somewhere, someone has managed to use a span in a semantic way, but I personally can’t think of any at the moment.

[For those of you who may be looking at the code for this site, don't bother telling me how bad it is. I already know that the code has problems. I haven't bothered to clean it up because I am working on a full redesign - or more correctly, an actual design. While I have been working with HTML for a few years, it is only recently that I have begun to understand and care about the code. At work I am constantly improving my coding habits, moving away form HTML tag soup to proper coding. It is so much easier to maintain. This will be reflected in my new site, whenever it gets done.]

[Oh, I made up the Semantic Coders Guild. If anyone was wondering.]

And, while they all look great in Mozilla (I love this browser), I just checked IE 6.0 and it, for some reason is cutting off the blog at the hight of the right-hand box. ::Nevermind. It’s all better now::

If you are looking for information on using stylesheets, try A List Apart. And don’t forget to Upgrade Your Browser.