# [web] Table limit in IE?

This topic is 4752 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

## Recommended Posts

I have a question for all you Internet explorer troubleshooting gurus, is there perhaps a limit of table depth? That is to say, a table within a table within a table within a table andso on to infinity? Because I've got a website working just fine in Firefox, but as soon as I open it up in IE, everything is out of shape, and I mean, BADLY out of shape. And I have LOTS of nested tables, I so I figured that might have something to do with the problem? Or, well, something to do with the solution to IE's problem? If anyone could enlighten me, I'd appreciate it.

#### Share this post

##### Share on other sites
Use divs and css for positioning and your life will be happier (even better if you use the ie7 javascript hack to correct all IE badness).

In leui of that be sure all of your tables rows and cells are closed correctly and that you are using as few rowspans as possible, preferably none. I have never encountered a limit to the amount you can nest tables, although it is a good idea to keep nesting to the minimum needed to achieve your layout.

Peace.

#### Share this post

##### Share on other sites
Yes, I do not believe neither browser has a (practical) limit for how many tables deep a nest can go.

I'd suggest doing what Anonymous Poster suggested, use divs and css.

Out of curiousity, how many tables are in your biggest nest?

#### Share this post

##### Share on other sites
How deep do my tables go currently? Umm, not having the code on me at this moment, IIRC, it was around 6-7 or so. I don't use any 'rowspan', only 'colspan', as I have never encountered a situation that required 'rowspan' [smile].

Regarding tables with
and css, well, currently, I'm using
s a bit, mainly for scrolling tables, but css tables? That I've never heard of, although I'll admit I haven't heard of nearly everything that is part of web pages :) If either of you, anonymous poster, or fraKtal could produce a link to a guide as to how this works, I'd be most obliged? Thanks!

#### Share this post

##### Share on other sites
The big question is, what kind of data are you putting on a web page that requires 6 or 7 nested tables? That seems a bit excessive.

#### Share this post

##### Share on other sites
Check out this thread, as it has a bunch of really good links to various resources for css & web related stuff.

Hope that helps!

#### Share this post

##### Share on other sites
Quote:
 Original post by Anonymous PosterThe big question is, what kind of data are you putting on a web page that requires 6 or 7 nested tables? That seems a bit excessive.

It's for the design, not any data set. I was going to do it with frames first, but I figured that was an even worse conclusion :D

#### Share this post

##### Share on other sites
Argh, you all know that feeling of utter stupidity, which makes you want to kick yourself in the head the solution was so simple? That's right, I've got that going in high gear right now [smile]. I've spent all day on this, only to finally realize that I was missing 1 '>' out of around 40KB of code.. It makes me sick to think that I wasted around 7 hours on that :D If only there was an HTML debugger! [grin] What really threw me off is that it worked fine in Firefox, because I figured if it was something as large as a missing '>' it would be picked up by firefox, and screw up there as well. At any rate, I can say with great pleasure that my problem is no fixed. Thanks a lot for you help guys, even though it wasn't relevant in the end, as remember, it's the thought that counts!

#### Share this post

##### Share on other sites
I had this problem once.

Turned out, I had to put a NEWLINE (<BR>) after a obviously too wide image. Uggh..

#### Share this post

##### Share on other sites
Quote:
 Original post by SirLuthorIf only there was an HTML debugger! [grin]

You mean something like this? (Online version!)

#### Share this post

##### Share on other sites
Quote:
 It's for the design, not any data set. I was going to do it with frames first, but I figured that was an even worse conclusion :D
Sweet merciful crap! 8 NESTED tables for a layout?

Here is what the body of your site should look like:

<div id="masthead">  <img src="logo.png" alt="my web site"/></div><div id="content">  <p>Insert content here.</p></div><div id="navigation">  <ul>    <li><a href="page.html">Page 1</a></li>    <li><a href="page2.html">Another page</a></li>  </ul></div>

#### Share this post

##### Share on other sites
Nested tables are a horrid, horrid way to do site layout. It wastes bandwidth, kills rendering speed, and gives you zero ability to make significant changes later.

Use tables for what they're for -- displaying tabular data.

Take a look at my site to see a simple real-world application of table-less layout. Better yet, look at CSS Zen Garden to see the possibilities.

#### Share this post

##### Share on other sites
Quote:
 Original post by EtnuNested tables are a horrid, horrid way to do site layout. It wastes bandwidth, kills rendering speed, and gives you zero ability to make significant changes later.Use tables for what they're for -- displaying tabular data. Take a look at my site to see a simple real-world application of table-less layout. Better yet, look at CSS Zen Garden to see the possibilities.

On a recount, I'v actually got 4 nested tables, I did a little bit of optimization..

I'm interested in the facts behind that first paragraph? I'm aware it's slightly slower then normal to render, but the slowdown is a little less then 1/8 of a second or so for me right now, and I don't really know where you get that 'wastes bandwidth'? I'm fully aware that you probably know quite a few times more then I on this matter, but honestly, I can't see the facts behind that one?

Also, 'and gives you zero ability to make significant changes later.'? I'm curious as to how you come to that conclusion? I've got the first three tables for the layout, and then one more defined in each php file (all of the 'require()-ed') for defining how the data is desplayed in it's section of the layout. I don't see how that gives me zero ability to make significant changes? I may have to rewrite a few lines of code in a specific .php file, but other then that?

I'm very curious.. Please explain your reasoning, as I would find it most enlightening?

BTW, CSS tables are a little beyond my grasp at this point, I'm sure I'll finally get the idea sooner or later, but at this point.. Me == baffled [smile]

#### Share this post

##### Share on other sites
I assume that when Etnu was talking about bandwidth, he was referring to the extra table/tr/td HTML bloat that would result from using 8 layers of tables. The corresponding div-based HTML would mean the code would be a lot shorter. To be fair, the only real people to notice would be those on a slow connection - but the real issue is the layout change issue.

Let me highlight with an example from my own past experiences. I used to run a website for a band a few years ago. In order to appear 'energetic' and 'in touch' they liked to have a whole new website every 6 months to a year, but they needed to keep pretty much the same content and structure - it was just the layout that needed changing. Back then I was a huge fan of tables, so the entire site was coded up with them as tables are generally cross-browser friendly, unlike their div/css companions. Remember that this was before IE5 was as big as it was, IE4 was pretty bad for this sort of thing.

So when it came to redesigning the site, I had to pull out all of the old content and restructure several layers of tables to reposition things. I used tablecells for spacing, positioning and all sorts of hacks to make the site look good so it was a real chore to redesign the pages. After it went live, the band decided that they'd like a coupld of (what they saw as) minor changes to the layout - due to my nesting of tables it required me to yet again redesign a large portion of the site to accomodate this.

Now that CSS is popular and browser support is pretty good (not perfect, but it's getting better) I'd never dream of using a table-based layout in the same way again. Take a look at my website for example - it's completely CSS-based (look at the source). Sure, a similar site could be created using tables but changing the layout would be extremely difficult. At present I can create an entirely new layout by changing one or two (at the most) files and still get similar results as it's table-based counterpart.

If you're having no problems with your current system then stick with it - but I think once you go CSS/DHTML you'll be pleasantly suprised with the results.

#### Share this post

##### Share on other sites
Just a note though, if you do decide to use css, be sure you have plenty of patience.

It took me days to get my site working half decently in IE/Firefox. And if you look at the page source, there's a whole bunch of bandwidth wasting divs that were necessary to get the layout I wanted while still remaining liquid.

#### Share this post

##### Share on other sites
Just to answer the original post: Yes, there is (maybe not anymore) a limit on nesting tables and IIRC it was somewhere around 12-15 levels deep.

#### Share this post

##### Share on other sites
Quote:
 Original post by SirLuthorI'm interested in the facts behind that first paragraph? I'm aware it's slightly slower then normal to render, but the slowdown is a little less then 1/8 of a second or so for me right now, and I don't really know where you get that 'wastes bandwidth'? I'm fully aware that you probably know quite a few times more then I on this matter, but honestly, I can't see the facts behind that one?

To render a table, a browser has to scan it twice. First, it calculates the maximum width and height for each column, then it goes back and draws the elements correctly. You notice immediate improvement with css-based layout.

Quote:
 Also, 'and gives you zero ability to make significant changes later.'? I'm curious as to how you come to that conclusion? I've got the first three tables for the layout, and then one more defined in each php file (all of the 'require()-ed') for defining how the data is desplayed in it's section of the layout. I don't see how that gives me zero ability to make significant changes? I may have to rewrite a few lines of code in a specific .php file, but other then that?

What happens if you decide that you want to change your layout from a two-column setup to a 1-column setup? That's just a simple example, but it all comes back to the same thing: lots of code and / or html changes that could be done in a few seconds with a css based approach.

Quote:
 BTW, CSS tables are a little beyond my grasp at this point, I'm sure I'll finally get the idea sooner or later, but at this point.. Me == baffled [smile]

There is no such thing as a "CSS table". Use tables for what they're for -- tabular data. Tables were not created as a layout tool, and aren't meant to be used as such.

#### Share this post

##### Share on other sites
Quote:
 Original post by evolutionalI assume that when Etnu was talking about bandwidth, he was referring to the extra table/tr/td HTML bloat that would result from using 8 layers of tables. The corresponding div-based HTML would mean the code would be a lot shorter. To be fair, the only real people to notice would be those on a slow connection - but the real issue is the layout change issue.

Actually, the bandwidth differences can be quite significant. There's an article on a list apart where they redid the slashdot front page, and, based on their bandwidth usage in 2001, would save them ~ \$8,000 a year in bandwidth costs alone.

This becomes a big issue for sites that serve millions of users per day. Say the average user visits 5 pages on your site per day, at an average of 50-100KB each hit (not counting images, since those are cached anyway). (these estimates come from my current employer's average page size).
5x75 = 375KB / user.
375 / user x 1,000,000 users = 357.7GB / day of bandwidth every single day.

And that doesn't even include image bandwidth. Again, though, images are cached so in all likelyhood you're using a lot less bandwidth here than on your markup.

Cutting your average page size down from the 75KB figure above to 35KB (an improvement well within reasonable expectations), will cut your bandwidth costs in half.

#### Share this post

##### Share on other sites
Etnu, thanks for explaining what you were talking about, I do, at this point, see what you're getting at [smile] Anyway, at this point though, this page I don't expect to get 1M+ hits per day, month, nor probably even year, so at any rate the bandwidth is not a problem!

#### Share this post

##### Share on other sites
That's fine, but you still have to worry about the W3 Gestapo.

#### Share this post

##### Share on other sites
Indeex :/ But, at any rate, every time I've run the pages through their validator so far, they've come up clean, so, so far, so good. Clean, but ugly [grin]

#### Share this post

##### Share on other sites
Firefox has no IFRAME inside IFRAME limit (IE does) I wrote a script to dynamically generate iframes in them selves... Instant crash. :D

#### Share this post

##### Share on other sites

This topic is 4752 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

## Create an account or sign in to comment

You need to be a member in order to leave a comment

## Create an account

Sign up for a new account in our community. It's easy!

Register a new account

## Sign in

Already have an account? Sign in here.

Sign In Now

• ### Forum Statistics

• Total Topics
628710
• Total Posts
2984319

• 23
• 11
• 9
• 13
• 14