Yeah I Use Tables For Layout, So Sue Me
Feb 02, 2009 22:25

"Hi, my name's Andrew Burke, and I, ... I use tables for layout."
"Hi Andrew. It's okay, we love you."
"I'm not alone? I though I was alone!"

                    (apologies to Bill Hicks)

                    This is a rant I've been wanting to make for a while - it has been in draft and private emails for a few months - but now <a href="" target="new">similar rants</a> are finally coming to light and getting attention - so I'm adding my voice to the slowly growing chorus.  

                                            I use tables for layout.  Not in a stupid way, but because CSS just doesn't do what I want to do. <a href="" target="new">And</a> <a href="" target="new">I'm</a> <a href="" target="new">in</a> <a href="" target="new">good</a> <a href="" target="new">company</a>

                                             I think it's interesting that these public confessions to using tables are coming out at the same time as details about the <a href="" target="new">next generation in CSS layout</a>, which looks like it will act a lot like regular HTML tables, but done 'properly' in CSS.

Anyhow, onto my own rant:

I use CSS for all sorts of things, including a lot of layout. It's great - and certainly a massive improvement over how styling and (most) layout was done before (I remember the FONT attribute). However, I think there's a conspiracy of silence about using tables for layout. I believe that a lot of people are unsatisfied with using CSS for layout, but figure that it's because they just don't know enough - so saying they have problems with it is like admitting they're not 1337. Well, I'm getting old enough to start being a cranky iconoclast, so I've decided to just get this off of my chest.

I started building websites back in 1994, in the early months of Netscape. I spent a lot of time back then arguing with people (especially people with traditional design or desktop publishing backgrounds) that these were web pages and not flat paper. You actually wanted to avoid absolute positioning, since screens and windows and devices can be any size and you want to support a wide range of readers. Embrace the flexibility and join the world of New Media!

But if you really wanted to do absolute positioning - and you shouldn't have wanted to, but clients can be demanding - there were ways to do it, but they were awkward messy hacks that involved invisible GIFs with arbitrary widths and heights, and meticulously arranged tables with clever fixed widths and colspans. IIt seems to me that the people who designed CSS spent too much time listening to the paper-based graphic designers, and they spent a lot of energy 'solving' the precise layout problem, with fixed widths and absolute positioning. I think that they missed the whole point of the web, which should be flexible and dynamic. Even worse, in designing CSS to support absolute positioning and fixed dimensions, they actually made it harder to do dynamic layouts.

I remember how disappointed I was the first time I checked the source for a mind-blowing CSS Zen Garden design and discovered that it was mostly just absolute-positioned elements over graphics - and worse, that if I grew or shrank the font in my browser it would either not resize the text, or the layout would completely fall apart. It wouldn't adjust to fit my browser window either.

A few years ago, I went 'back to school,' searched all the best websites, and read through the Head First XHTML and CSS book to see what the latest word was in HTML and layout. I felt like there must be some obvious layout technique that I was clearly missing, and once I found it I'd be able to leave this messy table crap behind and become 'pure'. The book indeed had several chapters explaining all of the different ways to get multicolumn layouts to work - but each one finished with "this is great until someone shrinks the window and then everything overlaps" or "this unfortunately doesn't work in IE". Many sites promised the secret to 'forms without tables', but just floated elements next to each other and assigned them fixed widths - fine for "Age: " and "City: " but not so good for "Validated Item Code: "

The main advantage of tables is that they enforce the relationships between elements rather than their size or position. When you don't know the size of a browser window, the amount of content within a layout element, or how a user might override things like font sizes, it's very important to be able to guarantee that certain things are always next to or above each other.

The other advantage with tables is that they stretch and shrink more intelligently than CSS does. You can set up fixed or percentage widths on individual elements, and the remaining elements with expand or shrink to fill the extra space.

