homepage Welcome to WebmasterWorld Guest from 54.161.214.221
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Become a Pro Member

Home / Forums Index / Code, Content, and Presentation / HTML
Forum Library, Charter, Moderators: incrediBILL

HTML Forum

This 155 message thread spans 6 pages: < < 155 ( 1 2 3 4 [5] 6 > >     
Tables - What is so bad about them again?
SirTalksalot




msg:3704281
 9:49 am on Jul 22, 2008 (gmt 0)

Hi all,

I've had it driven into me for so long now that 'tables are for displaying data', and not to be used to format your page any more, and the way forward is forever CSS.

I've tried my best to stick with CSS, but I've always found it a massive pain in the ass compared to simply using tables. The text is still readble on a page, the links still work, what's the big deal?

In short, I'm thinking of making life a lot easier by simply reverting to tables for formatting, with a little CSS to tweak it. Is this really such a crime?

 

csuguy




msg:3732201
 7:53 am on Aug 27, 2008 (gmt 0)


Clearly we're not going to agree, because, I accept, you are seeing <table> as a design tool instead of as just an element.

Div has become a design tool as well - the only difference is that it is semantically correct. Well, that and you can't accomplish as much with just divs as you can with tables in the mix.

But your right - I'm going to see table's as a design tool for a long time. The benefits for tables outway any theoretical disadvantages. The only time I would ban the use of tables is if acquiring/maintaing a job depended on it. Wouldn't really be problem though - I know how to use css quite well.

amznVibe




msg:3732325
 12:18 pm on Aug 27, 2008 (gmt 0)

How true. However, what would you consider the contents of this page - tabular data?

Yes, it's a list of users tabulated with their meta, post and the post meta.

SuzyUK




msg:3732691
 7:12 pm on Aug 27, 2008 (gmt 0)

Yes, it's a list of users tabulated with their meta, post and the post

with that I have to agree, for this site anyway, the/any "design" is just not there ( well, I have it looking a bit prettier with a custom stylesheet as I hate the colors! - SEO blue/green if you really want to know! - the font tags could go and some classes introduced to cut the bloat) - in general design talk this is a flat forum (i.e. not threaded, you can't reply to individual posts) therefore each cell has a specific data header, user details, date posted, what amznVibe said: therefore a table fits. It will, and does, pass muster as far as this particular project goes.

There are wrong things, IMVHO, for instance take a look at the code it takes to produce a "blockquote" ([quote] - does that really need to be a nested table?

then if you read back a few years, although "CSS Makeovers" have been performed on this site you might now see that what it doesn't need is a total div replacement redesign.. but instead it needs very basic CSS - <blockquote> for a quote anyone? - or give us a proper BBCode for code, would you, seeing as how this is a code forum, instead of the nested table nightmare?

take a look at the bigger picture is what I say, do not cut off your nose in spite.. I've taught more people CSS USING tables than I have taking the holier than thou attitude.. and I can produce a CSS layout in my sleep :)

[edited by: SuzyUK at 7:21 pm (utc) on Aug. 27, 2008]

DrDoc




msg:3734056
 2:35 am on Aug 29, 2008 (gmt 0)

except for the fact that the browser most commonly used (*cough IE *cough) doesn't support it. Hence - CSS isn't as supported as tables.

For what it's worth -- IE does support CSS. And quite well, I might add. The (by far) most common IE versions are 6 and 7. I never have to "hack" to get things to work in either of them.

It is true that there are various features of tables that are not supported - but none that are required to get a table to display correctly. All you need is tr,td,th,rowspan,and colspan.

Well, in that case ... let's stick to only CSS features that are supported as well!

This whole argument is so pointless. People non-proficient with CSS can hardly argue that a CSS solution is inferior. People proficient with CSS never disagree that people who don't know CSS (but who do know tables) should stick to tables.

Use what you know, and be happy with it.

csuguy




msg:3734256
 12:21 pm on Aug 29, 2008 (gmt 0)


For what it's worth -- IE does support CSS. And quite well, I might add. The (by far) most common IE versions are 6 and 7. I never have to "hack" to get things to work in either of them.

IE does support css fairly well - but not to the point that it makes tables obsolete. And it certainly differs from standards - which is why all the hacks are needed. It does not support display:table or display:table-cell (why they didn't put display:grid I'll never know). And while you may have never had to design with hacks for IE 6/7, there are designs which require hacks.


Well, in that case ... let's stick to only CSS features that are supported as well!

Of course, you don't design with unsupported features. The problem is that css is limited, as I have shown on a number of points in this thread. Tables have not been replaced yet and are still valuable as a design tool.


This whole argument is so pointless. People non-proficient with CSS can hardly argue that a CSS solution is inferior. People proficient with CSS never disagree that people who don't know CSS (but who do know tables) should stick to tables.

But I know both ;) - so I can discuss both from a knowledgeable position. While I have more experience with tables - I am by no means inferior in my css skills. Therefore I am able to correctly analyze the strengths and weaknesses of both. Anyone who says that css has reached the point that it makes tables obsolete is only fooling themselves - or they haven't researched beyond the css-div only dogma. That's not to say that design can't be done without tables - but you become restricted. As you would also be restricted if you used only tables and no css.

ronin




msg:3734265
 12:39 pm on Aug 29, 2008 (gmt 0)

A couple of questions for those who consider tables a non-controversial layout tool:

1) When you want to make paragraphs, do you use: <br>&nbsp;<br> between blocks of text?
2) When you want to write a paragraph with larger copy, followed by a paragraph with smaller copy, do you surround the first para with <h2> tags and the second with <h4> tags?
3) When you want to indent a paragraph, do you use <pre>?
4) When you want to shift an element one pixel to the right, do you use a 1px spacer gif?
5) When you want to include a non-licensed image from another site on your webpage, do you hotlink to it?

