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

The Art of Washing Forks

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

Washing a fork is a special skill, often requiring an extensive apprenticeship—usually at the hands of your mother, father, or skilled caregiver—and years of practical 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 elevated to disgusting (aka “green”).

Many people leave food between the tines when they “wash” their forks. Many people also find a sink full of dishes disgusting. The difference between these groups, in my experience, looks something like this:

Venn diagram showing an almost complete overlap of people who can't wash forks, and people who hate full sinks.

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

This behavior illustrates how my brain functions: Extreme procrastination, with perverse attention to detail at the time of execution.

This may also be the best way to understand the lack of love and affection this blog site has received over the last year (or more). Blogging has become my sink: ideas pile up for days weeks months on end, while I spend time thinking about redesigning, refocusing, and cleaning things up in general. As the site continues to be ignored, strange things begin to grow between the tines creep into the existing site design, or simply break outright.

A site can only lie dormant for so long before people write it off, much like a fork can only sit in a glass of water for a certain period of time before it starts to rust and corrode. However, an author must also be inspired by his environment, and sometimes, when that environment ceases to inspire, the process of creating a new one can take a lot of scrubbing and elbow grease.

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

Categories:

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 question “Why the Hate on Internet Explorer 6?” He explains some very logical reasons why it doesn’t make sense to be so negative about IE6, and as I agree with him on just about all points, I thought I’d give the clearest answer I could.

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

The best thing the web standards community (and any other smart web folk) can do is stop complaining about an ancient browser whose developer waited too long to replace, and just stop supporting it altogether.

One of the benefits of web standards is that our documents are marked up correctly before we reach the presentational stage. One of the benefits of IE6 (et al) is that we can target specific versions using Conditional Comments. The combination of the two means we can still send our content to old browsers, but not have to bother with the presentation, thus saving ourselves hours of needless headaches and frustrations, while not punishing the users of said old browsers by denying them access to our content.

There’s constant discussion about whether or not to continue support for IE6, and the only reason ever given these days in favor of supporting that browser is its market share. That market share is diminishing, and we’ve already reached the second beta of IE8, so let’s start dropping it already. Make the argument against supporting IE6, to your clients, your boss, your team—whoever needs to hear it, keep applying pressure and don’t back down.

It’s time to stop supporting IE6. Period.


This article has very kindly been translated to Serbo-Croatian language by Jovana Milutinovich from Webhostinggeeks.com.

Categories:

55 Comments

Regex Patterns for Single Line CSS

This item was posted by Dan Rubin on Friday, August 29th, 2008.

Update: You can now download the Textmate macro file rather than recording your own (skip to the download »).

There has been plenty of discussion about the pros and cons of single-line style sheets, and I’ve been including them as an option when teaching CSS management and organization in my Web Design World presentations in Chicago, Seattle, and later this year in Las Vegas (at WebBuilder) and Boston.

It’s a matter of preference

As a fellow Sidebar-ian (Sidebarbarian?) Steve has been trying to convince me to use the single-line approach for a while of course, and Bryan and Jon have also become fans of this formatting style for their own work. Although they are enamored with it, I haven’t taken to it yet, still preferring to write my style sheets using the “normal” indented formatting most of us are used to.

Now, before anyone gets their knickers in a twist about why they love, hate, “can’t live without” or “will die before they try” single-line formatting, let’s just take a step back and remember one thing: it isn’t anything special, just an alternate formatting style that doesn’t affect the way the browser interprets the style sheet one iota. It’s a personal preference—remember that before jumping on or off this particular bandwagon.

Always keep your options open

Now that I’ve got that out of my system, let’s talk practicality: there are indeed benefits to be had when using single-line CSS formatting—for example, I find it can make a difference after a project has been completed, at which point I’m usually more interested in visually scanning a style sheet for the selectors first, and then for a particular property I’m interested in editing. This is where I’ve found single-line formatting can come in handy.

But my editor already does that!

