Microformats Abuzz

As you may have heard, Bill Gates ushered in a new era by saying: “We need microformats” from stage at Mix’06. It was a long time coming. Slowly but surely the purists in us are realizing that this might be the only way to bring the vision of semantic web into fruition. Slowly but surely the mechanics in us are grokking the importance of semantic markup and the benefits that come with it. And I say with open arms: “Welcome to the fray!”. Kick the tires, join the discussion, learn the process, participate in development — and start using them, dang it!

Back? By Popular? Demand?

Yes, ’tis a post of many questions. “What happened, dude?” Lots and lots of stuff. Here’s a brief summary: worked like crazy, lost lots of sleep trying to get the little one to sleep, started back on drinking coffee, replaced a house HVAC system, cooked delicious Christmas meal, gained new friends, lost a friend, found cool sites, got disappointed in most of them, became fascinated with new technologies, then disillusioned in some, made serious life and career choices, pondered philosophical questions, decided to write a book, then cooled down a bit (but not too much), swore to stop cursing (well, that lasted all 10 minutes), joined a project, abandoned a project, spoke at a couple of conferences, talked about Web 2.0 like I know what I’m talking about, and wrote a lot of code, diagrams, and specs everywhere in between.

Oh, and I also got sucked into another blog: http://fuzzycontent.com. This is a collaborative project that Bob Robertson-Boyd and Eric Hodgson have started. I hope you like it — we’re just getting started.

Growing Feet on Valuable Equipment: Bad People Are Out There

I was coming back from a long meeting. The day was almost over. I didn’t expect to find anybody back at the office, and I was right: the last person locked the doors and left about 10 minutes prior to my arrival. In that short moment of time, someone broke into the building and stole 3 laptops, one of them mine.

What can I tell you? I am sad that I lost some work that wasn’t backed up since last night. I am upset that my music collection and some valuable information is gone, among them a 2-days’ worth of code, latest blog roll and a draft of a blog post. Oh well, back to the drawing board on those.

So, here’s a reminder: bad people are out there. And to the baddies: you suck!

Motorola HS850: Now Machine Washable (and Dryable)

The weekend was drawing to a close. My son was carrying a shoe around the house with such determination and intensity that I couldn’t help but follow him around and wonder if there really was a mystic purpose behind his concentric journey. Just as I was starting to doubt the prudence of my diminutive leader, we were interrupted by a gasp of horror — my wife was standing beside the open door of the clothes dryer and holding out her hand. On the palm of her hand rested a minuscule digital gadget, the Motorola HS850 Bluetooth headset.

We will never know whether I’d forgotten to take the headset out of my pocket or maybe (quite possibly!) the mean laundry gnomes planted it gleefully in the dirty laundry. The outcome however, was painfully obvious: the headset took the Frigidaire washing cycle ride, followed by the Frigidaire dryer tumble. Even a one-year old could tell you that we were now staring at something that should never blip or blink again.

Just like an ER character, who refuses to accept the flat-lining patient, I rushed to the power adapter and plugged the thing in. And, just like in the aforementioned over-the-top dramatization of emergency health care, something miraculous happened: the headset lit up and started charging.

We couldn’t believe our eyes. The darn thing was still breathing. A couple of hours later, I attempted to use it. And yet another thaumaturgy played out that fateful evening: the headset hooked up with the phone, recognized my voice command, and successfully dialed a number!

Since then, I’ve been using this headset every day and have yet to find any trace of impact of the water-and-heat abuse that it endured. I haven’t been a huge fan of Motorola, but this feat is changing my ways of thinking.

Oh, and contrary to my coworker’s theory and his repeated attempts to test it, the headset still lets through bad words. If washing digital equipment was all it took to clean up the lexicon, Tide would’ve had the market on spam filtering. Now, machine-washing the spammers themselves might not be a bad idea…

Semantics of Comments

Hey, what happened to June? You tell me.

Here’s a quick brainstormer: what would be the correct semantic markup of comments? The overarching structure is easy: list of comments is an ordered list, so we’ll use OL and LI elements to convey that.

What about the content of each comment? According to CommentAPI, here are the elements defined for each comment:

  • title — title of the post
  • link — link to the home page of comment author
  • description — text of the comment
  • author — email of the comment author
  • source — name of the comment author’s site (blog)
  • dc:creator — name of the comment author
  • permalink — permanent URL of the comment.

The last one is not really part of CommentAPI, but nevertheless important to have. Now, how would you express this in XHTML? My inclination is to treat this as a data row, and use DL element (DT for the title, individual DDs for all other content):

