Forum Moderators: not2easy
One of the biggest issues I have that prevents me from using <div> elements in place of <table><tr><td> elements is that a <div> reacts to its context, not its content, while a <table> reacts to its content.
This means that a <div> will always be 100%, or whatever specified width it is assigned, while a <table> will try to be whatever you assign, except when its content decides otherwise.
The most obvious incarnation of the <div> problem is the hideous "<div> overflow" that so many sites these days display.
My question is this: Is there a viable* way to get a <div> to react to its content? Can you make a <div> shrink to accommodate its content, as does a <table>? Can you make a <div> stretch when it has a big fat piece of content (like a big <img> or alotofrunontextwithabsolutelynowhitespacewhatsoeverthatforcesthedivtooverflow)?
Notice that there is no overflow here, because this site uses a <table> layout.
Discuss.
I'm actually very interested in this, as I am at yet another of those crossroads that tends to make me choose to use a <table> instead of a <div>.
*Making a <div> into a bad simulacrum of a <table> by using the dicey display:table CSS properties doesn't count. You're better off using a <table>.
[edited by: cmarshall at 8:18 pm (utc) on April 2, 2007]
The case I have now is a display of tabular data. In most cases, a <table> layout is the best solution, but this will also be getting output as WML (cWAP) and XHTML-MP, so <div> or <p> layout is a bit better for layout flow.
However, you have a good point, and I should experiment a bit more.
i can't say i've ever used them myself, so i don't know what exactly would happen. but maybe in there somewhere is your solution?
I have tried tableless layouts and found I can't for the same reason. I am working on a combination of TABLE/DIV with a little touch of JS to make it work. So far working very well, I'll publish my results when I'm done in the next few days hopefully.
But the answer is, 'display: inline' but as it was rightly pointed out, this option isn't really viable, unless you start using container DIVs but then you end up with more markup than if you'd just used a table in the first place.
Enough buts yet?
That's probably the best generic solution I could think of—I don't think using funky positioning would work in as many different scenarios, so it's not worth mentioning.
