For me, as a designer, it’s not about accepting ‘blemishes’ or not accepting blemishes. It’s simply a matter of doing what I want to do. If what I want to do can’t be done it can’t be done, where it gets frustrating is when it can be done elegantly in any of our targeted browsers except IE6. At this point, simply constraining an entire project, and the majority of users out of a feature or experiential aspect of the site just because IE6 is a weak browser is in my mind more ‘just stupid’ then feeding IE6 a special little cookie so it will play nice and doing it the right way for everyone else.

Yes, an entire site littered with browser specific hacks would be an ugly unfortunate thing. But that’s an extreme. As developers as well as designers we need to be flexible. Swearing off hacks altogether is not being flexible. If an entire project can come together exactly as the designers want it to, all with one or two concessions for IE6 (the currently problem vestige of a previous age), then as an architect I say so be it.

The web and the world isn’t made up of polar extremes. It’s gray area. There are times where hacks for IE6 or Safari are the best compromises of implementation and intention.

Don’t hate the player dog. Hate the game.

Seth

@Chad: I’d rather use conditional CSS for the one browser that needs it (IE6) than switch to tables unnecessarily. Additionally, the above approach can work with limiting the size of things like embeds and other content without having to wrap each element in a table.

[table][tr][td style="width:40em;"][table][tr][td]

Your content goes here

[/td][/tr][/table][/td][/tr][/table]

Hope that works.

Your content goes here.

What I have found is that “width” on a TD element is interpreted to mean: grow up to this width unless I’m constrained by my parent.

The inner table is not really necessary unless your content might be smaller than the 40em and want a border or background color to shrink to the size of your content (in which case the style goes on the inner TD). It has no width assignment (width=auto), so it will grow to be just as big as is needed to hold the contents, but never bigger than the constraining parent.

FYI, I was using:

Granted, this is a lot of extra markup and hence, still sort of a hack. But it seems less hacky than using expression syntax to me.

Am I missing something?

Caveat – I have not read and understood the W3C table layout rules well enough to know if my solution is standards compliant. I only know that it works on the browsers I tested.

The “expression” syntax is still worth knowing.
Thanks,
Chad