5 Ways to Style dl

Recently I lamented the rare usage of the supremely useful directory list, dl. The directory list is a pretty common data structure: one heading, followed by one or more related subsidiary data. It’s appropriate for more situations than it’s used for, probably because so many developers fixate on markup’s visual design rather than its information design. Browser defaults for dl obscure its versatility:

Firefox default for dl
Firefox default for dl

But there are so many occasions for which dl is the obvious data structure, once groomed by applicable CSS styling. As end users adopt standards-compliant browsers with better support for CSS 2+, styling dl into recognizable data structures becomes nearly fun, and will tempt you to try the ridiculous.

For instance, dl adapts readily to become the container for a recipe:

dl as recipe
dl as recipe

The CSS for achieving this assumes that you’re using one of those newfangled browsers with excellent support for CSS 2+:


dd {
display: inline;
margin: 0 .25em 0 0;
}
dd:before { content: " First, "; }
dd:after { content: ".  "; }
dd+dd:before { content: "Then, "; }
dd+dd+dd:before { content: "Finally, "; }

There’s a similar mechanism for forming dl into a citation:

dl as citation
dl as citation

CSS:


dt { font-weight: 700; }
dt:after { content: ":"; }
dt, dt:after, dd { display: inline; }
dd { margin: 0; }
dd:after { content: ","; padding-right: .25em; }
dl dd:last-child:after { content: "."; }

dl is, semantically, a good choice for an accordion menu, with a CSS :hover or JavaScript event attached to dt:

accordion, collapsed
accordion, collapsed
accordion, active
accordion, active

CSS:


dt {
font-weight: 700;
}
dt:after { content: "\203A"; padding-left: .25em;}
dd { margin-left: 0; visibility: hidden;}

dl:hover dt:after { content: "\2026"; }

dl:hover dd { visibility: visible; }

And then are ways to style dl which, yes, test the capabilities of CSS, but are just plain dumb. If, for instance, you feel compelled to style dl as a table or as a bulleted list, you should question why you’re using this particular markup, and not table or ul:

dl as table
dl as table
Picture 2
dl as bulleted list

The CSS for these stunts:


dl { display: table; }
dt {
display: table-caption;
font-weight: 700;
margin: 0;
text-align: center;
}