I have to admit that in 1997-1998 I did all of these things. Further, I used tables as a page-layout tool until 2003.

Anyone who says that css has reached the point that it makes tables obsolete

I don't think obsolescence is the issue.

Have you tried making paragraphs using <br>&nbsp;<br> ?

That's not obsolete. I assure you, it works every time. >;->

tangor




msg:3734284
 12:57 pm on Aug 29, 2008 (gmt 0)

As a fellow who relied on tables for layout from 1996 to 2003 I see one side. As a fellow who now codes all NEW pages (2003 forward) as CSS I see one side.

I am not happy with either. But then again, I have a printing background and that's why. The web, however, is not PAPER and preservation of layout is only possible in limited fashion (PDF, FLASH, etc).

After wrestling with the problems for layout over the years I've come to the conclusion that CONTENT is the priority, thus presentation of the CONTENT is what matters. After making that decision I looked at how CONTENT can be most pleasingly presented REGARDLESS OF BROWSER or viewport size.

Thus I use a FRAME (I know! I know!) and insert the content and haven't looked back. And no probs with ranking either.

This topic is a tempest in a teapot. I suspect the table users these days use CSS to style the text/appearance. CSS'ers...give 'em time. They will come around when the time is right for that change.

Marshall




msg:3734440
 4:15 pm on Aug 29, 2008 (gmt 0)

Have you tried making paragraphs using <br>&nbsp;<br> ?

I believe you will find this is not considered accessibility friendly regardless what method you use to design a site.

Marshall

csuguy




msg:3734735
 11:35 pm on Aug 29, 2008 (gmt 0)


A couple of questions for those who consider tables a non-controversial layout tool:

But controversy is what makes tables so fun to use ;)


1) When you want to make paragraphs, do you use: <br>&nbsp;<br> between blocks of text?

I did for a long time, though I don't anymore.

2) When you want to write a paragraph with larger copy, followed by a paragraph with smaller copy, do you surround the first para with <h2> tags and the second with <h4> tags?

I never used Header tags for style, they never looked right to me. I always used the font tag (in the old days) to increase the font size.

3) When you want to indent a paragraph, do you use <pre>?

Nope.

4) When you want to shift an element one pixel to the right, do you use a 1px spacer gif?

No need for spacer gifs anymore. Although I have found use for the img tag with no src specified ;)

5) When you want to include a non-licensed image from another site on your webpage, do you hotlink to it?

nope.


I don't think obsolescence is the issue.

Have you tried making paragraphs using <br>&nbsp;<br> ?

That's not obsolete. I assure you, it works every time. >;->

You know what I mean. It's not that the support is there for table, its that there isn't support enough for css. In other words - if <p> is the standards equivalent of <br>, what is the standards equivalent of <table>? It most certainly isn't div - as much as people try to do it. In truth - there is no equivalent yet, and that's why its not obsolete. That's also why W3C standards still allow for layout tables ;).

