Here's another nugget of truth: Denture-wearing browsers prefer easy-chew tables. For that quarter of your audience not using a fifth-generation (or better) browser, fixed-width workarounds and progressive rendering don't help.
One old-school trick works, though — remembering that lots of little tables appear to render faster than one big, many-rowed table.
If you've got a nine-row table that fills a few screens full of information, go ahead and break it into three smaller tables of three rows each. This strategy is particularly beneficial if your Web pages require a lot of vertical scrolling. Your audience can read the contents of your first table as other tables continue to load down in the nether regions of your page.
Don't Trust WYSIWYG Editors
Tables can be a pain, which is one big reason WYSIWYG HTML editors became popular in the first place. However, while HTML editors make it easier to create tables, they can produce amazingly inefficient code.
The layout windows of WYSIWYG editors often make it tough to spot unnecessarily nested tables, improperly sized table elements, or strange, roundabout HTML code. So if you want your tables to be as slim and efficient as possible, but you still want to use your WYSIWYG editor, then budget some time at the end to validate and clean up your code. Once everything looks the way you want it, jump to "Code View" in the WYSIWYG editor, or drop the dirty HTML into a text-editing app and pick over your code until it is nice and clean.
Nested Tables — the old taboo!
One notorious culprit associated with slow-to-the-screen Web pages has always been the nested table. A nested table is created when one table is put inside the cell of another table. Of course, with ever-faster computer hardware, nested tables may not get such a bad rap these days. Well, go ahead and call us old-timers, but nested tables are still sucky in our book.
Why the legendary performance hit with nested tables? For starters, browsers have to work doubletime on tables. Unlike most page elements, tables absolutely require two passes of browser "reflow" (layout code-crunching), due to their auto-sizing shrink-wrap behavior. Pass #1 assesses what size each table cell would like to be, and Pass #2 determines how big they actually can be, once other elements on the page have been accounted for.
And there's the rub. A single-nested table requires two passes, plus one more, because the inner table must be partially re-rendered during outer table's rendering process. Nest three tables inside one another, and that makes for five passes of reflow. Nest five levels deep, and the browser loops through reflow routines nine times.
Fun Fact: Some tables may even require a third reflow pass when put in tricky situations like specified-percentage-height table cells squatting in an un-sized parent table. Woah! Wait — did we just say "Fact" or "Fun Fact"? Oh. Umm, we meant to say "Fact".
So avoid using nested tables whenever possible, even if it means making minor alterations or simplifications to page layout. (Remind your design team that Photoshop is an image editor, not a HTML-prototyping application) If you must use nested tables, at least keep them simple — try not to nest more than a few levels deep. Even though table rendering speed issues are less problematic on modern PC hardware, table layouts still hamper screen readers and other accessibility-enhanced browsers. Nested tables doubly so. We're building Web pages here, not those little Russian dolls.
next page»
Home