dd { border: 1px solid #eee; display:table-cell; margin: 0; padding: .25em; }

dd {
display: list-item;
list-style: disc;
}

Versatility, it’s a burden.

Review: JavaScript Performance Rocks!

by Thomas Fuchs and Amy Hoy
by Thomas Fuchs and Amy Hoy

Title:  JavaScript Performance Rocks!
Authors: Thomas Fuchs and Amy Hoy


Pros:
  • Concise, easy-to-follow advice with good examples
  • Some overlap with other treatments of the same subject, such as posts on Ajaxian or the Steve Souders books, which reinforces the learning
  • Download includes the DOM Monster bookmarklet, which assesses a given page for conformance with the book’s recommended techniques
Cons:
  • Casual,  breezy tone in the prose which is hard to tolerate for very long
  • Idiosyncratic landscape format for page layout; difficult to read onscreen, terrible for printing out

JavaScript Performance Rocks! is yet another indicator of front-end development’s new status as something worth improving.  The authors examine where the scripting on a Web application interface frustrates or thwarts the user, and offer techniques either to speed up JavaScript rendering by various browsers, or to manage the user’s perception of that speed.  Some of the techniques will seem familiar if you have read much about JavaScript performance in the last two or three years–the greatest benefit this book gives you is having all that lore in one place, with justifications if you need to supply them when you use these on a project.

As of this writing, JavaScript Performance Rocks! is in beta.  When you purchase the download, you are assured of updates, which is necessary because some sections  remain incomplete.  I’m skeptical the final version will improve what I consider real problems with this book, which are in its prose and visual styling.   Both, I assume, are the results of the authors’ vision of delivering a technical book which would be fresh, hip, and not too serious.  Unfortunately, the youthful lingo wears–imagine having a hipster, like, totally, goin’ on about, you know, JavaScript? and you might experience the same impatience too many pages of this will give you.

More problematic is the book’s visual design.  I’ve looked several times at the landscape-oriented pages, trying to understand why they aren’t given the conventional portrait format.  I think the intention is that each page’s content falls “above the fold,” and the reader won’t need to scroll down to read it entirely.  However, on my monitor, this perfect layout only arrives when I reduce the page size in Acrobat Reader to 75%, which also reduces the fonts below my preferred level.   In any case, thinking of alternate presentations for this material is a needless distraction from it.

Included in your download of the beta is the marvelous DOM Monster utility.  If your questions about JavaScript performance concern an application you have already built, the DOM Monster gives you an easily comprehended diagnosis: where do you have too much whitespace?  Where are there empty nodes?  Do you have too many links to scripts and stylesheets?  I won’t be surprised to see this bookmarklet sold as its own product, given its immediate usefulness, but I’d be dismayed if developers used it without reading the accompanying text.  For, whatever its flaws, JavaScript Performance Rocks! comes highly recommended.  Like, all, hella recommended.  By me.

Finger Busting

The other night my husband and I indulged in some old-fashioned diversion by picking through our collection of 78 r.p.m. records, playing the selections on the 1947 Delco phonograph. He surprised me with a record I’d forgotten we had: Jelly Roll Morton, late in his career, playing Willie “The Lion” Smith’s “Finger Buster;” B-side, “Creepy Feeling.”

We listened to “Creepy Feeling” first. Here was all of Morton’s legendary talent in one side–the ragtime and jazz piano styles he excelled in and defined. We had great expectations for “Finger Buster.”

This piece was also rendered with impressive virtuosity, but ultimately left us cold. The point of it seemed to be for the pianist to cram as many notes into every moment as possible, a challenge Morton met and bested. But getting all those notes in meant he discarded tone, mood, contrast–almost everything that makes a piece of music memorable. “Finger Buster” had no hook.

I’m reminded of “Finger Buster” when I look at some of the ways people write JavaScript. I see cryptic, single-character variable names, rigid adherence to object literal syntax, disdain for whitespace and for comments. Some people seem to treat their applications as the Web equivalent to the Apollo moonshot: everything must be rigorously minimized, milliseconds shaved off like millimeters, as if, say, the rendering of the lightbox on the regional sales division’s intranet login has profound, mission-critical implications.

Still others want to impress with their scripts’ obscuring structure. They don’t want you to understand it readily; they don’t want to provide the f*cking manual for you to read. They want to dazzle you with their finger busters.

Okay, time for a test.

Quick: hum the riff for the Kingsmen’s “Louie Louie.” Now do the same for any of Steve Howe’s solos on Tales from Topographic Oceans. Maybe a few of us can do the latter, and some would even prefer it. I confess to a bone-deep dislike for prog rock, and admit bias for “Louie Louie.” I’m not alone–which recording do you think has great influence?


The Kingsmen, “Louie Louie”.


Steve Howe in 1971 BBC documentary.

A trick question. Both do. Punk arose in the 1970s from both emulation of the do-it-yourself, technically simple example of 1960s garage bands like the Kingsmen, and contempt for the pretentious, technically complex example of prog groups like Yes. The original punks knew finger busting really doesn’t signify great music. If the music can’t make its point quickly, if you need lots of post-production and exotic instruments and huge concert venues to create it, and if nobody can easily recall what it sounds like, then it’s failed–doesn’t matter how many notes it has.

It’s high time finger busting JavaScript met its punk counterbalance. Too many blog posts, presentations, framework docs, and lines of code seem written with complete disregard for the basics of communication, as if hoarding information makes the writer more powerful. Just as you don’t need conservatory training to make good music, you don’t need an MS in Computer Science to write good JavaScript. My stress is on “good”–is it good if nobody understands it? If nobody can reuse it, add on to it? No. Web development isn’t a cutting contest. Let’s save finger busting for novelty records.

I Still (Heart) RichInStyle

I’ve been perusing a lot of job postings, which is, I know, inefficient, if my goal is to find a job, but it’s interesting to see what employers are putting in their requirements.

More and more frequently I’m seeing a call for skill with frameworks–not just for Ruby on Rails or Prototype, but also for CSS. There are by now a few of these to choose from: the skins for the Yahoo! User Interface Library, Blueprint, Nicole Sullivan’s “Object Oriented CSS” (excellent work, but oh! for a less trendy name), and so on. All of them: good to use. But it depresses me that employers don’t want to hire someone who can develop CSS by hand.

Hand tailoring
Photo by Bradley Allen

I’ve barely used any of the frameworks; I haven’t needed to. I guess I’m like a Savile Row tailor in preferring to make my own measurements and to follow my own procedures. But I can’t really say “my own,” since I was the benefactor of other CSS developers, those who worked in the earliest days of the technique—Web 0.9?—and discovered its patterns.

One of these pioneers was Matthew Brealey, who contributed to the W3C CSS discussion list. In between posts he maintained RichInStyle, a one-man compendium of frontend development tips and tutorials; I had it bookmarked, if not always open in a separate browser window. Brealey somehow had the time to investigate the browser support for every proposal in the CSS 1 specification; generously, or self-aggrandizingly, he posted his findings.

He also devised a way of writing a stylesheet that, with few adjustments, I still use. Brealey’s “Masterclass” show signs of age (remember uppercase element names?), but outlines one of the most logical ways to write CSS I’ve seen yet.

A couple of his most enduring principles are, simply:

  1. Use the cascade. Start with the most general rules at the top (HTML elements), and only then follow with those for classes and IDs. Put the toughest cases–the most obstreperous browser hacks–at the bottom of the CSS text, processed last.This rule seems obvious, but I can’t believe how many stylesheets I see beginning with class or ID rules.
  2. Ease human usage of the stylesheet with alphabetization. Brealey wrote before we had Firebug, or even View Formatted Source. Yes, we were flying with instruments in those days; you never knew where that pesky text color was coming from, nor why your document’s h3s were in italics. But a stylesheet organized as Brealey proposed gave up its secrets more readily: the rule for h3, for instance, would be reliably beneath that for a and above that for p, and its font-style would be beneath border and above margin. Maybe the importance of this approach has diminished as far as debugging goes, but it still shows thoughtfulness, the developer’s hand.

Developed by hand, old-fashioned; an artifact, not a commodity. Sure, I’m biased in favor of hand-tailored CSS, but then I’ve seen nothing but benefits from its skilled usage. Note “skilled.” It’s thanks to Matthew Brealey and others like him that I know what that means.

In Praise of dl

Consider the task of delivering this:
heading-and-data

It’s a construct you’ll see everywhere on the Web: a text heading in bold type, with perhaps some background styling, and subsidiary text beneath it, often styled a little differently, such as in a lighter font style. The heading and the content beneath it seem to be related; visual design can give more evidence of that relationship with flourishes like the gray border enclosing the text blocks in the example above.

So how is this very ordinary construct expressed in HTML? Sadly, often in the most verbose, inflexible ways possible.

For instance:

<p>
	<strong>
		Heading
	</strong>
</p>
<p>
	Stuff under heading
</p>
<p>
	Stuff under heading
</p>
<p>
	Stuff under heading
</p>

Or:

<div class="heading">
		Heading
</div>
<div class="data">
	Stuff under heading
</div>
<div class="data">
	Stuff under heading
</div>
<div class="data">
	Stuff under heading
</div>

Or even (shudder):

<table>
	<tr>
		<th>
			Heading
		</th>
	</tr>
	<tr>
		<td>
			Stuff under heading
		</td>
	</tr>
	<tr>
		<td>
			Stuff under heading
		</td>
	</tr>
	<tr>
		<td>
			Stuff under heading
		</td>
	</tr>
</table>

Why? There’s an obvious solution in dl, which has been in the HTML specification since, for crying’ out loud, version 2.0. All you need to express this particular data structure are dl, its subsidiary elements, dt and dd, and basic CSS skills.

<dl>
	<dt>
		Heading
	</dt>
	<dd>
		[Stuff under heading-- 
		express each as paragraphs, list items, or other elements]
	</dd>
</dl>

Advantages of this approach include preserving an obvious heading/data relationship between those elements. If there is a situation in which your CSS does not render, user agent defaults will still indicate this relationship. For instance, in Firefox, the content enclosed in dd will have a slight indent from the left margin of dt. In screen readers, the dl will be announced as a definition list, and its numbers of items (dd) reported as well, which helps non-visual users understand where the list begins and ends.

Another advantage is flexibility in styling. There’s nothing intrinically presentational about dl, unlike strong or tr; indeed, you can make the same construct look very different with very simple CSS:

Three ways to style a definition list
Three ways to style a definition list

So why is this marvel of semantic markup so underused? Do we really prefer typing in strong? Is it human nature to take the long way? Has the div Element Marketing Association been extraordinarily successful?

Please tell me why.

5 Things I’m Doing Nowadays Instead of Working

So, you might’ve been spending the last year or so snoozing under a stalactite in Mammoth Cave, and completely missed the near-hourly utterance of the word “recession,” and now you’re a trite confused that so many millions of Americans with good educations, impressive experience, and opposable thumbs are unemployed. In fact, you could’ve surfaced a few months ago and been confronted with the same puzzler, even the same zombie battalion of former job holders. But not all of us are weathering the economic downturn with Red Vines and Snuggies. Some of us are keeping busy; almost too busy to work.

5 Things I’m Doing Nowadays Instead of Working

  1. Getting my command of JavaScript from 30 to 60. I can write state-of-the-art scripts—for 1998. Rather than continuing to embarrass myself with inline onclick handlers and overdependence on alert() for debugging, I’m devoting extra time to reading everything and anything written by Chris Heilmann and Peter-Paul Koch.
  2. Playing with all those advanced techniques customers never request. To date none of my clients have paid me to use any of the goodies from GitHub or Google Code or the multitude of promising APIs; instead, my workdays are devoted to treating float drops in IE 6 and the like. Now, with only myself to please, I can spend time on more challenging tasks at the keyboard.
  3. Thinking of going back to school. I spend much of my time reading about the built environment, and all of my time using it. I’ve been interested in architecture for many years, yet have no training in it; haven’t worked in the field at all. So what better time to seek retraining than the unbillable present?
  4. Avoiding the news. I stopped my hourly visits to the Web sites for the New York Times and the San Francisco papers because I suspected I was getting too distressed by the dismal stories I read there. I was right —my mood brightened once removed from the daily downbeat. I’m still informed of the things really important to me, and free from concern about those which aren’t.
  5. Going outside. One of the biggest stressors for me when I’m fully employed is that I’m not able to go outside very much during the daytime. Now, with no hypertensive project managers or overdemanding clients to rebuke me, I’m spending a lot of mid-days running, bicycling, or hiking. It’s a pity that work (unless you’re a bike messenger or park ranger) is so often structured to be incompatible with these activities, which are probably the easiest way to regain your enthusiasm for life.

What are you doing instead of working?

Ada Lovelace Day: the women of keypunch

Once upon a time, it was the year 1980.  Computers were regarded, vaguely, as something one should know more about, kind of like biotech at the present:  a guarantee of stable, well-paid employment to the person who was skilled with them.  What we considered computers seemed much more various than now—the devices included the Pong gaming console my dad bought at Sears, the mainframes down at the community college, the Commodore PETs in my junior high’s computer lab, and whatever it was that my friend Wendy’s mom had worked on using punched cards.

Back then, there was this joke about being “folded, spindled, or mutilated;” it was usually a metaphor for being mistreated by dour, inflexible bureaucrats. Most of us got the joke, both because we were all subject to bureaucracy, and because all of us had seen punched cards, pieces of tagboard also vulnerable to maiming by unfeeling entities.  Think of most large- or medium-scale processes, like assembling all the grades of the freshman class, or billing the customers of the gigantic Bell System: punched cards, and keypunch operators, were behind them.


Keypunch machine. Photo by inky

The keypunch operators were typically women.  The work was considered clerical, and paid less than technical work assumed by men.  The keypunch operators were nevertheless proud of their occupations, which held more status than being a secretary or nurse.  A smaller number of women were accepted as programmers, the ones who submitted the punched cards to the all-mighty computer.  Both roles required a greater degree of double-checking and focus than I think our jobs demand of us now:  there was no Command-Z to reverse a mistake.  They also seemed to pose a lot more physical discomfort:  noisier machines, nearly Arctic temperatures, and no Aeron chairs.

Yet the women I’ve met who were employed as operators or programmers during this era of computing still have positive memories of the experience.  They enjoyed having such esoteric skills.  They liked going to the customers’ sites and solving the customers’ problems.  They never considered their work incompatible with being feminine, or having lives outside work.  They don’t know why most of their own daughters and granddaughters didn’t jump into careers or degrees in computing.

I know why, at least in my case.  In 1980 my friend Wendy’s mom was explaining how to use a punched card program to one of my eighth-grade classmates—a boy.  And my junior high computer lab was filled with students from the Gifted program huddled around the keyboards and monitors—all of the students, boys.  The program director encouraged us girls to while away the hour in the band practice room instead.  We acquiesced; computers had acquired the stigma of being uncool, despite how diverting Pong could be.  Computers didn’t seem to do anything we found interesting, but we really didn’t get the time to investigate them too thoroughly: the boys in the lab made us feel too unwelcome.

What a tantalizing alternative history this would be, had we persisted.  Had the legacy of the keypunch operators become that of subsequent eras in technology —a tradition of female participation sustained, even considered commonplace.  Had computers become what they are today—ordinary appliances for use by all—but twenty or thirty years sooner.  What we be doing now?