<ol class="comments">
    <a href="permalink">Comment Title</a>
   <dd class="author">
    <a href="mailto:authorEmail">Author Name</a>
   <dd class="source">
    <a href="authorSiteUrl">Author Site</a>
   <dd class="description">
    Text of the comment

What about using CITE and BLOCKQUOTE? Are we really citing and quoting here? Any other semantics that might need to be conveyed? Thoughts, critiques, and ideas are appreciated.

Beware of the Ubiquitous Baton

Last night, somewhere in North London, a hollow object was launched from the secret base of the Web Forms 2.0 for Internet Explorer project. In a perfect parabola, the object crossed the ocean, entered the airspace of the United States, and landed squarely on my head. Boink.

Total volume

A measly 1.24Gb in my hard drive, around 200 CDs in my car. Yeah, I know.

Song playing right now

Morning birds chirping outside. That’s not really a song, that’s the actual birds making their birds sounds. Which reminds me of this joke:

A cowboy is sitting in a bar. Suddenly, a monkey runs up to his glass and ehm.. urinates into it. Dumbstruck, the cowboy jumps off his stool and barks, pulling out his gun: “What tha..!? Whose monkey is it?!”. Bartender looks to the piano, where the musician is working his magic, unaware of the developing situation. “Your monkey peed in my scotch!”, the cowboy roars in rage at the musician. Catching the barrel of a gun with the corner of his eye, the poor guy frantically scrambles to the keys: “I think I know this one! Yeah, I’ve got it! Your mo-oonkey peed in my scotch! Your mo-oonkey peed in my scotch!”

Five songs (albums) I listen to a lot or that mean a lot to me

  • Eternal Sailor — Peresvet
  • We are the Robots — Kraftwerk
  • Luminitza — Balanescu Quartet
  • Front 242 — Up evil
  • Journey of Dreams — Ladysmith Black Mambaza

Five people to whom I am passing the baton

TILT: How to Stop Feeling Bad About Using Tables for Layout and Start Enjoying Your Markup

You must be really living out in the sticks if you haven’t heard by now that using HTML tables for layout is bad. Markup is for content, CSS is for presentation, we learned.

You must be living in the land of magic mushrooms if you haven’t realized by now that making CSS do exactly what you want is easier said than done.

See, in the ideal, happy-go-lucky world, everything is just right. The content, custom-tailored by suave professional markup writers, fits perfectly into the widths and proportions of your template. The browsers support standards at exactly the same level and in exactly the same way.

Too bad we don’t live in Mayberry. With the loony Czar “The Exasperating” CSS 1.50304 ruling the presentational realm, it is surprisingly hard to build templates that are not brittle. Even The Man himself is battling with the idiosyncrasies of the dominant Web browser. And he’s the sole content contributor to the site! What if the entries were written and posted by someone who neither knows nor cares about the quality of markup, which last time I checked, is the absolute majority of your typical content contributors?

The issue becomes even more complicated when the layout is fluid, because its exact sizes are not known at any given time. And when the business requirements call for more sophisticated visual concepts than your typical “two-column”, “three-column”, and “three-column with coke and fries”, it becomes clear that the old Czar alone may not be able to hold the kingdom together.

The “Stretchy Pants” test

One of my favorite TV characters, Frank Barone of “Everybody Loves Raymond”, was ecstatic to finally find a pair of slacks that fit just right his lesser than strapping figure. Nevermind that his wife Marie had secretly purchased them at a maternity store — Frank loved his “stretchy pants”, in which his beer-drinking, cannelloni-devouring gut would never feel too tight. In a very similar manner, your layout must accommodate the fact that the content may sometimes grow a bit of cellulite here and there. Therefore, in order to be deemed ready for the real world, any page layout must withstand this simple test:

In each area of the layout that will have changing content, place markup whose presentation exceeds the width and/or height that is originally allocated for the area. Doing so must not cause the areas to:

  • Rearrange and change (break) the layout
  • Bleed one over another
  • Hide content of other areas.

This condition should still hold true if the browser window is resized to any width or height.

The ones with the heightened usability sense would add that these changes must also not trigger the appearance of in-page scrollbars. Go ahead and play with the pure CSS-driven sites. Download the source code of their pages, test it. View these pages in IE, view them in Mozilla, maybe even check them out in Opera. You will see that hardly any of them pass the test. In fact, if you find one that passes it and has more than one column, let me know.

The secret that CSS gurus have been trying to hide from you

But guess what? The table-driven layouts (if designed properly) pass the “stretchy pants” test with flying colors. Perhaps nobody enunciated the issue better than Andy Budd and Dave Shea in their insurgent strike against us structural markup purists: tables are bad, but they may be necessary to keep the layout intact in real-life conditions. Olav Junker sums up the problem in his comments:

