I agree - but I’d rather not see lies used to propagate the change. There are enough legitimate reasons to not use tables for layout - we don’t have to lie about it.
There are merits and flaws to every approach, the best thing we can do for nubes is teach them those merits and flaws, and make sure they have as much information as possible to make rational informed choices for themselves.
As I have demonstrated you can save many kb across your site by defining your layout tables in the CSS rather than in the HTML so the statement about saving bandwidth wasn’t a lie. As Alex mentioned that caching the CSS also saves bandwidth so there are two examples of that not being a lie.
There is also the fact that some web browsers do not render any of the content of a table until the entire table has loaded - that will make the page appear to load slower in those browsers than a semantically correct page will even if the total page size were the same and so for those browsers the load time difference is even greater than a bandwidth comparison would suggest.
There are lots of reasons for not using HTML tables for layout. That you can redo an entire site’s appearance in minutes if it uses CSS compared to months or years using HTML tables is probably the biggest advantage that CSS has. I know that from personal experience as when my site was half the size it is now I converted the pages from using HTML tables to using CSS and it took me all my spare time for about three months to make that change. Similar site wide changes now with twice as many pages on the site rarely take more than five or ten minutes. Had I not made the change to get rid of the HTML tables each change would now be taking all my spare time for around four or five months and I’d be unable to keep adding new pages to the site.
“Layout tables?” - do you mean a layout, or using tables?
Using a table with CSS vs. using a bunch of div with CSS, done properly, should have little if any difference in bandwidth use. AT MOST we’re talking 10-20 bytes each… and it can go either way depending on the layout effect. The ONLY real reason for more than 2-3% variance in either favor usually falls in the lap of the developer not using one or the other properly and using outdated/outmoded coding techniques…
Well that or browser developers not fixing decade old bugs in their implementations of HTML4/CSS2 while pissing away time on half-assed specifications not even out of draft yet.
He meant using the CSS table display properties:
div {display:table-cell}
^which is entirely pointless to use unless
a) you’re able to ignore IE6 and 7 (some people do have that luxery)
b) it’s ok that your “row” won’t wrap… if you need wrapping at smaller widths, you can’t do this… gotta float or inline-block or something…
c) you don’t run into a browser who needs specifically a layer for “table”, a layer for “row” and a layer for “cell”. I’ve been able to get away with just a table and a cell but it was some version of Safari that needed a “table-row” element and some version of Mozilla had a similar issue. That means three elements when you only want a row of boxes in a container.
I’ve used it a few times, and when it does what I want I like it, but I’m limiting myself mostly because of IE and because I dislike the very idea of giving a whole separate stylesheet for IE. Meaning the hacks are sitting in my sheet. I don’t mind the occasional line here or there, but if I use display: table, I either need ugly CC’s or I need two lines (one for 6, one for 7) for each replacement property.
The idea of styling a whole page like that seems as weird to me as doing everything with position: absolute or doing everything as floats. Yeah yeah I know Andy Clarke can do it all with abso-po’d boxes, but c’mon, I’m talking about real people here, peons like us. : )
Ugly either way.
One place you can lay the blame for this is Eric Meyer’s reset, or if he’s fixed it, his older but popular stylesheet.
Somewhere in that mess of unnecessary reset styles, there’s this statement about /tables still need cellpadding and borders/ or some weird shitake. And I’ve seen people using that and I’ve said hey, you don’t need that, CSS has border-collapse and border-spacing, and people still insist it’s necessary in the markup and that CSS can’t do that.
Frustration!
My reference was to layout tables as opposed to data tables which are tables that are what the HTML table tags were actually intended to be used for in the first place. There are data tables where the content of the table is tabular data and there are layout tables where the purpose of the table is to define the presentation of the content which is not tabular data.
I was giving you a comparison between the amount of code needed to do a page layout using a layout table in the HTML as compared to doing a layout using CSS (it doesn’t matter what CSS you use, I just used CSS tables in order to simplify the example since then it too is a layout table but using floats or positioning commands in the CSS doesn’t affect what I was saying).
As I showed, the biggest benefit comes if you need to change the way the page is set out but there are still some benefits that can be achieved through semantic markup in your HTML.
Without tables:
<style type="text/css">
ul#list li {display: inline; float: left;}
</style>
<ul id=list>
<li><img src="image1.jpg" width="171" height="300" alt="image desc" /></li>
<li><img src="image2.jpg" width="171" height="300" alt="image desc" /></li>
<li><img src="image3.jpg" width="171" height="300" alt="image desc" /></li>
<li><img src="image4.jpg" width="171" height="300" alt="image desc" /></li>
<li><img src="image5.jpg" width="171" height="300" alt="image desc" /></li>
</ul>
With Tables:
<table width="898" cellspacing="5" bordercolor="#1C5487" background="image.jpg">
<tr>
<td width="213" height="300" align="center" valign="top"><p><img src="image.jpg" width="171" height="250" /><br />
<br />
</p></td>
<td width="15" align="center" valign="top"><p><img src="image.jpg" width="171" height="250" /><br />
<br />
</p></td>
<td width="199" align="center" valign="top"><p><img src="images/blank.jpg" width="171" height="250" /><br />
<br />
</p></td>
<td width="213" align="center" valign="top"><p><img src="image/blank.jpg" width="171" height="250" /><br />
<br />
</p></td>
<td width="216" align="center" valign="top"><p><img src="image.jpg" width="171" height="250" /><br />
</p></td>
</tr>
</table>
Which one makes more sense to you?
Well one of them will dynamically change the number of images displayed across the screen depending on how many will fit while the other will either be too wide and have a horizontal scrollbar or will leave big gaps between the images.
My experience is:
It’s a happy synergy where the most semantically correct approach is also the most efficient, and it works because in either case, if you use the wrong approach then you’re abusing the markup, which leads to having to include lots of extra definitions, declarations, hacks and kludges to achieve the effect you want.
Uhm, neither since they aren’t even the same thing? The table one
A> declaring all the TD as different widths so it’s not going to render the same… that extra 43px having to go SOMEWHERE.
B> not even pointing at the same images.
C> Declaring *** like width, align, valign, bordercolor, and background in the markup - none of which even BELONG in the markup… (some of which aren’t even valid in STRICT)
D> … and that’s before we talk about paragraphs for no good reason, double line breaks doing padding’s job…
E> without the extra padding on your LI or IMG declarations in the ‘non-table’ version you are nowhere near the same rendering. Great job of card stacking - supporting your viewpoint by omitting some details.
GREAT example of writing a table as if it was 1997. Too bad this isn’t 1997.
First, let’s get the CSS for your second one to at least TRY and match the table version - that way you don’t have your lie by omission. It’s called card stacking for a reason.
#list {
overflow:hidden; /* wrap floats */
width:890x; /* also trips haslayout, wraps floats IE */
padding-right:5px;
background:url(images/image.jpg);
border:1px solid #1C5487;
}
#list li {
float:left;
display:inline; /* prevent IE margin doubling */
padding:1.2em 0 3.6em; /* assumes 1.2em line-height */
margin-left:5px;
border:1px solid #1C5487;
}
This of course will have 1 extra PX of padding on the left side, and encounter the broken box model bug in 5.x (if you give a flying *** about 5.x being off one pixel)
Then of course, let’s make a table version written PROPERLY.
<table class="list" cellspacing="5">
<tr>
<td><img src="image1.jpg" width="171" height="300" alt="image desc" /></td>
<td><img src="image2.jpg" width="171" height="300" alt="image desc" /></td>
<td><img src="image2.jpg" width="171" height="300" alt="image desc" /></td>
<td><img src="image2.jpg" width="171" height="300" alt="image desc" /></td>
<td><img src="image2.jpg" width="171" height="300" alt="image desc" /></td>
</tr>
</table>
Oh noes, 31 extra characters of markup!?! MOST of which being whitespace… (though we could lose 16 of those if IE and FF weren’t retards about the border-spacing property)
#table {
width:898px;
background:url(images/image.jpg);
border:1px solid #1C5487;
}
#table td {
padding:1.2em 0 3.6em; /* assumes 1.2em line-height */
border:1px solid #1C5487;
}
183 bytes less CSS since our table already has our desired behavior, so that means we’d need to serve 6 pages to one user before we started saving bandwidth.
Though SEMANTICALLY the list makes more sense. Well, actually that might not be true since it’s just a bunch of images it might be most semantically correct to just have them in a div - but that hinges on what they are images OF.
Still, if your going to compare, do so apples to apples, not apples to seedling.
There’s a reason I keep this old demo of mine around:
http://battletech.hopto.org/html_tutorials/3coltable.html
… and even update it from time to time. 3 column content first 100% min-height using a table. No fatter on bandwidth than it’s DIV/CSS counterpart would be…
http://battletech.hopto.org/html_tutorials/3coldiv/fixed.html
In fact… look at the contents of the two body areas. Stripped of content the table one is 254 bytes of tags and attributes - the div based one is 231 bytes… though once you add the second wrapper our sandbag background div’s for the faux column effects you’d be right back up at the same size. (assuming you couldn’t dual-purpose body and #container)
Compare the CSS, and it’s 800 bytes for the table and 1100 bytes for the div/css one (stripping comments, but before we even think faux-columns). To make up that 300 bytes we’d have to average 13 pages served per user.
Oh, and which one needs actual browser specific hacks to even work?
There are plenty of legitimate reasons for not using tables to layout elements - we do NOT need to make up ones by propagating lies.
The few times I’ve used border-spacing, it’s done what I expected (well, didn’t use it for IE6)… what does the “open sores fox” do wrong with it? Either it’s in a situation I’ve not coded for, or it was small enough that I either missed it or didn’t care. But I’d like to know.
2.x ignores it outright, in 3.x last time I checked it made border on TABLE be counted OUTSIDE the table width… which if you’ll remember tables are ALWAYS supposed to behave like the “broken box model” IE Quirks – width being total width.
Oh, I’ve only used border-spacing for cells, not table-itself borders.
I was just trying to make a point. I copied the table code from a website that had 2 rows of pictures and I just wanted to emphasize the semantic improvements of using xhtml and css.
And by the way, most table based sites out there are STILL using inline styling. Up untill CS5 Dreamweaver outputs that kind of code in its included layout templates which a lot of people are using.