If you want to position and size your elements absolutely, then go ahead and use CSS. If you're using tables for absolute positioning, then I agree that you're doing it wrong (1996 is calling and they want their "Trainspotting" soundtrack back). But if you're doing real work on the web, and not just pretty brochureware, I would argue that you don't want to use absolute positioning.

I build business applications, so my pages are more like templates for dynamic content than pristine fixed layouts. Sometimes an element will contain a small piece of text, and sometimes the same element will contain a massive 30-column spreadsheet-style report, possibly with graphics somewhere in it too. Fixed-width CSS layouts don't work in this context, and dynamic width CSS tends to fall apart badly. Elements overlap, or fall off the screen, or hop to the 'next line' and blow everything out of relation.

There was a time a few years ago when you could expect windows to be around 800 x 600, and most sites out there are set up with absolute layouts with fixed widths of 640, or 800, or 1024, or whatever - but those days have passed. My time is split between a 30" monitor at home, the 12" screen on my trusty old ThinkPad X30, the regular 15" screen on my MacBook Pro, and whatever-it-is on my iPhone - and things are going to get more varied, rather than less (consider the tiny screens on the popular new Netbooks). I can't tell you how many sites suddenly have no margins and require constant left-right scrolling to read on the ThinkPad's 12" screen, or have a thin strip of content in between oceans of margin on my 30" desk monitor.

The standard argument against tables is that "your HTML should focus on the content, leaving the CSS for style and positioning information. What about all those blind people?!" Well, your CSS site probably doesn't work very well for blind people either. Do you use AJAX? Do you manipulate the DOM at all? Do you use Flash?

In fact, having a layout that doesn't fall apart if the user grows the font size to maximum would probably do more for people with poor eyesight than 'proper' CSS would.

Also, CSS isn't as pure a separation of style and content as it pretends: the order of elements on a page still matters quite a bit, for example. Furthermore, if you've done any of the fancier DHTML effects with JavaScript, you'll notice that you still need to put the dimensions and positions directly into the element's STYLE attributes, thus breaking that separation of content and layout.

                                                        When the new CSS spec comes out and everyone is using a browser that supports it, I'll happily leave tables behind as a layout strategy forever.  However, I can't wait until 2015, so until then, I'm using tables to get things done. 

So, yeah, I use tables for layout. In fact, look at this page right here. Go ahead, change the size of your browser window, or change the font size. Notice how the logo is locked in place, while the rest of the header stretches and shrinks to fill your window, while keeping the gradient pattern always aligned to the left? Notice how this text also expands and shrinks so it always fills the available space, but still keeps proper margins and spacing? Notice how the footer also stretches and shrinks as well, so it always completely crosses the bottom? That's done with a relatively simple table for the major layout elements, and some clever CSS styles for repeating backgrounds.

By the way, if you shrink your browser window on this page to a very small size, you'll notice that the sidebar to the right ends up underneath the blog post text. That's because I decided to use 'float: right' for it. I guess nobody's perfect, eh?

