CSSquirrel A look at web development and web design by Kyle Weems

Over at the Mindfly Studio Blog I’ve added a small tutorial on how to vertically align your text with CSS. Yes, it annoys the hell out of me to use display: table-cell (which was the source of Monday’s comic on this very topic), but for now it’s the best thing we’ve got. If you’re wrestling with just this, pop on over for a simple explanation.

If you’ve got a better method, please tell me in the comments. I’m open to new and strange things, like Texan sushi.

Today’s comic, featuring Jeff Croft in a fictional scenario where he’s rebuilt into a duller, less spontaneous being by Jakob Nielsen after a tragic karaoke accident, is something of a lighthearted poke at the death of spontaneity in the name of… well, I’m not sure what, exactly. (It also guest stars Bruce Lawson as the HTML5 Doctor)

The sequence of events that inspired this micro-drama is as follows: Firstly, Jakob Nielsen decided to talk about iterative designs in tweets (or as he likes to dress them up: “stream-based postings”). He guides us through a process where in only five easy steps he has drained the blood from a sample tweet, leaving a dried husk that will rise in thirteen days to join the legions of humorless drones that find the useit.com design both fascinating and useful.

After this, Jeff Croft cuts through the meat of Jakob’s ‘findings’ with a tweet that probably did not require five iterations: “An article by Jacob Nielsen on how to take all the spontaneity and humaneness out of your tweets in five easy steps…”

Granted, at least one iteration more might have helped in his case to get Jakob spelled right.

The fact is, Jeff hit it on the head. If you’re writing down your tweets and re-writing them repeatedly to maximize some sort of marketing message, you’re not tweeting. I’m not sure what you’re doing, but I’ll bet that most people that see the message can see what it is, canned artificial crap. You don’t have a medium of micro-messages just to waste all the time and effort of a proper e-mail or blog post on a single sentence. Spending that effort on the message not only is contrary to the purpose of the medium, it’s counterproductive when the end result is what Nielsen presents, complete with shouting-style caps, months in parentheses, and different wording to make it “punchier.”

I’m going to say Jakob Nielsen does not know what “punchier” actually means. If he did, useit.com might not look like a canary got stuck in a mid-90’s school administration newsletter.

Tweet how you like, but if you spend a half-hour at a time maximizing your tweets in some sort of business formula, don’t be surprised when people stop paying attention to your massaged marketing attempts.

[Update: The CSS3 Attribute Selectors article in the Reference was updated just prior to this post going live. So my ranting about that section is largely out-of-date and can be summed up now as "Took much longer than I'd anticipated".]

When I was first hired by Mindfly in 2007 I was not what you’d call “web standards aware”. Upon seeing the table-based layouts, font tags, and massive collection of inline-styles that stampeded through my pages like wild buffalo, grown men would gnash their teeth and wail in torment and mothers would hide their children.

It only took a few crying infants for me to realize something needed to change if I wanted to keep this career. My infovore nature led me to consume as much information on the topic I could muster, starting with Andy Clarke’s Transcending CSS and continuing through dozens of online tutorials and references. Learning the errors of my past, I spent a bit of time quietly taking my old sites out to the woods, instructing them to dig their own graves, then whacking them with a shovel before burying them for all time.

After the evidence had been destroyed, I went about trying to make compliant, pretty sites using the best practices in HTML and CSS. By 2008, I had friends who thought making website was the bee’s knees, but they didn’t know where to look for learning CSS, etc. At that point my bookmarks of handy sites had grown enormously, so I heartily recommended several.

One that I mentioned time and again was the Sitepoint CSS Reference, which was (to my knowledge at the time) a very complete, useful reference to the wonderful world of CSS. It even included tasty tidbits about CSS3 support. The main reason I sent each person who asked to this reference was explained in Sitepoint’s announcement:  “…the reference contains a bunch of features that make it stand out from the pack — things like cross-browser compatibility charts and user feedback to ensure that it is accurate, up to date, and best-practice. If you’re building sites with CSS, this is a reference you’ll keep coming back to again and again.”

With the speed at which this industry changes, who wouldn’t want access to a constantly updated reference that even incorporated outside feedback?

There is a problem, unfortunately. As near as I can tell, the reference isn’t updating. Since its launch, it seems to be sitting still, failing to modernize its information as browsers march on. Every single browser on their compatibility list has had major updates since its launch, putting much of the CSS3 support information well out of date. Never mind that Google Chrome has been out for quite a bit of time now (as the Internet sees such things) and has no compatibility information present despite it’s higher browser share than Opera in most markets.

In a book, this situation is a necessary reality. Books, by their static nature, are out-of-date typically before they’ve even been published, requiring later editions, etc. But for a web-based reference, which claims specifically to have the benefit of staying up-to-date and incorporating user feedback, this isn’t terribly cool.

