About this site's lack of design: Yes, it's supposed to look this way — I'm helping create a new sandbox theme for WordPress (see it on GitHub).

Dan Rubin's SuperfluousBanter

Suffering from chronic idiocy since 1977

Archive for August, 2008

Regex Patterns for Single Line CSS

Friday, August 29th, 2008

Update: You can now down­load the Text­mate macro file rather than record­ing your own (skip to the down­load »).

There has been plenty of dis­cus­sion about the pros and cons of single-line style sheets, and I’ve been includ­ing them as an option when teach­ing CSS man­age­ment and orga­ni­za­tion in my Web Design World pre­sen­ta­tions in Chicago, Seat­tle, and later this year in Las Vegas (at Web­Builder) and Boston.

It’s a mat­ter of preference

As a fel­low Side­bar–ian (Side­bar­bar­ian?) Steve has been try­ing to con­vince me to use the single-line approach for a while of course, and Bryan and Jon have also become fans of this for­mat­ting style for their own work. Although they are enam­ored with it, I haven’t taken to it yet, still pre­fer­ring to write my style sheets using the “nor­mal” indented for­mat­ting most of us are used to.

Now, before any­one gets their knick­ers in a twist about why they love, hate, “can’t live with­out” or “will die before they try” single-line for­mat­ting, let’s just take a step back and remem­ber one thing: it isn’t any­thing spe­cial, just an alter­nate for­mat­ting style that doesn’t affect the way the browser inter­prets the style sheet one iota. It’s a per­sonal preference—remember that before jump­ing on or off this par­tic­u­lar bandwagon.

Always keep your options open

Now that I’ve got that out of my sys­tem, let’s talk prac­ti­cal­ity: there are indeed ben­e­fits to be had when using single-line CSS formatting—for exam­ple, I find it can make a dif­fer­ence after a project has been com­pleted, at which point I’m usu­ally more inter­ested in visu­ally scan­ning a style sheet for the selec­tors first, and then for a par­tic­u­lar prop­erty I’m inter­ested in edit­ing. This is where I’ve found single-line for­mat­ting can come in handy.

But my edi­tor already does that!

This is the point where some peo­ple will start going on about how you could just use Textmate’s “fold­ings” fea­ture to get the same visual result (with­out alter­ing your file), or how CSS Edit has a handy list of all the selec­tors in a col­umn on the left side of its win­dow, or that you could always use your editor’s “find” com­mand and search for the selec­tor you want to edit. Yet while those are all per­fectly log­i­cal, sane sug­ges­tions, they don’t account for flex­i­bil­ity and choice.

Just another way of doing things

Much like Jon Hicks with his harem of web browsers, I tend to be a bit of a “text edi­tor polyg­a­mist”, bounc­ing from Text­mate to CSS Edit to Coda to BBE­dit to Transmit’s text edi­tor and a host of CLI edi­tors, mostly depend­ing on my mood (though some­times con­tex­tual if I’m at a com­puter that doesn’t have a par­tic­u­lar application—a Win­dowsXP box with noth­ing but Notepad, for instance). It’s the times when I’m using an edi­tor that doesn’t have “fold­ings” or pretty columns of selec­tors that I start to appre­ci­ate single-line CSS when mak­ing quick edits, so I’ve started con­vert­ing style sheets to a “sim­ple” single-line for­mat (with­out the left-aligned tab blocks to start each rule’s prop­er­ties) once they are ready to go live.

Pat­terns fit for a kilt

Edi­tors like Text­mate and BBE­dit have built-in com­mands for for­mat­ting (the stan­dard, multi-line approach) or com­press­ing (the entire style sheet on one line, osten­si­bly to reduce file size by strip­ping white space) CSS, but no way to con­vert to single-line for­mat­ting and Textmate’s “For­mat CSS Com­pressed” bun­dle can for­mat your stylesheet to a sin­gle line per-rule, though it’s all squished together, mak­ing it dif­fi­cult to scan due to a lack of white­space. Con­vert­ing a style sheet by hand every time would be much too time-consuming to bother with, but that’s where reg­u­lar expres­sions come to the rescue.

In Text­mate, you can record a macro using each of these regex pat­terns as a sep­a­rate step (I’m sure other edi­tors have a sim­i­lar fea­ture, so please feel free to post details in the com­ments below). This allowed me to cre­ate a “For­mat CSS Single-line” com­mand, com­plete with a key­board short­cut, which enables an easy switch between multi– and single-line formatting.

Unfor­tu­nately, as of this writ­ing Text­mate macros can­not be exported and shared For those using Text­mate, get­ting the macro is a sim­ple mat­ter of down­load­ing, expand­ing and double-clicking this file:

While sim­i­lar to “For­mat CSS Com­pressed”, this macro retains a sin­gle blank line where your orig­i­nal con­tained two or more blank lines (help­ful if you group your rules), and adds white­space that matches my stan­dard for­mat­ting pref­er­ences (which I find makes it eas­ier to scan quickly). To switch between each for­mat­ting style, just run each com­mand in turn (via the Bun­dles menu or the key­board shortcuts).

