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

Although recently the trend seems to be more towards fixed widths or flexible percentage-based width layouts, from time to time I’m tasked with building a site with a liquid layout. Thanks to the demands of appropriately-ordered content and the challenges of having one column stay fixed in width while the other flexibly expands to fill the remaining space, these types of sites haven’t been the cleanest to make with CSS. One common technique that I’ve made a lot of use of was written in A List Apart called Creating Liquid Layouts with Negative Margins by Ryan Brill. It does the job, but it’s a semantic mess with a ton of divs.

I decided to try to find a method that pares down the div count, and makes the CSS a bit cleaner and more appropriate to the task. Lightning struck, and my mind put together a technique that feels like a decided improvement on accomplishing the desired task. I wrote about it over at Mindfly’s blog. Go check it out at Get Refreshed: Liquid Layouts with Simpler CSS and Without A Semantic Mess.

Over at the Mindfly blog I’ve posted The Curious Case of Inline Block, a mini-tutorial meant to help reacquaint people with display: inline-block, an incredibly useful CSS 2.1 display property value that wasn’t as convenient to make use of in the past due to faulty IE implementation and no Firefox 2 support.  But with Firefox 3 out and Internet Explorer 8 on the horizon, it’s going back into my toolkit of invaluable styles.

Go check out the post if you need a refresher course on how to make inline-block work out in all major browsers with little fuss.

Yesterday I wrote a post at Mindfly describing how to make use of the CSS @font-face rule for embedding fonts into web pages. I figured it was timely, as I’m getting tired of the number of times I have to use an image (or putz around with workarounds like sIFR) to substitute a special header all because of a non-web safe font, or a client with very specific typographic tastes and a very poor understanding of how the web and fonts work together (or more to the point, how they don’t). Furthermore, both Firefox and Opera have intentions to add support to the feature very soon, creating a world where all four major browsers will have the function (although with IE using EOT and not TTF it won’t be all peace and happiness quite yet).

The thing is, the more I look into the topic, the more it appears that @font-face won’t going to be ushering in a Utopian society of pretty fonts. The core issue seems to be how legal is font embedding going to be, and how will typographers feel about developers putting their font files on servers in a place where they could potentially be snatched?

So far the answers seem to be ‘not very’ and ‘not good’, respectively.

Which makes me wonder, what good, if any, will @font-face actually serve us. If, as a solution, it creates only another problem, a legal problem, that standards themselves can’t fix, is it worth the effort investing into this path to web fonts? Perhaps browser people should be looking into another technique that’ll prove to be more secure for the font files. Something that won’t look good on paper but results in a lot of angry mail from lawyers.

Although, it does make me wonder. Is there a technique that could be used with the current @font-face rule that would still protect the fonts?

@font-face. Good? Bad?

Am I the only person annoyed by how the CSS opacity property is automatically inherited by an element’s children, and it can’t be overridden in the child elements by any means? This is one of the most obnoxious limitations to a CSS property that I’ve ever encountered.

Seriously, why prevent that? I’d initially hazard a guess that it was due to technical limitations, but CSS3’s rgba colors don’t suffer from the same limitation. Too bad rgba colors aren’t universally supported yet.

Then again, neither is opacity.

-sigh-

I wonder if IE8 will support either, although frankly, if they’re going to step up to the big kid’s table, I’d rather see them implement rgba colors first.

I’m a few days too late for CSS Naked Day, so what’s going on?

The fact is, the existing “design” for the site was a quick, hacky skinning of Wordpress, done in about an hour of time with little regard to the end result. It was ugly. And I’m tired of it.

So I’ve stripped the site of it’s design for two reasons: 1. I hated what I had, and 2. Now every time that I look at the site I’ll see the bare bones staring back at me. It’s my hope that this will influence me to get off my lazy ass and actually put up the design I had in mind for the site all along.

I have a co-worker that made a comment about painters never having nice houses. I get the feeling that web developers often have unfinished websites. I’m hoping to break that pattern myself.

In other news, I’ve been checking out Twitter more. I know it’s yesterday’s news, but there’s a lot of neat things you can do with it that I’m thinking of trying to integrate into the site. We’ll see if that works out.

Ok, time for a dentist appointment. Yay.