The Different Kinds of Done
Jan 24, 2009 16:11
Careerious - Ruby and Rails vs. C#/.NET
Feb 09, 2009 15:46
Other Blog Posts
My Expanded Twitter Thread about BurgerWeek 2021 This Is Nowhere: The Server Side Building a React Native App Without Tears - Part 3 Building a React Native App Without Tears - Part 2 Building a React Native App Without Tears (Mostly) This Is Nowhere: The Memento Edition This Is Nowhere: Aspects of Accessibility Presentations About NowHere This Is Nowhere: Head-First Into React Native This Is Nowhere: Bloomsday Halifax This Is Nowhere: Why an HTML/JavaScript Single-Page App With GPS Is A Bad Idea This Is Nowhere: GPS and Wayfinding and More UX This Is Nowhere: The Single-Button UX This Is Nowhere: Don’t Just Stand There! This Is Nowhere: Finding My Duck Finding Burgers Fast: My DIY Halifax Burger Week Site "This is Nowhere" at PodCamp Halifax 2018 The Diary Diaries: Fixing Remembary's Facebook Connection Special Leap Day Edition of "Some Weird Things About Time" What's Up With Remembary Can't get pg_dump To Work Now That Heroku Has Upgraded Postgresql to 9.4? The Best Thing I Ever Did To Promote My App If You Build It, They WON'T Come #deployaday, My Big Hairy Plan for 2015 Extracting Plain Text from an NSAttributedString My Year of "Hits" Part 2: Remembary Rolling My Year of "Hits" Part 1: Remembary Rises (and Stumbles) Handy Little Test Method to Check for Translations in Rails Apps My Suddenly Slow-Waking MacBook Air Indie App PR: Keeping Control of Your Tone A Quick Note on 'clone' in Rails 3.2 My eBook Apps 2: iOS, JavaScript, and Ruby My eBook Apps 1: Introduction Quick Tip: No Sound on Mountain Lion My Upcoming Talk at PodcampHFX 2012: My Year of "Hits" Building at the Speed of Funny Screencast Tips Remembary's Cool New Picture Support Indie App PR 2: Keeping On Top Of User Feedback Indie App PR 1: How to Handle an App Disaster Giles Bowkett Diary Project 2 Remembary Video Congratulations! Welcome to Your Nightmare! How My iPad App Remembary Took Off Why You Should Have an App in the App Store (Even If You Probably Won't Make Any Money) PodCampHFX Remembary Presentation - Part 3 How I Used MailChimp Autoresponders to Promote Remembary PodCampHFX Remembary Presentation Part 2 PodCampHFX Remembary Presentation Part 1 Why AdWords Ads Don't Work for iPad Apps Remembary is Sponsoring PodcampHFX Why Can't I Resize my Views in Interface Builder? Momento and Remembary Concerning Remembary iPad-Friendly eBooks of Gracian's Art of Worldly Wisdom Project Report: PTOS2 A Quick Note on Encryption We're all LUsers Thoughts on HAML Friday Afternoon Hack - Getting Beyond the Basics Halifax Friday Hack and Back to Basics Quote from Wil Shipley FutureRuby Make Web Not War Busy Week I: Toronto Ruby Job Fair Employment.nil - the Toronto Ruby Job Fair Code Count: Ruby on Rails vs. C#/ASP.NET A Brief Note on Twitter The Hub Halifax and Mobile Tech for Social Change Deep Thoughts on Microsoft From The Accordion Guy The Two Kinds of Defensive Programming Presentation - Fixing Careerious: From C#/.NET to Ruby on Rails Enterprise! Presenting at Ruby on Rails Project Night - May 7th New Name and New Look for Careerious/Clearfit FutureRuby and More From Unspace Health Tips for Programmers This tables meme won't die Careerious - Ruby and Rails vs. C#/.NET Yeah I Use Tables For Layout, So Sue Me The Different Kinds of Done Giles Bowkett's RubyFringe presentation OfficeTime: Great Time-Tracking App for OS X Back With A New Look Non-DRY Feed torontorb Keeping Your Sanity With The Command Design Pattern shindigital Is All Grown Up! (according to the spambots) Startup Stars? I'm so bored! The Magic Words for RMagick Jennifer from Operations You see? Naming is HARD Business Software as Process Documentation Deployment note: 'execve failed' Steve Jobs on Market Research Why Canada Is Better for Entrepreneurs "Program first and blog second" Toronto Tech Collage The MacBook Air Is A Roadster RubyFringe! Quote of the Week: Steve Yegge Starting Up: Cards Great design tool: Starting Up: The Logo Quotes Of The Day: Hedge Fund Interview TSOT Ruby / Rails Presentation Night - Part 1 Moneyworks: Accounting Software for Canadians on OS X Starting Up: The Name Nice logo, but why is your site so bland? Welcome to