Principle vs. Practical in the World of Web Design

By Deane Barker

Web design and development isn’t a perfect science – there are no absolutes. You can take a stand on how something should be done, but that doesn’t mean it’s necessarily going to work that way. I wrote this article about a year ago, and in it, I drew several lines in the sand about the way things…

The author discusses the balance between principle and practicality in web design, particularly in the areas of font sizes and table widths. They express concern over browser differences and the challenges of applying font-size percentages, and the difficulty of maintaining usability in the face of multiple browser sizes. The author also acknowledges past disagreements with Rob and Kara over the concept of liquid design.

Generated by Azure AI on June 24, 2024

Web design and development isn’t a perfect science – there are no absolutes. You can take a stand on how something should be done, but that doesn’t mean it’s necessarily going to work that way.

I wrote this article about a year ago, and in it, I drew several lines in the sand about the way things should be done. Well, I’ve since crossed one of those lines more or less completely, and I’m seriously re-thinking another. Both are implied in this sentence: “Use Percentages for Font Sizes and Table Widths.”

Font Sizes

The font-size one is obvious, but it’s hard to do in a lot of cases because of browser differences and how they handle cascades.

With Internet Explorer, for instance, the font-size CCS attribute applied to the BODY element isn’t carried over to a TD element. But if you apply it to a TD, then it will re-apply for successive TDs – if you set it to 90%, then a TD inside a TD will have a font-size of 81% (90% of 90%). Drives me nuts. The solution, of course, is to not use tables for site layout and just use absolutely positioned DIVs, but that opens a whole different can of worms.

So what do you do? Abandon standards and hack everything up? Abandon layout tables (and older browsers) and use absolutely positioned DIVs? Or abandon usability and code font-sizes in pixels?

Table Widths

The bit about table sizes was designed to make Web pages flow (liquid design, they call it) within multiple sizes of browser windows. However, if someone has their screen resolution set to 1280 x 960, and has their browser maximized, it makes blocks of text hard to read – they go wall-to-wall. I get eye fatigue trying to read them.

Given this, I’m starting to do more and more sites as fixed width…like this one, for instance. (However, I am tempted to try something different: detect the screen resolution and then show or hide a third column based on how wide the user’s screen is. All sorts of warning bells go off in my head when I contemplate this, but I still may try just for fun…)

So, here we have a battle of principle vs. practical. I was playing with AmphetaDesk the other day, and in the HTML source of the main template file, the author has written this in an HTML comment:

I’m a fan of stylesheets and standards. However, I’m a bigger fan of catering to browsers from yesteryear. So you’ll find a lot of tables and hackish HTML in this ‘default’ template. You’re gonna have to deal.

Rob and Kara, if you’re reading this, my apologies for all the grief I gave you two over the liquid design thing. I remember a tense conversation we had about it in the first-floor conference room in Building 3 about a year ago. In retrospect, I can see where you were coming from.

This is item #348 in a sequence of 357 items.

You can use your left/right arrow keys to navigate