How­ever, that wouldn’t be much use to every­one who doesn’t use Text­mate, so here are the respec­tive groups of regex I used for the conversion:

[ \t]+
[ \t]*,[ \t]*

What’s miss­ing

In Text­mate and BBE­dit I can return to multi-line for­mat­ting with a sin­gle com­mand, but that might not be as sim­ple in other edi­tors. What I’d love to see is a pair of shell scripts that con­vert from multi– to single-line and back, and pos­si­bly a web-based proces­sor that does the same (paste your style sheet into a textarea, select your for­mat­ting, hit “process” and the script pro­duces the result). If any­one would like to take on those tasks, I’ll hap­pily update this post to link to the prod­ucts of your labor.

And in the end…

If you’ve never tried single-line for­mat­ting, this makes it easy to exper­i­ment with­out com­mit­ting your­self (and I do rec­om­mend giv­ing it a try—you may be sur­prised once you’ve worked with it a few times).

Ulti­mately, because I can return to multi-line with a sin­gle com­mand my pri­mary text edi­tor should I ever feel like it, automat­ing the switch from multi– to single-line is a con­ve­nient way to get the ben­e­fits of single-line for­mat­ting with­out back­ing myself or my clients into a for­mat­ting corner.



Simple CSS Hover Tab Thingy

Tuesday, August 19th, 2008

Update: The orig­i­nal edit of this post and demo file didn’t quite work in IE6/7 (ok, didn’t work at all, really). That’s what you get when you rush and/or don’t care about cer­tain browsers :) See the com­ments for my quick expla­na­tion of the fix (the demo now works in FF2/3, Safari 2/3, Opera 9, and IE6/7).

Ok, so the name won’t win any awards, but let’s be hon­est: nei­ther will this mini-tutorial, or the idea itself (noth­ing ground­break­ing here, move along…). But after throw­ing together a quick lit­tle (you guessed it) hover/tab/thingy for my pre­vi­ous arti­cle, I thought I was fun enough to share, in case you find a need for it someday.

The usual suspects

The “thingy” in ques­tion is just a sim­ple unordered list, with each list item con­tain­ing an anchor and an image—we want the images in this case because I want them to dis­play in my RSS feed and for any­one who can’t (or chooses not to) view the styled ver­sion of this site.

Note: Feel free to ref­er­ence images in the stylesheet rather than inline if that suits your pur­poses. Because I know you need per­mis­sion, don’t you…

If you were too lazy to click the link to my pre­vi­ous arti­cle above (and who could blame you, really), here’s a quick demo page.

Mov­ing right along…

First, the markup (with URLs trun­cated to save trees):

<ul id="hover-tab-thingy">
  <li id="one"><a href="...">One <img ... /></a></li>
  <li id="two"><a href="...">Two <img ... /></a></li>
  <li id="three"><a href="...">Three <img ... /></a></li>

Sim­ple, unclut­tered, uncom­pli­cated. Just how I know you like it.

Next, the CSS—not quite as short as the markup, but that’s how the story often goes:

ul#hover-tab-thingy {
  height:498px; }
#hover-tab-thingy li {
  list-style:none; }
#hover-tab-thingy li a {
  padding:9px 21px;
  border-right:1px solid #fff; }
#hover-tab-thingy li a:hover {
  color:#fff; }
li#one a,
li#one a:hover {
  color:#555; }
#hover-tab-thingy li a img {
  border:3px solid #e5e5e5; }
li#one a img,
#hover-tab-thingy li a:hover img {
  margin-left:0; }
li#two a:hover img,
li#three a:hover img {
  border-color:#f60; }

This is all fairly straight­for­ward, so here are the high­lights that may help when dupli­cat­ing this on your own:

  1. The entire idea is that you have tabs that are each asso­ci­ated with con­tent (images in this case) which are made vis­i­ble when the user hov­ers over the tab. There are more things you could do with this, but that’s your job, grasshopper.
  2. The tabs are floated; the con­tent ele­ments (img in this case) clear the floats.
  3. The con­tent ele­ments are set to position:absolute, so they can appear in the same loca­tion for each tab. To accom­plish this, the ul is set to position:relative (in short: an absolutely posi­tioned ele­ment will be posi­tioned rel­a­tive to its near­est posi­tioned ancestor—see Doug Bowman’s great write up for more), and it’s prob­a­bly a good idea if the dimen­sions of your ul (the con­tainer for your con­tent) have a lot in com­mon with those of your con­tent elements.
  4. IE6 has a prob­lem revert­ing ele­ments that set display:block on :hover to their orig­i­nal state (e.g. display:none). To counter this, use a neg­a­tive left mar­gin as the default posi­tion­ing, and then set margin-left:0; on the hover state, which works in all mod­ern browsers.
  5. The width and height is spe­cific to my exam­ple (the dimen­sions of the images I used), ditto for the padding on the tabs and the top posi­tion­ing on the img ele­ments (to push them below the tabs). Bend them to your will.
  6. Every­one dies at the end of The Departed. Seri­ously, every­one. That should be the sub­ti­tle of the movie.