[edited by: csuguy at 11:57 pm (utc) on Aug. 29, 2008]

csuguy




msg:3734737
 11:37 pm on Aug 29, 2008 (gmt 0)


Thus I use a FRAME (I know! I know!) and insert the content and haven't looked back. And no probs with ranking either.

I used these before I was using tables. I wish they had supported them a bit better! It's the server-side equivalent of includes!

ronin




msg:3734951
 1:46 pm on Aug 30, 2008 (gmt 0)

In other words - if <p> is the standards equivalent of <br>, what is the standards equivalent of <table>? It most certainly isn't div - as much as people try to do it.

>;->

I must be coming at this from the wrong angle.

By applying CSS to block-level elements (not only divs but also lists, paragraphs, headings, images and 'real' tables) you can:

1) Determine their width and height
2) Determine their padding, border thickness and margin (separately for each side if required)
2) Position them anywhere on the screen, relative to any of the four corners of the surrounding block-level element
3) Shift them up, down, left or right from where they would normally be in the document flow
4) Line them up in a row
5) Position them further back or further forward, giving your page layout 'depth' as well as height and breadth

I'm sure we could all name 25 things that you can do in a straightforward manner with CSS which would take several nested tables to achieve using tables. What is it precisely that you can do with layout tables that you cannot do with CSS?

Solution1




msg:3735015
 3:54 pm on Aug 30, 2008 (gmt 0)

What is it precisely that you can do with layout tables that you cannot do with CSS?

As I mentioned earlier in this thread:
You cannot do equal length columns in DIVs + CSS, when the contents of the columns change. In TABLEs it's simple and straightforward.

Tell me, how do you put a picture in the right bottom corner of a rectangle, when the height of the surrounding rectangle changes with changing content, and content needs to flow around the picture? You can float to the right with CSS, but you cannot float to the bottom...

csuguy




msg:3735231
 11:08 pm on Aug 30, 2008 (gmt 0)

@ronnin - see solution1's response, or go back and read my slightly earlier replies which say essentially the same thing. Also note that you can't vertically align divs or their block level contents.

Also - its not about what would be easier with straight css vs nested tables. Tables should be used with CSS - so that's a moot point.

theMaab




msg:3735325
 6:52 am on Aug 31, 2008 (gmt 0)

I agree, tables should not be used for the layout. I battled with it for a long time, because I couldn't get the CSS to do what I wanted. But I eventually got it and do not use any tables.

However, tables have their place. To display rows and columns of data. So I do not think they should be done away with altogether, but should be used for the 'intended' purpose. Also, tables still validate as xhtml. So it isn't 'wrong'.

I don't think you are punished for using tables in the layout either. I've seen many #1 ranking sites that have way over used tables in their layouts.

The reason you would use a CSS layout vs. a Table layout should be more of a personal thing if you ask me. If you look at the big scheme of things, for the Net, it makes sense and has a purpose.

mediaVinci




msg:3735404
 12:02 pm on Aug 31, 2008 (gmt 0)

> I've tried my best to stick with CSS, but I've always found it a massive pain in the ass compared to simply using tables.

I have made my own experiences using div layers for a long time. First I have started to play around a lot with "Netscape Layers" after that I started to play around a lot with css layers.

However, after having spent a lot of time and investigation in developing web page layouts by using css layers, I have finally switched back using "Tables & CSS Styles" or a combination of both " Tables & CSS styles & Layers".

Tables are very suitable on my opinion for creating a simple, clean and flexible web page layout in minutes. Creating a clean and user-friendly web page layout often requires to develop a suitable framework that resembles a little bit like a chessboard.

So, instead of "re-creating" the chessboard-like web page layout and framework by placing each single rectangular css layer separately, I prefer to use a table which is offering me all the features I need to achieve my goal.

If you consider a table as a "container" you will see that it offers many advantages compared to div layers.

Especially in the case when a web developer starts applying CSS classes to the individual tags of a table such as

<table class="...">

<tr class="...">
<td class="...>

The other big advantage of a table is the fact that you have all the cells and rows attached(!) to a surrounding container which keeps all the including cell elements and rows in a flexible and adjustable scale and position.

Web developers who are using css layers in the end are re-creating table-like layouts by nesting a div into a div and so on. Strangely, these users are saying that "nesting" elements is a "bad thing" to do. However, they are following a very similar technique by by using div layers.

Nesting tables is not a "bad thing" either.

