Forum Moderators: open
I am no expert on css but I get the impression that rendering can vary dramatically between browsers.
I tried a nice sample layout which worked beautifully in Firefox but turned the columns into rows in IE.
I have yet to find a tutoral that will take css newbies through the process without assuming a mass of in-depth expertise.
It's all a learning process though - this'll take time. It's worth it in the long run.
<table> tags have a couple of SIGNIFICANT advantages over <div> tags, and the Zeldmanites often get sudden cell phone calls whenever I bring it up.
1) A <table> is robust as all hell. It will stretch, bend, fold spindle and mutilate. <div> tags have a glass jaw.
Try this on for size:
<div style="width:28px;border:1px solid red;background-color:yellow;padding:8px"><img src="a_200_by_48_pixel_black_gif.gif" alt="black" style="width:200px;height="48px" /></div>
Now, try this:
<table><tr><td style="width:28px;border:1px solid red;background-color:yellow;padding:8px"><img src="a_200_by_48_pixel_black_gif.gif" alt="black" style="width:200px;height="48px" /></td></tr></table>
If you will be creating pages with unpredictable content, you would be far better off using a <table>.
2) For a similar reason, a <table> is a much better option when you need to produce layout with certain vertical borders. I often use a "3D" appearance that uses "extruded" left and right page borders. I simply cannot get <divs> to display them correctly. They either jam the image up near the top, or they don't display at all. The flexibility of a <div> tag screws it here. The typical response is to create a single image the width of the layout, with sidebars, then stretch it down through an enclosing <div>. However, if I want flexible content, I can't depend on my content always playing nice with the enclosing <div>. A <table> tag requires that each cell scale to fit the table, so sidebars are always in sync with the content.
I would HIGHLY recommend leaving the Kool-Aid in the barrel. There is no "one, true answer."
That being said, I pretty much completely agree with the "no tables" crowd in 90% of applications. A table-less layout gives you a LOT more flexibility.
That being said, the myth of the legendary "CSS-only Designer" is just that: a myth. CSS design is a heavy-duty technical task, and not for the faint of heart. I write half-million-line C++ programs, and CSS design is every bit as difficult to get right as a bitchy C++ program.
There is NO WAY a graphic designer, with no real technical expertise, can "whip up some CSS." The CSS will ALWAYS need to be massaged by an alpha geek to make it work right across multiple browsers.
The CSS will ALWAYS
While I can see the rest of your points (even if I don't agree with them) the above is getting less and less true. When I first started doing this job cross browser CSS layout was a nightmare. These days a few workarounds for IE6 and 5.5 and everything else generally just works. That's the benefit of standards.
It's very simple, use CSS to control layout of the page and use tables to control the layout of collections of data/information.
Using advanced CSS to accomplish the same task as a table is just plain stupid. However, it is equally stupid to use tables to control page layout since this can be accomplished more easily with CSS.
Kaled.
While I can see the rest of your points (even if I don't agree with them) the above is getting less and less true.
It's that "less and less true" part that is the clincher.
I write sites that support NPOs, serving low-income and disabled people.
I need to support down to 5-level browsers (I just stopped supporting 4-level browsers last year).
Browser lifetimes are long. I expect to be needing to support 5-level browsers for the next year or two; at the very least.
If you don't agree, then I am curious as to how you would address that one, simple issue. If you can provide a viable workaround, then I will drop <table> layouts like a live cobra. I really do believe in the promise of <div>-centric design.
Using advanced CSS to accomplish the same task as a table is just plain stupid. However, it is equally stupid to use tables to control page layout since this can be accomplished more easily with CSS.
Here's some code:
<div style="width:28px;border:1px solid red;background-color:yellow;padding:8px"><img src="a_200_by_48_pixel_black_gif.gif" alt="black" style="width:200px;height="48px" /></div>
<br />
<br />
<table><tr><td style="width:28px;border:1px solid red;background-color:yellow;padding:8px"><img src="a_200_by_48_pixel_black_gif.gif" alt="black" style="width:200px;height="48px" /></td></tr></table>
Give me a solution that addresses this in a non-<table> layout, and I will gladly mea culpa.
NOTE: Henny Youngman-esque "Don't do that!" is not an acceptable answer. The layout MUST accept a very diverse range of content, including oversize images and complex tables.
Here's some code:<div style="width:28px;border:1px solid red;background-color:yellow;padding:8px"><img src="a_200_by_48_pixel_black_gif.gif" alt="black" style="width:200px;height="48px" /></div>
<br />
<br />
<table><tr><td style="width:28px;border:1px solid red;background-color:yellow;padding:8px"><img src="a_200_by_48_pixel_black_gif.gif" alt="black" style="width:200px;height="48px" /></td></tr></table>Give me a solution that addresses this in a non-<table> layout, and I will gladly mea culpa.
From my perspective, this is not a CSS problem. It's either a training issue--i.e. where somebody without adequate knowledge places too-large images in a container--or it's a similar issue with software (as with a CMS).
I can't see any reason for setting the width of a cell in a layout table unless that width is somehow important to the layout. If the width is important enough to be specified and it changes when something too-large is placed inside it, then the layout is still broken as far as I'm concerned.
Some of the higher-end CMS software can help with this problem by enabling the setting of maximum widths on images per layout region.
-b
If the width is important enough to be specified and it changes when something too-large is placed inside it, then the layout is still broken as far as I'm concerned.
No it's not.
I write sites that need to be maintained by numerous people, some, with little skills, and some, with more.
I simply write the containers, and they write the content. Think of it as a CMS, but stupider.
They WILL NOT ACCEPT "Don't do that!", because they see it being done all the time. I don't blame them.
If you have a site theme that must remain consistent when you jam a massive third-party event calender into it, then you need a robust, consistent layout.
You can either do a butt-ugly Nielsen site, or you can thumb your nose at the "purists," and design a site that looks great, works great, supports many, many browsers and is a downright pleasure to use and maintain.
I'm a nose-thumber, myself. I consider "You can't do that!" to be a glove on the floor. My clients very much appreciate what I do, and I don't lose a second's sleep over the thought of Zeldman using my picture as a dartboard. People are still alive because of the sites I design. I WILL NOT endanger someone's life over an academic ideal.
I've seen these challenges before and never see any CSSer lose. I see no reason to play these games.
I agree with bedlam. It's a training issue. There is no issue with using CSS over tables.
C'mon! I know you guys love a challenge!
So msn and espn and wired are wrong?
You're kidding, right?
Of course they're not wrong (except try running a validation on ESPN and Wired). That kind of binary framing isn't helpful at all.
They each are right for their own, controlled environments. If you control your environment, then, of course you can control your pages.
I have to play by a different set of rules. I set up a framework, then set it free to be done with as they will by experts and the unwashed masses alike.
As I said, the consequences for me being a purist are potentially catastrophic. I take my Web design pretty darn seriously. It ain't a textbook.
I love reading books, in which a thesis is presented and proved in 100 lines of code or less.
As any engineer will tell you, that all goes pear-shaped when the Reality Fairy comes tinkling along to the strains of Tchaikovsky, sprinkling 100,000 LOC programs around. So what if ESPN and Wired blow out the validator? They work, and that is what counts in the aggregate.