Oblig­a­tory wrap-up

This may be some­thing that you’ll find use for on a reg­u­lar basis—one of those tiny snip­pets of reusable “stuff” that you’ll be glad you don’t have to type every time. Or you’ll never need it because you can’t for the life of you think of any rea­son why you’d need to reveal some con­tent whilst hov­er­ing over a tab (I’m pretty much just paint­ing the sar­casm with a roller at this point…).

What­ever your future may hold, now you have some­thing you might not have had before, and that’s never a bad thing—unless we’re talk­ing about some sort of dis­ease, in which case…



I Need Some Spacing

Tuesday, August 19th, 2008

Way back in June over on Sub­trac­tion, Khoi pre­sented a tweaked ver­sion of the Gmail inter­face (and then a follow-up arti­cle regard­ing the feed­back on the first), improv­ing spac­ing and align­ment by mak­ing a few small but sig­nif­i­cant changes overall:

…by nor­mal­iz­ing the space between like ele­ments, align­ing ele­ments along sim­i­lar spa­tial planes, mod­er­ately increas­ing the space between stacked items and pay­ing atten­tion to how ele­ments are framed by neg­a­tive space, we can get what is, in my opin­ion, a sig­nif­i­cantly more attrac­tive Gmail inter­face.” Khoi Vinh

This is some­thing I’ve wanted to see for a while in Gmail, and in fact had pre­sented a few exam­ples last year (July 2007) as part of my inter­view process at Google (I really must write about my series of amaz­ing job inter­views last sum­mer, but I’ll leave that for another time). After reading—and commenting—on Khoi’s post, I had intended to pub­lish my vari­a­tion on Google’s mid-2007 inter­face, but as the ded­i­ca­tion to blog­ging con­tin­ues to elude me, this too fell a few pages back in the Mole­sk­ine to-do list—until now.

The Setup

I took a slightly dif­fer­ent approach than Khoi, though my goals were similar:

That last goal was impor­tant and acted as a guide to the rest: I wanted to present improve­ments that could be made right away with­out caus­ing a neg­a­tive reac­tion among Gmail users.

Rather than adjust the line height of the main mes­sage area, I decided to bring as many of the other ele­ments in line with that as I could. You’ll notice spac­ing improve­ments within each line how­ever, reclaim­ing some poorly used hor­i­zon­tal space. Like Khoi, I felt the mes­sage lines were a bit crowded, so to give the impres­sion of more room in those lines, I removed the grey hor­i­zon­tal lines between each item and allowed the back­ground color to bleed through (all they need is some separation—further empha­sis on those lines just adds weight). The result is that it feels like there’s a bit more space, with­out actu­ally adding any.

The main nav­i­ga­tion lost its under­lines (again, remov­ing unnec­es­sary visual weight—the “this is a link” cue is super­flu­ous here) and gained space (match­ing the base­line of the mes­sage list). The “Com­pose Mail” link got an extra high­light by way of a back­ground; the extra padding makes it the only nav­i­ga­tion item that doesn’t align with the base­line, but that also gives it a lit­tle more con­trast ver­ti­cally, thus it stands out more with­out hav­ing to scream for atten­tion. Less impor­tant text links within the mes­sage area were made slightly smaller (but kept their under­lines), and “Mark as read” was pulled out of the drop-down menu and given its own but­ton: I had spent a week or so watch­ing peo­ple use Gmail before doing this exer­cise, and that was the sec­ond most fre­quent action users needed (right behind “Delete”) but was hid­den in the drop-down.

Finally, all rounded cor­ners were cleaned up a bit, footer text was aligned to the base­line, and the mes­sage list was enclosed on the right side (maybe it’s just me, but it’s always bugged me how those lines just run right to the edge).

Reveal Already!

I’m still happy with how this turned out a year later, and it was well received by the Google inter­view crew. Com­pare the before and after images, and you’ll also notice that the improved spac­ing in this exam­ple actu­ally reduces the over­all height of the page, allow­ing two addi­tional mes­sage lines to fit in the space of the original.

Both Khoi’s and my realign leave almost all the orig­i­nal ele­ments of the inter­face intact—this is very impor­tant when mak­ing changes (even if only sug­gested ones) to such a pop­u­lar appli­ca­tion, and the same goes for any prod­uct, pub­li­ca­tion or web site that is part of a person’s daily routine.

Whether Gmail incor­po­rates any of these sug­ges­tions is out of our hands, but it’s still nice to have the chance to compare.

Note: many changes have already been made to the Gmail inter­face over the last year, and even in the last few months since Khoi posted his exam­ple. Not all are improve­ments, but at least someone’s mak­ing an attempt.