digitalBush

Over the years I've heard the phrase "semantic web" tossed around the Internet via blog posts, how-tos, and podcasts.  Even though I saw the phrase several hundred times, it just went right on by.  I mean, I know what the words say, but it actually hit home until the other day.  I was writing some angle brackets and all of a sudden I had an epiphany.

First, a quick definition of sematic courtesy of Wiktionary:

semantic: Of or relating to semantics or the meanings of words.

The application of this word to (x)html signifies defining meaning to your content. You see, (x)html is a document markup language.  It's grown over the years to accommodate changes in the web.   Some of the changes over the years have been good (like the new elements in html5) and some haven't been so good (the blink and marquee tags come to mind here). What we've been moving towards is a more clear separation of content(xhtml), design(css), and interaction(javascript).

The easiest way for me to explain semantic html is to talk about a few deprecated tags and their newer, more meaningful counterparts:

courtesy of Jesper Rønn-Jensen

• <b> is for bold.  Boldness is a visual characteristic, not a meaning. This element has been deprecated in favor of <strong>.  Even though strong is more verbose, it's easy to see in markup that this thing is important.  It's up to the designer to determine how strongness gets visualized.  It could be bold.  It could be red.  It could be red and bold.  Who cares?  Leave that to the designer. For the content creator, all that should matter is that it's important.
• <i> is for italic.  Once again, italic is a visual style.  This element has been deprecated in favor of <em> or emphasize.  I guess emphasize is a little too long for the w3c, so I just imagine the full word is still there.  Emphasis bears more meaning than italicize.  The designer might want to emphasize you emphasis by making it 20pt comic sans with green text on a purple background.  Leave that to the designer.

You may be reading this with a "Well Duh" feeling, and that's fine.  What I'm saying isn't earth shattering.  This is just my reminder why I don't want to litter my markup with something silly like a "left" and "right" class.  If I start to want to go that direction, I just ask myself: "Self, why do you want that element floated to the right of the screen?"  Once I have that answer, I have a better class name that bears more meaning.

I'm not too much of a table hater.  Tables in your HTML have their place, and they do what they were designed to do well.  They display tabular data with ease and relatively straightforward markup.  Tables work the way they work, and there are generally very few surprises between the various browsers.  With that said, I'm not a huge fan of tables being used for layout.  I like clean markup, and using a table for small bits of information just looks bad, at least to my eye.

One day, for whatever reason, I right clicked on the front page of Stack Overflow, only to be greeted with this:

<div onclick="javascript:window.location.href='/questions/620476/can-someone-tell-me-why-my-div-buttons-wont-resize'">
	<div class="votes">
		<table width="100%">
			<tr><td class="mini-counts">0</td></tr>
			<tr><td>votes</td></tr>
		</table>
	</div>
	<div class="status answered">
		<table width="100%">
			<tr><td class="mini-counts">3</td></tr>
			<tr><td>answers</td></tr>
		</table>
	</div>
	<div class="views">
		<table width="100%">
			<tr><td class="mini-counts">40</td></tr>
			<tr><td>views</td></tr>
		</table>
	</div>
</div>

That's 3 tables to display the following area, which is repeated nearly 50 times on the front page.

stack overflow front page

So I fired off an email to Jeff Atwood explaining to him that just by changing those heavy tables to divs that he would realize a 15K savings per page. Normally, I wouldn't blink at 15K for one of my sites. My sites don't get much traffic. But, for a site like Stack Overflow which has 500,000+ page views per day, that 15K can add up fast. Jeff quickly responded with the reasoning for their decision: "Vertical alignment is something that divs do extremely poorly."

Damn, I neglected to notice the vertical centering.  But, I knew that I could still make it work.  My first attempt to make this work involved nested divs with neagtive margin.  The markup looked like crap and wasn't working well in all of the browsers for me.  Then it hit me, this is just text.  What does the "line-height" css property do?  BAM!  The text was centering vertically and the markup looks nice.  I fired that off to Jeff, he got it integrated into a dev build to test the browsers, and off it went to production.

Now the markup looks like this:

<div onclick="javascript:window.location.href='/questions/514420/how-to-validate-numeric-input-c'" style="cursor:pointer">
	<div class="votes">
	    <div class="mini-counts">2</div>
	    <div>votes</div>
	</div>
	<div class="status answered-accepted" title="one of the answers was accepted as the correct answer">
	    <div class="mini-counts">5</div>
	    <div>answers</div>
	</div>
	<div class="views">
	    <div class="mini-counts">309</div>
	    <div>views</div>
	</div>
</div>

There, doesn't that look better?  I think so. I'm just glad I was able to see an issue, offer a solution, and get my voice heard.  There it is, my small contribution to Stack Overflow.  I hope they are realizing some bandwidth savings from that smaller markup.  Without hard numbers to go on, I'd say it's only a slight improvement after the content gets gzipped.

It still sucks that we have to play this game as web developers.  We're stuck compensating for the bad decisions of web browsers from 2001.  It's really easy to just fall back to tools we know really well, like tables.  Tables aren't bad.  Sometimes they just aren't the tool for the job.  The big bummer is that for 99% of us, it's a better use of our time to go ahead and use the clunky table markup to get something simple done in a timely manner.  There simply won't be enough people using our site(s) to realize any significant benefit from the extra effort to make things "right".   For those remaining 1%, the extra effort to get things right can be worth something. That's just wrong.  It's easier to do things the "wrong" way because the "right" way doesn't work everywhere and/or involves hacks to make it work.

It's worth noting that if you are a developer and aren't participating on stack overflow, then you are cutting yourself short.  It's a great place to find the answers you need and give a little back. Now I just need to get my rep up!