This is the point where some people will start going on about how you could just use Textmate’s “foldings” feature to get the same visual result (without altering your file), or how CSS Edit has a handy list of all the selectors in a column on the left side of its window, or that you could always use your editor’s “find” command and search for the selector you want to edit. Yet while those are all perfectly logical, sane suggestions, they don’t account for flexibility 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 editor polygamist”, bouncing from Textmate to CSS Edit to Coda to BBEdit to Transmit’s text editor and a host of CLI editors, mostly depending on my mood (though sometimes contextual if I’m at a computer that doesn’t have a particular application—a WindowsXP box with nothing but Notepad, for instance). It’s the times when I’m using an editor that doesn’t have “foldings” or pretty columns of selectors that I start to appreciate single-line CSS when making quick edits, so I’ve started converting style sheets to a “simple” single-line format (without the left-aligned tab blocks to start each rule’s properties) once they are ready to go live.

Patterns fit for a kilt

Editors like Textmate and BBEdit have built-in commands for formatting (the standard, multi-line approach) or compressing (the entire style sheet on one line, ostensibly to reduce file size by stripping white space) CSS, but no way to convert to single-line formatting and Textmate’s “Format CSS Compressed” bundle can format your stylesheet to a single line per-rule, though it’s all squished together, making it difficult to scan due to a lack of whitespace. Converting a style sheet by hand every time would be much too time-consuming to bother with, but that’s where regular expressions come to the rescue.

In Textmate, you can record a macro using each of these regex patterns as a separate step (I’m sure other editors have a similar feature, so please feel free to post details in the comments below). This allowed me to create a “Format CSS Single-line” command, complete with a keyboard shortcut, which enables an easy switch between multi- and single-line formatting.

Unfortunately, as of this writing Textmate macros cannot be exported and shared For those using Textmate, getting the macro is a simple matter of downloading, expanding and double-clicking this file:

While similar to “Format CSS Compressed”, this macro retains a single blank line where your original contained two or more blank lines (helpful if you group your rules), and adds whitespace that matches my standard formatting preferences (which I find makes it easier to scan quickly). To switch between each formatting style, just run each command in turn (via the Bundles menu or the keyboard shortcuts).

However, that wouldn’t be much use to everyone who doesn’t use Textmate, so here are the respective 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 missing

In Textmate and BBEdit I can return to multi-line formatting with a single command, but that might not be as simple in other editors. What I’d love to see is a pair of shell scripts that convert from multi- to single-line and back, and possibly a web-based processor that does the same (paste your style sheet into a textarea, select your formatting, hit “process” and the script produces the result). If anyone would like to take on those tasks, I’ll happily update this post to link to the products of your labor.

And in the end…

If you’ve never tried single-line formatting, this makes it easy to experiment without committing yourself (and I do recommend giving it a try—you may be surprised once you’ve worked with it a few times).

Ultimately, because I can return to multi-line with a single command my primary text editor should I ever feel like it, automating the switch from multi- to single-line is a convenient way to get the benefits of single-line formatting without backing myself or my clients into a formatting corner.

Categories:

67 Comments

Simple CSS Hover Tab Thingy

This item was posted by Dan Rubin on Tuesday, August 19th, 2008.

Update: The original 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 certain browsers :) See the comments for my quick explanation 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 honest: neither will this mini-tutorial, or the idea itself (nothing groundbreaking here, move along…). But after throwing together a quick little (you guessed it) hover/tab/thingy for my previous article, I thought I was fun enough to share, in case you find a need for it someday.

The usual suspects

The “thingy” in question is just a simple unordered list, with each list item containing an anchor and an image—we want the images in this case because I want them to display in my RSS feed and for anyone who can’t (or chooses not to) view the styled version of this site.

Note: Feel free to reference images in the stylesheet rather than inline if that suits your purposes. Because I know you need permission, don’t you…

If you were too lazy to click the link to my previous article above (and who could blame you, really), here’s a quick demo page.

Moving right along…

First, the markup (with URLs truncated to save trees):


