So having said all that, the way we’re handling CSS columns these days is actually pretty cool. Here’s some sample CSS, from a site in development with a 720px wide content area:
/* Column layouts */
.column { float:left; overflow:hidden;}
.columns { margin-bottom:20px; padding-top:10px; }
.three.columns .first { width:200px; padding-right:20px; }
.three.columns .second { width:200px; padding:0 20px; }
.three.columns .third { width:200px; padding-left:20px; }
.two.columns .first { width:300px; padding-right:20px; }
.two.columns .second { width:300px; padding-left:20px; }
This lets us code the XHTML like this:
<div class="three columns">
<div class="first column">
Column 1
</div>
<div class="second column">
Column 2
</div>
<div class="third column">
Column 3
</div>
<div style="clear:both;"></div>
</div>
… which is pretty nice semantically.
Tags: CSS, free stuff, tables, whitewhale
Comments: None »
You don’t use HTML tables for layout. Every standards-based Web designer knows this.
As of June 2008, this notion is so deeply buried in the conventional wisdom about Web page design that just about nobody ever thinks about it anymore; the idea of using a table for anything other than Tabular Data is met with scorn and derision from developers. And so the lowly <table> tag sits alone in the lunchroom, friendless, with nobody to talk to except its perpetual hangers-on <td> and <tr>.
Now of course, we don’t use tables for layout at White Whale. Ever. How could we? It’d be like driving an SUV, listening to a Zune, or voting Republican— it’s something cool people just don’t do. We (as a company) couldn’t design a site with layout tables and look at ourselves in the morning.
But I don’t like conventional wisdom, and as a result I often find myself thinking about tables— in particular, how there are some things you can do with <table> that you can’t do with <div>, no matter how hard you try. (At least across all browsers, and without using Javascript.) Read more »
Tags: bad habits, CSS, design, guilty pleasures, tables, whitewhale
Comments: 3 comments »
Internet Explorer 6 is a web development headache for many reasons, but its lack of support for PNG alpha transparency is one of the most grating. It’s more-or-less a given that any cutting-edge design (even a relatively minimalist one) is going to have a place where one layer shines through another, or a single transparent image should be matched to multiple background colors, or—most commonly—anti-aliased text is placed over a photo or texture.
Getting these PNGs to actually be transparent is no longer a major issue—we’ve used a few different approaches over the years, but settled on Angus Turnbull’s iepngfix.htc as the most straightforward drop-in solution out there. The way it works is just really smart.
But while building out some recent client projects, we just couldn’t get it to catch. We checked and double-checked the file paths, and re-exported the PNG images, and finally copied a working example from a live client site, but nothing seemed to do it. Because IE has no decent debugger, I removed the conditional comment to see what I could learn in Firebug.
It turns out that our staging server sends the .htc file as text/plain, while the working client version was serving text/x-component. Changing out server config to mimic this fixed the problem. Later, some Googling revealed that the release notes for the newest beta version address this (and even include a PHP solution that serves the file while sending the correct headers).
There are still a whole host of limitations: no repeating images, weird layering glitches that happen even in IE7, and really bizarre link clickability issues. But iepngfix gets far enough to solve 90% of the problem.
Tags: code, CSS, development, ie6, internet explorer, png
Comments: 5 comments »
I spoke briefly about our particular CSS formatting structure in my last post. But here’s something else that’s been on my mind a lot.
At White Whale, we’re of course always thinking about code efficiency: less queries, less code, fewer requests, et cetera. And much of this on the design side is rote best practices (semantics, accessibility, compatibility). But I still find myself sweating more nitty-gritty details, so I was fascinated to see jpsykes’ analysis of this one. The question boils down to, “How specific should I get with CSS selectors?” Read more »
Tags: bestpractices, CSS, efficiency, optimization
Comments: None »
We’ve been talking for a long time about (and more recently getting to work on) documenting some of White Whale’s best practices. It just seems like good stuff to have written down—and one day maybe share—but more importantly, as we slowly grow we’ll have a reference guide for anything from variable naming conventions to our preferred image replacement technique.
One of the things that’s been part of White Whale canon for some time is writing CSS declarations in a single-line format, with indents for parent-child relationships. Read more »
Tags: Best Practices, coding, CSS
Comments: None »