CSS is perfect for basically single-column layouts. Secondary blocks like sidebars can be placed outside the main column with float. This solves the layout requirements of many websites, but requires the designer to rethink the layout as column-based rather that grid-based. It’s not just a case of moving some attributes into a slightly different CSS syntax.

However, sometimes you really need blocks aligned in two dimensions. You can emulate it with positioning and fixed sizes, but this will not, like tables, adjust gracefully if content is changed.

So my point is, it’s not a case of CSS being harder to learn and tables beeing more familiar (the same could be said of font-tags then, but i dont think many uses them any more), its a case of CSS not supporting 2D grid-layouts.

As painful as it is to admit, the amalgamation of rendering engines that’s currently available on the market simply does not provide a robust enough implementation of the 2-dimensional layout grid. You can float and slide your divs and spans all you want — these hacks will still remain hacks, because they only provide a simulation of the layout that’s aced by those darn tables.

We can rebuild him. We have the technology

So, what’s the solution? How do we keep provide a 2-dimensional grid to support the layout of our markup structurally correct markup? Well, how about this: let’s augment the rendering engine with the missing layout capabilities.

Huh? Are we trying to build a new browser now? Hopefully not. Just want to improve the existing ones with a slight twist of Javascript. Pull out the old trusty blade of client-side scripting to enforce the placement of your content areas in a 2-dimensional grid. Many of you ‘scripters probably just saw an elaborate mesh of “onresizes” and hidden iframes to account for various size changes flash before your eyes. No, it’s actually much simpler than that. Let’s think for a second. Don’t we already have a nice logic that does exactly what we need and is already build right into each and every one browser on this planet? Let’s see, what do we call those…? Tables, was it? You betcha.

The gory details

Here’s the gist of the technique: using standard DOM methods, inject a table where it is needed to support layout. Let’s use this composition as an example. Now, you fancy design folk might start pooh-poohing the awful choice of colors and lack of style, but let’s try to keep our focus on the topic.

First, we write the markup for the content and its structure:

  <div id="Page">
   <h1 class="Title">Your Company Name</h1>
   <ul class="Tools">
     <a href="#">Home</a>
     <a href="#">Site Map</a>
     <a href="#">Search</a>
     <a href="#">Contact Us</a>
   <div class="Content">
     Lorem ipsum etc ...
   <ul class="Links">
     <a href="#">Related Link</a>
     <a href="#">Another Related Link</a>
     <a href="#">Vaguely Relevant Link</a>
     <a href="#">Just some link</a>

Next, we inject our tables:

  var page = document.getElementById("Page");
  var pageItems = new ClassNameBag(page);
  var pageTable = new LayoutTable(2, 2);
  pageTable.appendChild(1, 1, pageItems.Title);
  pageTable.appendChild(2, 1, pageItems.Tools);
  pageTable.appendChild(1, 2, pageItems.Content);
  pageTable.appendChild(2, 2, pageItems.Links);

And finally, we use CSS to complete the composition. Looks simple enough? Let’s examine the injection code line by line. Line 1 should be pretty self-explanatory: the element by id of “Page” is retrieved. Basically, we grab the root of the DOM tree that represents mentioned above markup.

Line 2 is just creating a ClassNameBag instance, which doesn’t relate to the technique directly, but is useful, because it creates an object with properties, each containing the child of the element, supplied as a constructor argument, and named after the child’s class name. Now, for instance, I can access <ul class="Links"> element simply as pageItems.Links.

On Line 3, the actual injection magic begins: a new object named LayoutTable is instantiated. The LayoutTable encapsulates the “to-be-injected” table and its constructor has the following signature: LayoutTable(columnCount, rowCount [, className]), where columnCount and rowCount specify how many columns and rows, correpondingly the table will contain, and the optional className parameter allows to add an extra class name qualifier to table’s “class” attribute (which already has “Layout” class name assigned by default).

The LayoutTable provides nprovides a single method appendChild(column, row, node), which is similar to your typical element.appendChild method, except it appends the element, supplied in the node argument in the specified row and column of the table. Lines 4-7 distribute the contents of the Page element to their corresponding locations in the 2D grid (a.k.a. layout table).

And finally, on Line 8 we attach the layout table back to the Page element. The LayoutTable has one property node, which contains the actual DOM node of the table that was built with the code above. At this point, the injection is complete, and the table becomes part of the DOM.