Simple, uncluttered, uncomplicated. 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 {
  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 straightforward, so here are the highlights that may help when duplicating this on your own:

  1. The entire idea is that you have tabs that are each associated with content (images in this case) which are made visible when the user hovers over the tab. There are more things you could do with this, but that’s your job, grasshopper.
  2. The tabs are floated; the content elements (img in this case) clear the floats.
  3. The content elements are set to position:absolute, so they can appear in the same location for each tab. To accomplish this, the ul is set to position:relative (in short: an absolutely positioned element will be positioned relative to its nearest positioned ancestor—see Doug Bowman’s great write up for more), and it’s probably a good idea if the dimensions of your ul (the container for your content) have a lot in common with those of your content elements.
  4. IE6 has a problem reverting elements that set display:block on :hover to their original state (e.g. display:none). To counter this, use a negative left margin as the default positioning, and then set margin-left:0; on the hover state, which works in all modern browsers.
  5. The width and height is specific to my example (the dimensions of the images I used), ditto for the padding on the tabs and the top positioning on the img elements (to push them below the tabs). Bend them to your will.
  6. Everyone dies at the end of The Departed. Seriously, everyone. That should be the subtitle of the movie.

Obligatory wrap-up

This may be something that you’ll find use for on a regular basis—one of those tiny snippets 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 reason why you’d need to reveal some content whilst hovering over a tab (I’m pretty much just painting the sarcasm with a roller at this point…).

Whatever your future may hold, now you have something you might not have had before, and that’s never a bad thing—unless we’re talking about some sort of disease, in which case…

Categories:

15 Comments

I Need Some Spacing

This item was posted by Dan Rubin on Tuesday, August 19th, 2008.

Way back in June over on Subtraction, Khoi presented a tweaked version of the Gmail interface (and then a follow-up article regarding the feedback on the first), improving spacing and alignment by making a few small but significant changes overall:

“…by normalizing the space between like elements, aligning elements along similar spatial planes, moderately increasing the space between stacked items and paying attention to how elements are framed by negative space, we can get what is, in my opinion, a significantly more attractive Gmail interface.” Khoi Vinh

This is something I’ve wanted to see for a while in Gmail, and in fact had presented a few examples last year (July 2007) as part of my interview process at Google (I really must write about my series of amazing job interviews last summer, but I’ll leave that for another time). After reading—and commenting—on Khoi’s post, I had intended to publish my variation on Google’s mid-2007 interface, but as the dedication to blogging continues to elude me, this too fell a few pages back in the Moleskine to-do list—until now.

The Setup

I took a slightly different approach than Khoi, though my goals were similar:

That last goal was important and acted as a guide to the rest: I wanted to present improvements that could be made right away without causing a negative reaction among Gmail users.

Rather than adjust the line height of the main message area, I decided to bring as many of the other elements in line with that as I could. You’ll notice spacing improvements within each line however, reclaiming some poorly used horizontal space. Like Khoi, I felt the message lines were a bit crowded, so to give the impression of more room in those lines, I removed the grey horizontal lines between each item and allowed the background color to bleed through (all they need is some separation—further emphasis on those lines just adds weight). The result is that it feels like there’s a bit more space, without actually adding any.

The main navigation lost its underlines (again, removing unnecessary visual weight—the “this is a link” cue is superfluous here) and gained space (matching the baseline of the message list). The “Compose Mail” link got an extra highlight by way of a background; the extra padding makes it the only navigation item that doesn’t align with the baseline, but that also gives it a little more contrast vertically, thus it stands out more without having to scream for attention. Less important text links within the message area were made slightly smaller (but kept their underlines), and “Mark as read” was pulled out of the drop-down menu and given its own button: I had spent a week or so watching people use Gmail before doing this exercise, and that was the second most frequent action users needed (right behind “Delete”) but was hidden in the drop-down.

Finally, all rounded corners were cleaned up a bit, footer text was aligned to the baseline, and the message 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 interview crew. Compare the before and after images, and you’ll also notice that the improved spacing in this example actually reduces the overall height of the page, allowing two additional message lines to fit in the space of the original.

Both Khoi’s and my realign leave almost all the original elements of the interface intact—this is very important when making changes (even if only suggested ones) to such a popular application, and the same goes for any product, publication or web site that is part of a person’s daily routine.

Whether Gmail incorporates any of these suggestions 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 interface over the last year, and even in the last few months since Khoi posted his example. Not all are improvements, but at least someone’s making an attempt.

Categories:

13 Comments

Older