For me, the situation is exasperated by their promise to incorporate feedback (or even claiming to do so) when they (at least in situations I’ve experienced) clearly are not. To back my claim, I’d like like to direct you to my own experience I’ve had, which I’ll call Exhibit A. If you examine the page on CSS3 Attribute Selectors, you’ll find that it erroneously claims that Internet Explorer 7 completely fails to support these little gems.

I’m no IE fan, but I can tell you my friends, that this is a falsehood. And because I was foolish enough to take that advice at face value (who doesn’t trust Sitepoint?) I created IE-specific workarounds in a project where I first included these selectors, workarounds which ended up costing me a decent chunk of time. It was only later that I decided the best experience is personal experience and I actually tried the selectors in IE7, only to discover that they work perfectly fine. I’d wasted time (translate that: money) fixing a nonexistent problem they claimed existed.

Not being the type to hoard information, I shared the fact that they were mistaken in a comment on May 2, 2008, complete with a link to a test page to confirm that I wasn’t full of hot air. (The old test page has disappeared, so you can see what I’m talking about if you check this test page in IE7). Eventually they marked that they’d incorporated my comment into the article… only they hadn’t. It still incorrectly stated IE7 support didn’t exist. Sometime much later (aka, this year), I commented in annoyance at the mistake again on Twitter. They responded multiple times over Twitter to me, asking for clarification (which I gave) and then promised to update their Reference (which they didn’t).

That was a couple months ago.

Today’s comic shares my view on the so-called Reference, albeit in a somewhat abstract sense. So let me make it clear: I don’t think the Reference is what they claim: a reference. Rather, much like René Magritte’s unpipe it is not what it appears, merely the image of it. The unreference, if you will, is something that claims authority and completeness but increasingly lacks both as time moves forward.

One erroneous page isn’t worth tearing down their entire reference. However, with a complete lack of modern CSS support information on every major browser, Sitepoint’s “up-to-date” CSS Reference has become largely useless as a source for web designers living and working in 2009.  I’m upset at this, because I sent literally everyone I knew with an interest in learning CSS to their site, saying “Hey, these guys know their stuff.”

Now… well, now I tell people to avoid it. I’ll repeat that for anyone reading: Don’t bother. They mean well, but they’ve failed to live up to their mandate of keeping updated. In March, when I’d commented (again) on my disgruntlement with the lack of updates, I received the following pair of tweets from Kevin Yank (@sentience).

April 6, 2009 4:19pm: “What erroneous compatibility info did you find? We are planning to refresh the Reference for the latest crop of browsers in May.” (after which I gave a summary).

April 6, 2009 4:50pm: “Thanks! Will get that corrected ASAP.“

It’s July now. I think we may have different definitions for “corrected” or “ASAP”.

Nothing keeps you more humble in your industry than learning an important job-related detail, then discovering shortly thereafter that everyone else has known for years. For the past few months I’ve been experimenting with “OOP CSS”, taking advantage of mutliclassed elements to reduce stylesheet size and increase CSS reusability (after attending this presentation by Nicole Sullivan at Web Directions North.) Within the past couple weeks, I found some major roadblocks to using this technique with IE6 when being incautious about how the rule descriptors are ordered: IE6 majorly bungles multiple-class descriptor support.

To get a better view of what I’m speaking about (assuming you’re not already familiar with it), go check out the post I wrote at Mindfly about this very issue: Web Developer Weems and the Case of the Multiclass Bungler (AKA IE6).

This is a quick sanity check, if nothing else.

A while back, I found a way to make my inline-block spacing issues go away by getting tricky and using word-spacing to remove the gap, as discussed and tested here. I failed to check the results in a webkit browser, though, and recently discovered a slight problem.

Mainly, they don’t support that.

For whatever reason, IE, Firefox and Opera all apply word-spacing styling to inline-blocks, either adding to or removing the whitespace between the elements depending on your style. Safari and Chrome, however, do not. Mind you, they both have whitespace between the elements. They simply don’t allow the use of word-spacing to modify that space.

Here’s an example page showing the use of word-spacing with inline-blocks and normal sentances. Take a look in a webkit and non-webkit browser to notice the difference. (I didn’t bother to do IE 6&7 correction, so those browsers won’t show the lists side-by-side. Upgrade your browser already!)

As you’ll see, the webkit browser isn’t removing the whitespace.

So, the question is this: Does the w3c spec say what behavior is supposed to occur? Is the webkit result a bug/out-of-spec, or are the other browsers providing a result that isn’t required by the spec? It seems to me that the non-webkit result is the proper one. If you’re going to make blocks behave like words with spacing, you should be able to modify them in the same fashion. But then, there’s a lot about CSS that doesn’t always work like you think it should. (point in case: vertical-align. Probably the worst style ever.)