Dan Rubin's SuperfluousBanter

The Art of Washing Forks

This item was posted by Dan Rubin on Friday, October 9th, 2009.

Wash­ing a fork is a spe­cial skill, often requir­ing an exten­sive apprenticeship—usually at the hands of your mother, father, or skilled caregiver—and years of prac­ti­cal application.

If you don’t get it right, food will remain stuck between the tines. If there is food between the tines, the threat level is ele­vated to dis­gust­ing (aka “green”).

Many peo­ple leave food between the tines when they “wash” their forks. Many peo­ple also find a sink full of dishes dis­gust­ing. The dif­fer­ence between these groups, in my expe­ri­ence, looks some­thing like this:

I leave my sink full for weeks at a time. But when I wash my dishes, they are spot­less, right down to the space between the tines.

This behav­ior illus­trates how my brain func­tions: Extreme pro­cras­ti­na­tion, with per­verse atten­tion to detail at the time of execution.

This may also be the best way to under­stand the lack of love and affec­tion this blog site has received over the last year (or more). Blog­ging has become my sink: ideas pile up for days weeks months on end, while I spend time think­ing about redesign­ing, refo­cus­ing, and clean­ing things up in gen­eral. As the site con­tin­ues to be ignored, strange things begin to grow between the tines creep into the exist­ing site design, or sim­ply break outright.

A site can only lie dor­mant for so long before peo­ple write it off, much like a fork can only sit in a glass of water for a cer­tain period of time before it starts to rust and cor­rode. How­ever, an author must also be inspired by his envi­ron­ment, and some­times, when that envi­ron­ment ceases to inspire, the process of cre­at­ing a new one can take a lot of scrub­bing and elbow grease.

Trust me: when I’m ready, the tines will be spotless.

Categories:

• Uncategorized

3 Comments

The Final Word on IE6

This item was posted by Dan Rubin on Wednesday, September 3rd, 2008.

A friend of mine recently asked the ques­tion “Why the Hate on Inter­net Explorer 6?” He explains some very log­i­cal rea­sons why it doesn’t make sense to be so neg­a­tive about IE6, and as I agree with him on just about all points, I thought I’d give the clear­est answer I could.

Sim­ply put, IE6 shouldn’t get any hate. Nor should it receive any love, either.

The best thing the web stan­dards com­mu­nity (and any other smart web folk) can do is stop com­plain­ing about an ancient browser whose devel­oper waited too long to replace, and just stop sup­port­ing it altogether.

One of the ben­e­fits of web stan­dards is that our doc­u­ments are marked up cor­rectly before we reach the pre­sen­ta­tional stage. One of the ben­e­fits of IE6 (et al) is that we can tar­get spe­cific ver­sions using Con­di­tional Com­ments. The com­bi­na­tion of the two means we can still send our con­tent to old browsers, but not have to bother with the pre­sen­ta­tion, thus sav­ing our­selves hours of need­less headaches and frus­tra­tions, while not pun­ish­ing the users of said old browsers by deny­ing them access to our content.

There’s con­stant dis­cus­sion about whether or not to con­tinue sup­port for IE6, and the only rea­son ever given these days in favor of sup­port­ing that browser is its mar­ket share. That mar­ket share is dimin­ish­ing, and we’ve already reached the sec­ond beta of IE8, so let’s start drop­ping it already. Make the argu­ment against sup­port­ing IE6, to your clients, your boss, your team—whoever needs to hear it, keep apply­ing pres­sure and don’t back down.

It’s time to stop sup­port­ing IE6. Period.

Categories:

• CSS
• Internet
• Technology
• Web Standards

55 Comments

Regex Patterns for Single Line CSS

This item was posted by Dan Rubin on 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:

• Down­load the “For­mat CSS Single-line” Text­mate macro » (ZIP, 1KB)

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:

\n{3,}
\n\n
 
[ \t]+
 
(?m)([;:])\s+
$1
 
\s*}
 }
 
\s*{\s*
 { 
 
[ \t]*,[ \t]*
,
 
@import(.*?);
@import$1;\n\n

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.

Categories:

• CSS

62 Comments

Simple CSS Hover Tab Thingy

This item was posted by Dan Rubin on 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):

1
2
3
4
5

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

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:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

ul#hover-tab-thingy {
  position:relative;
  padding:0;
  width:500px;
  height:498px; }
#hover-tab-thingy li {
  float:left;
  list-style:none; }
#hover-tab-thingy li a {
  float:left;
  padding:9px 21px;
  background-color:#eee;
  color:#999;
  font-size:9px;
  text-align:center;
  text-transform:uppercase;
  border-right:1px solid #fff; }
#hover-tab-thingy li a:hover {
  background-color:#f60;
  color:#fff; }
li#one a,
li#one a:hover {
  background-color:#e5e5e5;
  color:#555; }
#hover-tab-thingy li a img {
  position:absolute;
  left:0;
  top:30px;
  width:500px;
  height:460px;
  clear:left;
  margin-left:-9999px;
  padding:1px;
  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…

Categories:

• CSS

14 Comments

I Need Some Spacing

This item was posted by Dan Rubin on 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:

• Give all ele­ments more room to breathe
• Make it eas­ier to tar­get nav­i­ga­tion and oft-used links
• Nor­mal­ize align­ment of text and other elements
• Do it all with­out dras­ti­cally alter­ing the appear­ance of the interface

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!

• Before
• After
• After (with baseline)

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.

Categories:

• Design

12 Comments