In order to allow for more styling flexibility, each table row is given className of “ry“, where y is the number of the row (“r1” and “r2” in our example), and table each cell is assigned className of “cx“, where x is the number of the column (“c1” and “c2” for our table). This simple naming trick lets us control the presentation of rows, columns, or even individual cells in the layout table. For instance, “table.Layout tr.r1” will select the whole row 1, “table.Layout td.c2” will select the column 1, and “table.Layout tr.r1 td.c2” selects just the second cell of the first row.

Suddenly, CSS and tables are friends again. The old nemesis of structural markup comes back to the good guys’ side and saves the day. The barriers are broken, problems are solved, the happy end ensues, and tears of delight flow down the cheeks of sentimental readers.

What’s your name, stranger?

Now hang on just a second. Obviously, we have a technique here. And as far as I can tell, nobody had named it yet. Maybe I should try my hand at the Four-Letter Moniker Wheel of Fortune. Let’s see here… It’s a Table Injection Technique! Well, that’s only three letters and a couple of notches past PG-13. How about this: BOTOX, a quick way to smooth over nasty old wrinkles by injecting normally toxic stuff into the facial area of your page. Clever, but nah… I can just smell the lawyers circling around my head with this one.

Wait, wait.. I think I got it. The Table Injection for Layout Technique, or TILT! Woo wee! I think I just got me my own 4-letter abbreviation! Yup, TILT it is. Are you ready to TILT it?

Surgeon general’s warning

Just like anything that sounds too good to be true, TILT comes at a certain price.

  • Using client-side scripting to add extra layout functionality to your browser’s rendering engine requires, uhm, client-side scripting, which may or may not be available on the browser of your visitor.
  • TILT modifies the DOM tree of the page, which is something that has to be accounted for if you are doing DOM work for other purposes.
  • Using tables for layout while keeping the markup clean is addictive and may lead to inexplicable waves of feeling joy and urge to hug and kiss co-workers and even total strangers.

Ok, maybe not the last one. However, when all said and done, this technique definitely deserves a good look. It has potential of making your hacking with CSS columns and floats obsolete and clearing up the way for you to actually starting to enjoy your markup.

Graphics and Structural Markup: Keeping “pretties” out of content

Pet peeve time! Let's talk graphics. You know, the catchy visual dujibobs that have been part of the Internet since the Gopher went south. As far as I know, there are only two types of graphics on the Web: content graphics and presentational graphics.

  • Content graphics comprise the content of the page or serve as illustration for text content. For example, a news story on nuclear research breakthrough may feature a photo of a glowing (pardon the bad pun) scientist in a hazmat suit. A page containing a gallery of pictures with cut lines could serve as another example of images as content.
  • Presentational graphics serve the decorative purposes of a page. Typically, these are ingredients for what you'd call "page template" – they survive, with some degree of consistency, from page to page on a site. Taking away or changing the presentational graphics does not affect the content of the page. The nice white-space background texture that makes your eyes feel happy, or the heading that expresses the spirit of the site, or rounded corners that give your sidebars the look of a candy bar – all of the above are presentational graphics.

Another, less obvious example of presentational graphics is using images to convey textual information. Very often, Web sites can be found using titling (and sometimes more) that is rendered as images. See, text looks much better when kerned by hand and licked clean with anti-aliasing in Photoshop in a font that's something other than the common serifs and sans-serifs given to us by Web gods. And in the absence of a standard font delivery/rendering mechanism, provided by CSS or (X)HTML, developers use ye olde GIFs to compensate.

However, as I mentioned earlier, these images are context, not content. Why? Well, because from the perspective of content, we could care less about how it looks. We just want information. The "pretty" part is thus presentational, and only the actual textual information that is represented by the image is content. Can't decide who you really are, eh?

Images and structural markup

Obviously, presentational graphics have no place in structural markup. Only content graphics deserve to have their own designated image elements in the markup. The rest will have to take a ride on a CSS bus. Luckily, the color and background family of properties gives you more than enough flexibility in accomplishing that, and A List Apart is a good starting place in getting a taste of common techniques.

What of that MPD-afflicted "text as graphic" case? If we tuck our graphical titling into CSS backgrounds, we hide content in the presentational land, because these graphics contain textual information. If we make them into image elements, we have presentational elements in the content, which is even worse. What shall one do?

