Archive for ‘css’ category


I have yet to download and install an IE7 beta, but it sounds like it’s actually time to start paying attention to the latest release (Beta 2 Preview). We’re hearing reports from MIX 06 that the browser is essentially done in terms of CSS implementation:

Really interesting stuff from the above links. I’m impressed with what we’ve heard regarding the now-standards-aware IE team. On the flip-side, Roger Johansson brings up an excellent point: whether we’ll need a new way to self-clear floats in IE7.

Wow, this is a bit frightening, as I’ve been using the easy clearing method extensively, finding it to be pretty rock solid and predictable. It’s especially handy to use this to group components that use complicated floats and most importantly keeping them independent as self-contained, bulletproof “modules”. Being self-contained means they’re not dependent on subsequent elements in order to clear, and can then be moved around at will. Handy stuff.

So, it appears we’ll need a way to self-clear floats in IE7 that doesn’t use the still unsupported :after pseudo-element and the now fixed height: 1%; trick that previous versions of IE/Win so lovingly accepted. Here’s hoping there’s an alternative out there (aside from floating the container among others). I’m sure there will be, but even then this particular method would now feature 3 different declarations in order to work across browsers (actually add a few more in if you’d like IE5/Mac to work).

Update: Roger has posted an update, where a solution using display: inline-block; instead of display: inline-table; seems to do the trick for IE7. It’s a tad more complicated as to why this works, so be sure to read Claire Campbell’s informative write-up.

Arkanoid Edition

Another year, another realignment. What started out as a long-term desire to take better advantage of the footer (putting content chunks that were previously in the sidebar down near the bottom) quickly turned into more of a CSS refresh. This version is dubbed “Arkanoid Edition” (coined by Ethan and will make sense to anyone that spent their afternoons at the arcade in the 80s).

There are too many dusty corners to clean up, and so there very well might be some areas that still need attention. But somehow this feels more comfortable right now. The colors are toned down a bit, columns feel a bit more readable, etc. Surely not everyone will be a fan, but such is the life of a web site. Change is good. But it can also be disorienting.

Boxy, but Nice

One of the struggles with the SimpleBits logo is that it’s not a logo at all. It’s an icon. And works terribly in print unless it’s enlarged properly. I’ve debated changing the logo, always settling on maintaining the brand, and instead embracing its pixellated charm. Hence the square, blocky treatments that will likely warm the hearts of 8-bit fans and yet turn away the warm-and-fuzzy brigade.


I’m no longer straddling the fixed/fluid fence! Previous versions of this site featured a little toggle up in the top right corner enabling you to switch between a fixed or fluid width by means of a little Javasript and an alternate stylesheet. How diplomatic. With this new design, I thought I’d try a centered, fluid layout, using left and right padding on the body using a percentage value. That coupled with a conservative max-width set at 900px makes for a wider-but-not-too-wide solution. If only max-width (and min-width) worked in IE (aside from the Javascript fixes that exist).

Hiding from IE/Mac

I’ve also decided to intentionally hide all CSS from IE/Mac this time around. It’s not that it would be impossible (or even that difficult) to get this particular design working. It’s just that, for this site, it’s time to move on and have one less set of hacks to worry about.

What’s great, is that it’s dead simple to hide CSS from IE/Mac using the commented backslash hack just before importing your styles. Here’s my main stylesheet, screen.css, which imports the master styles as well patches for IE/Win.

/* import stylesheets and hide from ie/mac \*/
@import url("master.css");
@import url("ie.css");
/* end import/hide */

IE/Mac won’t get any of it because of that backslash at the end of the opening comment. And this is certainly OK for SimpleBits. Your site’s statistics may vary.


Archived for posterity, and a comparison for those arriving here today for the first time, is a screenshot of the previous design.

A Tiny, Subtle Shift

As with anything that you do frequently, patterns emerge. Certain choices become comfortable, unrequired of a second thought. Such is the case for me when choosing colors for the web. There have been certain hex values that I’ll gravitate toward: #eee, #ddd, #ccc, #999, in the grey family, for example. I know what each of these will accomplish for me and how they play with each other before a stylesheet is created. I’m sure you have your favorites and old standbys as well. I fall into using and reusing these values because they work like a trusty wrench.

But it’s fun to cast those aside (at least temporarily), changing things by an extremely small measure. At times, it can mean all the difference in devising something fresh, new and different.

This happened while working on a recent project. Instead of combining my usual #eee, #ddd, and #ccc, I instead settled on combining #f5f5f5, #e5e5e5, and #d5d5d5. I know, this sounds completely trivial, doesn’t it? I mean, the difference is so damn subtle, it’s liable to go unnoticed by the average user, not to mention indistinguishable on varying screen types. And on top of that, they’re all far from being web-safe hues. But all that aside, for me at that moment, the slightest change made all the difference in making this particular project stand on its own. A temporary step outside the familiar — even if that step is purely the benefit of me, as the designer.

The main point here being: sometimes a tiny, subtle shift in the way you do things can be all it takes for things to seem new, exciting and right again (perhaps a micro-realignment?). This same philosophy can of course be applied to the non-web world. Just a few hours ago, Kerry and I were tossing around statements like, “we need a new house” or “we need to put on an addition”. Later, we started hypothetically shifting furniture around in our minds, and suddenly there was this renewed excitement in making something old, new again. A tiny adjustment that (for the time being anyway) quenches an urge for broad, sweeping changes.
Next week? I’ll be back to #eee.


CSS Patches

The term “hack” implies that a legitimate solution to the problem exists. Yet, in order to save time, or perhaps due to lack of knowledge, a sloppy fix is applied to just get the job done. “Let’s hack at it, ’till it works”. But is this the case in terms of CSS hacks? Sure, we call them “hacks”, when in reality they’re really patches. Patches that fix known, documented problems in certain browsers.

I know it’s really just a term, but the problem is this: by using “hack” to describe often necessary code, a negative connotation can be attached, even if what we’re really doing is compensating for a browser’s shortcomings. When you hear someone say: “I avoid all hacks”, you’ve witnessed this negative connotation. Heck, we’d all love to avoid hacks — but we’re also realistic, living in the real world, and designing in 2005.

Now think about the term “patch”. It brings to mind, mending something that’s broken. It’s rip or tear is clearly visible — we know it’s broken, and we know what we need to do to make it look better. We’re not cutting corners, we’re applying a fix.

Perhaps from now on, I’ll refer to fixes for gems like the double float margin bug, or the three-pixel text jog as, well… patches.

Bulletproof Logos

There are a few browsers (Firefox, Opera) that treat image alt text as if it were normal text on the page, when the image isn’t present. If the reader turns images off to save bandwidth, we can still visually treat the images by styling the alt text, and this could be especially handy in regards to site logos.


Been There, Done That

For whatever reason, I often struggle with visited link treatments, perhaps because (for me) it’s often an afterthought. A color palette is selected, the page is designed — now it’s time to figure out how best to show that a link has been visited. For most sites, it’s important to visually signify where the reader has been, and not everyone handles it in the same manner.


When Floated Figures Attack!

I recently began publishing full entries in the RSS feed for SimpleBits, figuring that if people would rather read the entire Notebook post in the comfort of their aggregator, they could go ahead and do so. Personally, I enjoy reading content in its intended environment, with all the site design around it, and find myself skimming NetNewsWire for interesting articles to pull up in a browser later on.