And my recent website project again clearly proofs:

" Web designers and developers could AVOID using rather complicated table structures IF browser developers such as Microsoft Internet Explorer would start to render tables using colspan and rowspan PROPERLY.

More than 10 years(!) of browser development have past by now and one MAJOR browser developer is still having problems rendering a VERY simply formatted table structure? After more than 1o years?

So, instead of maintaining a VERY simple table structure, I have to invent a MORE complicated solution to FORCE a major browser like IE to achieve the SAME result.

And all this bug-fixing starts LL over again and is getting even worse by using css-only layouts.

Sometimes, I am wondering who was the one on the internet who has spread out the rumor that css layouts are "more" search-engine friendly than websites built with tables?

This is simply NOT true. It is just a RUMOR and pure PROPAGANDA.

So, table on folks if it works well for you!

graphically & sincerely,

Marc Klein

tedster




msg:3735482
 4:27 pm on Aug 31, 2008 (gmt 0)

The difference in opinion and usage often come from point-of-view. People with a background in print design are accustomed to thinking visually and using a layout grid. Those who only think about a visual browser also naturally gravitate to that kind of thinking. It seems quite intuitive and natural, whereas CSS positioning adds a further layer of abstraction to the process of creating web documents.

Those who have a different approach to the web - seeing that information and structure can (even should be) be two separate things - also see the potential strength of CSS positioning.

And still, the tool of CSS positioning can be frustratingly obtuse in practice, especially for time-sensitive commercial projects.

Things might be different by now if HTML standards hadn't taken a left turn early on and had to be herded back. Or if browser support had been serious in the early days. I first tried to learn CSS in 1997, but I had to give up because there was no way to know whether I made a mistake or the browser did!

Solution1




msg:3735523
 6:08 pm on Aug 31, 2008 (gmt 0)

Those who have a different approach to the web - seeing that information and structure can (even should be) be two separate things - also see the potential strength of CSS positioning.

If you take a look at the source code of this current webpage, built with TABLEs, you'll see that information and structure are, in fact, separated. Information comes from database tables, and is inserted into a template.

With the use of server side scripting, a template can be made entirely with TABLEs, FONT tags, all kinds of HTML attributes, and no CSS - and still information and structure are perfectly separated. There often isn't really a need to use CSS and DIVs for that.

csuguy




msg:3735586
 8:16 pm on Aug 31, 2008 (gmt 0)

Where have you been Solution1? That's exactly what I've been saying!

Stefan




msg:3735654
 11:35 pm on Aug 31, 2008 (gmt 0)

I'm sure we could all name 25 things that you can do in a straightforward manner with CSS which would take several nested tables to achieve using tables. What is it precisely that you can do with layout tables that you cannot do with CSS?

Ronin, you make a great case for the advantages of CSS, and I'm convinced. However, I simply don't have the time to switch to it, because it's so complicated. My main site exists only to share info on the activities of an ENGO that I'm the head of. We have a great backlog of data/info to get online, and I can do it fastest with very crude, simple html code (e.g. a paragraph break for me is <br><br>). There is no site-wide template (it all develops organically, and is variable in the extreme), and the navigation is ad hoc (although G finds all of it, and treats us well). No matter, because our visitors are after the content, not the wrapper.

So, respect, you're right, but my time is better spent adding content, using simple tables, in order to concentrate on the substance. If it doesn't render perfectly, so it goes. If I ever have a couple of months with nothing else to do, I'll figure out CSS.

Solution1




msg:3735766
 5:23 am on Sep 1, 2008 (gmt 0)

Where have you been Solution1? That's exactly what I've been saying!

Sure you did. And it was worth saying again.

old_expat




msg:3738859
 7:02 am on Sep 5, 2008 (gmt 0)

I keep wondering why on earth these "Tables vs. CSS" comments don't address the core issue >> "Tables vs. "No Tables/Floating Divs". "Tables" and "CSS" are not necessarily mutually exclusive.

Leave the poor CSS alone .. it swings both ways.

A basic 3 column table (or 2 column, for that matter) can be chock full of divs prettily decorated with CSS in the innards of the columns.

Tables with CSS are easy. Floating divs, and incompatible browsers can be a b****! .. especially for me .. for an elastic layout

csuguy




msg:3739422
 10:32 pm on Sep 5, 2008 (gmt 0)


for an elastic layout

Maybe it's just me, but I never liked elastic layouts. Just doesn't feel right, but that could be from programming one to many 800x600 sites.

