inditetheweb.com» CSS Articles | Indite the Web | Web Development Tips, Tricks, and Tutorials

Designing Without Tables

Kate — Thu, 23 Oct 2008 18:58:51 +0000

Fortunately for me, I started doing Web development at a time when Web standards were moving forward with a vengeance. XHTML, CSS, and table-less designs are accepted techniques. However, I’ve still had to deal with my fair share of tables. My first job out of college, for instance, was with a company that, up until that point, had strictly used tables (and nested tables) for site layout and design. It took a bit of convincing, but they eventually saw the benefits of tableless/CSS design. (Fortunately for me, they were already trying to make the transition when I came on board.)

But, I’m still amazed at the number of well-known sites that rely heavily on tables. Instead of being surprised when a site is using a table, I’m pleasently surprised when they’re not. Isn’t there something wrong with that picture? I understand that browser support can be a bit sketchy for CSS at times, but the trade-offs, to me, far outweigh any extra work you may need to do to make a site cross-browser compatible. Not to mention, tables were never intended to be used for design/layout.

It’s truly a case of using the right tool for the right job. Think of it this way. If you’re sitting down to create, for instance, some sort of digital art, what’s the first tool you open. Microsoft Excel? Probably not. More than likely, you’ll choose a tool that’s suited for design, perhaps Photoshop, the GIMP,… even Paint would be a choice! Now, if you were going to record this week’s payroll information into a table, Excel would be a good choice. See the difference? It’s not that the tool in itself is wrong… it’s the misuse of it. Tables are great… for tabular data. Not for design and structure. That’s what CSS is for. Even tables can be used effectively with CSS. The benefits will soon become apparent. From faster page load times to less time spent updating and maintaining pages, you’ll be thankful.

Fixed Width and Screen Resolutions

Kate — Thu, 23 Oct 2008 17:28:41 +0000

While creating this blog I was faced with a dilemna: what width do I make the layout? I knew I wanted it to be a fixed width, but what width? I’ve developed sites for a long time for 800X600 resolution. My thought is that it still looks good for those with a higher resolution, but works for those with a lower one. I still hold to this. There are many things you can do to enhance browsing for users with higher resolutions. (For instance, say you have a wrapper container set at 760px. You could add a background image to the body that would be visible to users with higher resolutions, while not hindering those with a lower one. Anyway, back on topic:) There were two big considerations to making this site optimal for users with a 1024×768 resolution or higher. 1) This is a blog. Due to content needs and ads, a large percentage of blogs seem to forsake the 800×600 users, more out of necessity than spite. That’s the road I opted for. 2) I assume my readers have some level of tech interest, and as such, there is a very good chance they have a resolution higher than 800×600.

Again, I can’t stress enough: consider your target audience. I did a project with a company who’s client was a group comprised of mostly elderly people. As such, their screen resolutions were likely to fall into the 800×600 category. I worked with that company for almost a year and a half on various other projects, and I got into the habit/mindset of designing for 800×600. We both thought that with the statistics available at the time, and with the clients they have, this would be the best choice. But, things are changing, and likely will continue to change into the future. The beauty of Web development is that it’s constantly changing, constantly evolving. So are our users. We need to keep our thumb on the pulse of the times and make sure that, regardless of what resolution we design for, we’re keeping our users first in our mind.