Touche Tom, I will play ball...
Originally Posted by
tomchadwin
I don't think the key argument is the semantic meaning of table, as opposed to the neutral div. I think it is the markup bloat associated with tables. Having all these extra table and tr tags, not to mention thead and tbody (which, even if you don't use them explicitly, the rendering engine of browsers inserts) makes code extremely difficult to read, and inefficiently bloated.
The difference between this:
Code:
<table class="someWrapper">
<tr>
<td class="someColumn"></td>
<td class="someOtherColumn"></td>
</tr>
</table>
...And this:
Code:
<div class="someWrapper">
<div class="someColumn"></div>
<div class="someOtherColumn"></div>
</div>
Is minimal. And I've heard the "yeah but multiply that by 1000 pages" argument many times, but in a real-world setting I'm not really convinced about those 6 extra characters. (HTML files are compressed anyway, so the bandwidth savings are not 1-1). And in return for those two extra tiny <tr> tags, in many instances you would buy yourself at least a little bit of convenience and simplicity when you develop.
Originally Posted by
tomchadwin
The other key argument is multiple stylesheets. If you use tables, especially with cell spans, you will find it very difficult to hide navigation in print versions. The best way to allow alternative browsing technology to get at your site's content is to use CSS. End users with vision problems can then specify their own CSS (high-contrast, large type, etc).
I think you are assuming we are talking about the "one-hulking-table-shell-that-surrounds-everything" approach. When I coded with tables, I didn't really do that. I stacked simpler, individual tables, one after the other when I needed columns, and still used div's when I did not. So something like a horizontal navigation menu would have had its own table, and that table could easily be hidden with a print stylesheet like any other element.
I'm glad you brought up menus -- the great thing about a table for a horizontal menu was you could automatically space out the items equally without extra CSS declarations (like hard coding padding in pixels, or specifying widths as percentages -- both of which require CSS changes when new items are added).
Originally Posted by
tomchadwin
There is also the search engine issue. One criterion used by search engines which determines how a page is ranked against a search phrase is the ratio of the phrase to the page content. The less markup you have, the greater this percentage.
I will defer to argument #1 on this (the amount of code weight that is actually added).
Originally Posted by
tomchadwin
As for fixed versus fluid layouts, I've always been a fan of elastic layouts, where the em is the prevailing unit. This allows you to fix the width, but text line length remains constant as text is resized by browser controls, and the layout doesn't break. This is less of an issue these days, though, since IE (v7, I think) made its default zoom behaviour a full zoom, not a text size shift.
I quoted this not to comment on the fixed/fluid issue (which I think is a largely personal preference -- with some specific exceptions). But you have to admit -- how much easier is it to make a layout with a mix of fixed and fluid columns if you still used tables? You don't want to admit, but deep down you know it's true.
Yeah, so suck on that, Tom!!!
Bookmarks