ronin




msg:3740093
 5:59 pm on Sep 7, 2008 (gmt 0)

"Tables" and "CSS" are not necessarily mutually exclusive.

Quite right. Tables are a perfectly respectable element. It's the practice of employing them as a hack to lay out page designs which is questionable.

The only difference between "Layout Tables" and "Layout Lists" is that no-one uses the latter.

Solution1 and csuguy> Blow me down, you were right! You can't get the CSS-styled backgrounds of columnar divs containing variable content to stay the same height. I found it relatively easy (using floats) if I knew that one column would always be the tallest, but otherwise I couldn't make it happen. So, I've learned something, thanks.

Somehow though, the fact that CSS can't do this yet, didn't seem like a good reason to switch to layout tables given that the finished product is what counts and, at the end of the day, (for me at least) what a web page looks like in a browser to a sighted human is less important (on a scale) than how cross-platform, machine-readable the underlying document is.

[edited by: tedster at 6:24 pm (utc) on Sep. 7, 2008]

npwsol




msg:3740542
 4:20 pm on Sep 8, 2008 (gmt 0)

Ronin - If you're on a fixed width layout, you can use a background image on a container (containing each of your columns) element to simulate the effect. While some might consider this a "hack," it's a perfectly standards compliant method to achieve the effect you're looking for.

The only thing not elastic about this method is the width, which is typically how I typically build sites anyway. I find there are too many rounding errors on relative sizes across browsers to stand beside variable width sites. With regards to background images and other width dependant elements, tables do nothing to resolve these problems either. :)

I had an idea rolling around in my head to use PHP or another server-side language to resize background images when appropriate (potentially starting with a massive base image to avoid quality loss, a la Willy Wonka sending chocolate through your TV), but I don't know of a way to note the "zoom" level the browser is on, or what event to handle to adjust to this. But that's neither here nor there for this discussion.

CSU and Solution - Calling information from a database is not the kind of separating content from structure we talk about with regards to CSS. True, it is technically separate, but what we refer to is the use of tags like "font" to adjust the appearance of markup. Yes, this even applies to tables. The idea, of course, is to use only semantically relevant tags, and then use markup to adjust the appearance. Suzy is right on the money when she suggests that the quote tag should use blockquote instead of tables. Not only do you save yourself some markup, but you also limit the number of tables you have to differentiate between.

Another part of separating content from structure is making sure that the elements around your content don't define their structure. I don't want any width attributes or hspace or vertical alignment properties in my markup, because it clutters things up and it's really not relevant to the content I'm going to be displaying. This is something you can avoid doing with tables as well, but requires a bit more markup (since you have to adjust both the table and td elements at the least).

Of course, this is general principle I'm speaking about. In practice, I find myself using inline styles (which are just as bad as HTML attributes) in cases where I'm making a quick adjustment.

This may not be a hassle for people who use tables a lot. Indeed, I don't even find table layouts all that difficult to use (granted, all my sites used to be tabled layouts).