Because the initial reason for having text as graphics is due to incomplete rendering paradigm, there is no perfect solution. But there are a few that come pretty darn close. I am talking about the family of image replacement techniques. They all approach the issue from the same angle: textual information is marked up as text, but replaced with images using clever hacking with CSS, client- or server-side rendering. That way, the markup stays structurally correct, and the layout engine of the browser is augmented with new capability to make the text look more appealing. The major limitation of these techniques is that they're hacks, and like any hack, each technique has it Achilles' heel:

  • Static image replacement (FIR being the first, Leahy being my current favorite) still requires you to break out your Photoshop if the text information in the images changes.
  • Client-side dynamic image replacement (sIFR is the best example) has additional expectations on technology support (Flash is required), does not provide enough presentational flexibility (you can't hand-kern something that's generated on-the-fly), and may have accessibility problems (try reading sIFR-enabled page with the latest version of JAWS).
  • Server-side dynamic image replacement (DTR comes to mind) places extra computational burden on the server and has the same flexibility and, to a lesser degree, accessibility issues as its client-side counterpart.

However imperfect, image replacement is an enabling technology. Without it, presentational aspects of the page would have been the sacrificial lamb of structurally-correct markup. I doubt structural markup would've had a chance of making it to the mainstream.

Brand is content?

Very often, it is tempting to regard branding elements on a page as presentational. Branding elements are part of the letterhead, not the letter itself (letterhead being the presentational part of the page, of course). But in reality, the situation is a little trickier. In most cases, brand is as important as content on the page and deserves to be counted as content. Here are a few examples:

  • Point: The university seal is often used on a page to signify that the content comes from official university sources. Removing the seal from content diminishes the authority of the page. Thus, the seal is content.

    Counterpoint: This is the case of mistaken identity. The seal itself is not content. The content is the phrase "This page is part of the official university content", which is implicitly stated by the presence of the seal.

  • Point: The logo of a company on a page was re-colored to match the theme of the page, has been given gradient fill and a drop shadow to make it look "pretty". Anything "pretty" is part of presentation, thus making the logo a presentational graphic.

    Counterpoint: The changes in logo appearance are indeed presentational. However, being the unique mark (title) of the company, the unaltered logo itself is still content. Therefore, the unaltered logo graphic may be part of page content, only to be later replaced by the spruced-up presentational version. Think of it as using image replacement technique for an image.

Hyperlinkin' graphics

Web wouldn't be Web without hyperlinks. Those pesky anchor elements define the essence of surfing, the brand new user experience that was born with the Web. Many times, the item that the Web surfer clicks on is a graphic. Now, quick: is this a presentational graphic or content?

To answer this question, let's examine the nature of a hyperlink. A hyperlink is a way to link from one page to another, which identifies the target of the link on the page that's the link's starting point. Naturally, identification of this link is content.

Yes, but what kind of content? As any of known accessibility guidelines (WCAG, Section 508, etc.) would tell us, this content must be textual in order to be interpretable in absence of the agent that supports visual content. Therefore, from the perspective of user experience, the textual nature of the link is more important than its visual representation.

This means that any graph
ics that are part of hyperlink are probably presentational
. They are there to make the link look "nice" or "pop", not to identify the target of the link.

Comrade, what about my image maps?

Image maps are about as evil as you can get from the perspective of structural markup. Think about it: it's a markup construct that was devised to arrange links (content) on a graphic using 2-dimensional, pixel-oriented system of coordinates, which is as presentational as you can get. Stay away from the image maps, they are the heathen borne from Devil's womb. Especially, since you already have a presentational vehicle such as CSS.

Rules of Thumb

  • The image is definitely content, if
    1. It is referred to in the textual content. For instance, "This diagram depicts the relationship between good and evil (see figure 1)"
    2. If removed from the page, affects the value of content
  • The image is probably content, if
    1. It was created specifically for this page
    2. It is unique for this page
  • The image is probably presentational, if:
    1. It's clickable
    2. It was borrowed from stock library
    3. It is present on multiple pages with a degree of consistency
    4. It lends itself better to a GIF format
  • The image is more than likely presentational, if:
    1. If removed from the page, does not affect the value of content
    2. It contains textual information that would be considered content if it were just text.

Image element Quiz 1

Following the spirit of this article, how many image elements will you need to develop markup for the following composition?

Quiz 1

Image element Quiz 2

Think of what XHTML markup you would write for the composition below. Specifically, what would you use to express the icons (I assume it's obvious that they are clickable)?

Markup Quiz 2

Image element Quiz 3

Visit the following Web sites, view their source and point out images are incorrectly marked up as their own elements:

Note to the user from the utopian future: If you are looking at my page and can't find any examples of bad structural markup, you bring me the happy thought that I finally did find time to redesign my site. If you can't find anything wrong with any of the Web sites listed, you are either overlooking something or the future is looking so bright that I might just have to get me a pair of shades.

With any luck, this article shares your current thinking. Or maybe it gave you something to argue about (that's what the comment form at the bottom is for). In either case, next time you code presentational graphics as image elements, I hope you see it as adding ugly warts to the beautiful face of your Web site.