csuguy, I can do anything with CSS that you can do with a table (well, I can't mimick a table, but why would I?). This requires you to not eliminate certain properties from my metaphorical playbook, however. What's better is that I can do it with less markup and in a more mantainable (readable) manner.

I'll go another step. I could mimick WebmasterWorld's layout with divs. One of these thread-view pages is 80kb in size. I could cut that in half with CSS and semantic markup. I don't know the usage statistics for WebmasterWorld, but I'm fairly certain it would cut down significantly on their bandwidth consumption.

In defense of the filesize here, it's extremely dependant on the size and number of posts the page is displaying, but the amount of markup is positively massive.

So, what's so bad about tables? Nothing, really, if you know what you're doing. So then, what's so bad about DIVs and CSS? Nothing, really, if you know what you're doing.

The problem with tables is when you start nesting them to achieve layout/structural/positioning effects. Go ahead and use them if that's what works for you, but for the love of god, if I see one more site with five tables opened before you get to the first bit of content, I will have to murder the internet. These sites are not even remotely easy to maintain by someone who doesn't usually work with tables (or by anybody if it's not properly indented), and they bloat faster than Rush Limbaugh at an all-you-can-eat buffet.

The problems with CSS occur when: you catch divitis or classitis. Divitis is when you start replacing conventional, semantic markup with divs. I caught a bad case of both when I first started with CSS and it made my life a living nightmare. Overusing classes usually wound up in me creating a class for every active element (highly counter-productive). Oh, god, not to mention the cascade issues; classes are only worth ten points, and if you try to layer them in your CSS (.parentClass .childClass {), you'll start to run into some issues. Overusing divs made it nigh-impossible to read my source code. Divs became every element I wanted, and while it may have worked, it's the same issue you have with tables: too much similar and confusing markup. I use divs now as a framework/container elements. Ctr { Header, Navigation, ContentCtr {SideBar(2?), Content}, Footer }. Beyond that, they're used to denote sections and special elements (testimonials which require special formatting, for instance).

In short, neither method is inherently bad or good, so do as you will. Just know that you could be a bad programmer (and still make a site that functions).

I will continue to vehemently defend divs and CSS as the way of the future, and making sites in the future will be a quicker, more efficient process for me because I took the time to work with and understand the "new technology." I'll daresay it's already much quicker for me. :)

Demaestro




msg:3740554
 4:37 pm on Sep 8, 2008 (gmt 0)

Yes, it's a list of users tabulated with their meta, post and the post

Then why would it be wrong to use <th> tags?

Everyone who is saying tables are ok for layouts agrees that using <th> is bad for layouts... why? If a site, this site included is truly a form of tabular data then headings wouldn't be wrong.

ronin




msg:3743686
 4:46 pm on Sep 12, 2008 (gmt 0)

Tumbleweed blows past...

It's alright, Demaestro, the reason why they aren't replying is because at some level, they do know that using tables as a 2D layout tool as if HTML were Desktop-Publishing-for-the-Web is a hack and always was, from the moment it was first introduced (in 1995? 1996?). Not that for the time, it wasn't a pretty good hack - it overcame a lot of the design limitations that we otherwise had to cope with.

Take the time to learn CSS-P properly guys - as web design professionals it will be one of the biggest favours you can ever grant yourselves. Think of it as progressing from Doggy-Paddling to the Crawl.

It took me until 2004 to get around to learning how to design in CSS properly, but since then designing layouts has felt like waking up on Christmas morning at the age of seven. It's quick, easy and best of all, fun.

ronin




msg:3743864
 9:06 pm on Sep 12, 2008 (gmt 0)

Ouch. Sorry, that wasn't supposed to come across so revoltingly patronisingly. Allow me to frame those comments: I just don't want to be working in a technological environment which insists on harking back to the mid-nineties when hacks were needed.

Maybe when HTML 5 and CSS 3 are widespread this whole debate will look very antiquated, but it's difficult enough to promote uptake of new browsers... how is the job of user agents made any easier when web-architects refuse to let go of tables?

Personally, I feel it's long past high time that we all dropped table-based layouts and moved on. Otherwise, I'm genuinely afraid that a lot of the web in 2015 is not going to look much different from how it does now. And I think we can all do better.

tedster




msg:3743900
 10:34 pm on Sep 12, 2008 (gmt 0)

The thing is, I went BACK to table based layout - just for the main layout grid - after giving CSS layouts a real go a couple years back. I recently tried again, and still with all the browser strangeness, it's just not commercially viable IMO.

A few more browser versions and maybe I'll be back to CSS positioned divs. But not if it hits in the wallet!

amznVibe




msg:3744602
 2:28 pm on Sep 14, 2008 (gmt 0)

By the way, from a javascript standpoint, walking a table with it's well designed rows and columns and cells is far faster in all browsers than fetching the elementid or class for various CSS objects in the DOM.

SuzyUK




msg:3749182
 8:51 pm on Sep 21, 2008 (gmt 0)

what Ted says will go.. (we're so used to that opinion it now becomes up to you to decide, ted's been a member for 8 years yet he's giving his opinion of the last 2!) and as for the JS standpoint then let me just rewind a few years ;) "walking a table" is simply walking the DOM which is exactly what CSS suggests style for.. after you've marked up your content (or laid out your DOM, if that's easier) that is.

[edited by: SuzyUK at 9:03 pm (utc) on Sep. 21, 2008]

dukelips




msg:3754324
 10:42 am on Sep 29, 2008 (gmt 0)

Designing layouts for Content Management Systems is easier to do in tables than in css.

Then y do people keep saying that tables should not be used,

This 155 message thread spans 6 pages: < < 155 ( 1 2 3 4 [5] 6 > >
Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Code, Content, and Presentation / HTML
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved