Why do people wish for tableless with CSS?

[cashblogs]

Hello members

I've always wondered why, I found an answer in bandwidth economy, but other than that, how do they expect us to do it? With padding?
Any advice, comments?
thanks

[stymiee]

Why is easy:

1) Easier to update
2) Faster loading pages
3) More control

[MattEvans]

Sometimes you can do things that could be done with tables with CSS instead; sometimes you can't, or it just becomes close to a waste of time trying (if you find your almost para-implementing tables with CSS + javscript, you're certainly wasting your time).

i guess the thinking is that a table is a restrictive structure (defined in markup) and CSS can be modular (by using different stylesheets)

CSS and tables aren't incompatible or exclusive. If you're being asked to do something without tables, you should ask the person commissioning you if they have a good reason why not to use them; and a reason based on heresay/myth-mongering isn't a valid one.

Here's some myths to dispell:

Myth - Screenreaders can't read tables
Fact - Well organised tables are easier to read in logical order (using a markup-based screenreader) than a load of floating/absolutely placed elements.

Myth - Tables are deprecated in the latest W3C HTML specs.:
Fact - Tables are not deprecated in any HTML or XHTML specification, although the WAI do advise against the use of tables in circumstances where they are inapropriate, or could be confusing if linearized.

Myth - Search engines don't like tables, a site without tables is going to get a lower rank in a search engine.
Fact - Search spiders don't like confusing or invalid markup, but they are intelliigent enough to work out what is markup and what is keywordable data. If your headings and primary keywords are in a table, you could probably organise your page better; but a spider just sees valid block level elements containing text, in the same way it would see any hierachy of block level elements.

Myth - Tables make my markup longer.
Fact - If your markup is shorter without some tables and still does what you want it to, then it probably wasn't neccessary to use those table in the first place. Standard "CSS-only" replacements for tables (which tend to make use of <div> elements in replacement) often contain at least as many <div> elements than <table>,<tr> and <td> elements in a table approach, and often suffer from browser compatibility issues or have a 'breaking threshold' (the point at which either a screen size or data length cause visual messiness) far lower than a table.

This is getting to be something I reiterate quite often. You'll find it's worth researching how to do things using different methods, but it's not worth restricting yourself in any direction for any reason.

[MattEvans]

Why is easy:

1) Easier to update
2) Faster loading pages
3) More control

That went through as I was typing out my micro-essay...

As a rebuttal to 1, that depends entirely on how you update pages.

Tweaking the position of things is not the same as changing content, and a big style change usually involves some markup changing anyway.

In agreement with 2, in some circumstances.

In partial agreement with 3, except that a table is a controllable entity in itself, and sometimes control is more controllable when it's controlled. ^_-

[FC Jamison]

Ha!

It really is a preference issue.

Most people will tell you that tables were created exclusively to hold tabular data...and that any other use is wrong.

Since we have been using tables long before CSS, this is obviously false.

If your client doesn't care and you are GOOD at using tables, knock yourself out. If you are using 50 tables to position items on a small page, however, you should really look into learning CSS.

[stymiee]

ost people will tell you that tables were created exclusively to hold tabular data...and that any other use is wrong.

Since we have been using tables long before CSS, this is obviously false.

That's because tables were the only way to control a page's layout. Until CSS came along, and was fully supported, it was either use tables (incorrectly) or have a basic top-to-bottom page. In other words, using tables were a hack.

Tables are meant for tabular data.

[roryt]

That's because tables were the only way to control a page's layout. Until CSS came along, and was fully supported, it was either use tables (incorrectly) or have a basic top-to-bottom page. In other words, using tables were a hack.

Tables are meant for tabular data.

That is a perfect way of putting it. I also think one of the most important things for me is how much neater and easier to edit your html becomes.

The other day I had to make a quick design for someone who wanted to add all the server-side stuff themselves and they asked me to do it with tables and it took me I would say (with no exageration) about 10 or 20 times longer to do it than if I had just used css and no tables.

[FC Jamison]

That depends on what you consider "wrong."

Technically, yes, according to the W3C, tables for layout is "wrong." I think browsers still have a little way to go in the way of rendering CSS uniformly across platforms, so sometimes a table is easier for those who are familiar with them.

I personally use CSS...but I won't hang someone who doesn't (unless they are working on my site).

Hey...I've been known to use a screwdriver for a chisel in the past. It may not be "right"...but it works in a pinch.

[MattEvans]

I think a definate distinction needs to be drawn between designing with less tables, and tableless design.

Rigidly tableless design is as logically defunct as throwing all of the screwdrivers out of your toolbox because a chisel is good for presentation.
Mythical "CSS-only" chisels cause as much of a mess to the screwhead of any tabular data layout (which may or may not be presented as a table of figures) as a screwdriver would to a woodcarving.

Design with less tables is a process of natural selection. If "CSS-only" (which is an absolute myth anyway) could do everything tables could do, and reliably, and with the same markup overhead, and without being overall more hacky than a table solution, nobody would use tables; even if it were only to escape pre-spoken criticism.

All HTML markup is presentational to a point; HTML has almost none of the useful features a data definition language would have, and yet it's widely spoken as being 'data' that needs to be separated from presentation. All CSS solutions require markup, otherwise you have one element to work with; <body> (and even then you need a little markup).

You'll find, that the best designed websites and the best website designers make good use of the inherant advantages of tables, where and when they are appropriate.

I think it'd also be good to talk about the different types of website. Flashy graphical one-to-five page info-sites that never change unless the "website designer" gets another hefty contract payment probably never need a table. Each page can be carefully designed and tested on every browser version, and it'll always look good because it'll never change anyway.

Sites that present dynamic lists of anything (forums are a good example) will almost always use a table to present something, somewhere. Tables line up their rows and columns, tables are easily visually interpretable, tables can easily be populated from a database. Using a combination of HTML DIVs and SPANs and CSS to emulate a tabular layout for the data is always going to be 150% hacky.

In essence, this is exactly as the W3C put it, tabular data (possibly taken directly from a database table) could be presented in a table, and for the most part, should be presented in a table.

The same applies whether the HTML data is manually entered or automatically generated, provided there is some logical or meta-logical link between "these values" and "those values". In essence XML itself (and thus XHTML, and thus HTML if you agree that HTML is essentially occasionally-closure-implicit XHTML) is an arbitrarily-dimensioned nested tabular structure.

Where the path between data organisation and data layout lies will for the most part, and providing you're not aiming to confuse, fall along parallel lines. I fail to understand why double-implementing those lines could be of any benefit to anyone. Applying positioning CSS to a load of identically classed objects to arrange data that could be better organised seems somewhat backwards to me. Perhaps these CSS-only designers are aiming for totally content-ordered-markup, which seems to be mostly an SEO myth.

If you want to design without tables, definately try it. If you use one table where it's appropriate, you don't design without tables, you (perhaps) design with less tables. Neither way is inherantly wrong.

[mrclean]

In order to keep up with the "trend" of modern design techniques you should really learn CSS and tableless (or less-table ;)) design practices. The key benefits I can think are as follows:

1) Using CSS makes your site more accessible to those with disablities and textbased web browsers (Lynx).
2) CSS makes your code easier to read and understand by search engine bots. (and yourself sometimes)
3) It's good practice to keep your Presentation/Layout layer seperate from your Data/Content layer. (updating is in-fact easier).

Think of it this way: You wouldn't use Excel to design a webpage so why would you use tables. Move on to CSS and don't look back.

[MattEvans]

In order to keep up with the "trend" of modern design techniques you should really learn CSS and tableless (or less-table ) design practices. The key benefits I can think are as follows:

1) Using CSS makes your site more accessible to those with disablities and textbased web browsers (Lynx).
2) CSS makes your code easier to read and understand by search engine bots. (and yourself sometimes)
3) It's good practice to keep your Presentation/Layout layer seperate from your Data/Content layer. (updating is in-fact easier).

Think of it this way: You wouldn't use Excel to design a webpage so why would you use tables. Move on to CSS and don't look back.

Webpages with CSS are nothing without HTML ^_-

Perhaps my fault, but the thread thinking has deviated into assuming tabled designs make no use of CSS. This is far from the truth.

CSS by itself does not make sites more accessable, or search engines more effiicient. Using CSS may make sites more accessable, or it may make them less accessable.

Consider, a user with moderate long-sightedness; who prefers to view pages without any stylesheets atall. Not by overriding certain stylesheet rules, but by completely overruling stylesheets.

Anything now that uses CSS to re-order page content in a "tabular fashion" fails immediately and to the user, un- interpretably. Any organisiton of data is now as the document would read in markup, with markup-standard headings, fonts, and positions where elements are used. Tables noteably, still hold data in the same relative place.

Consider now, that instead of overulling stylesheets, the user reads a site with tables with their screenreader. The screenreader is optimized to deal with tables intelligently, as a table can be logically split into columns and rows, and read in a user specified order, perhaps with an aural repeat of headings on every other row for clarification. Even visually, a linearized table can still be interpretted using a reading convention rather than a series of reading assumptions.

A site using CSS to rearange content will hit a potential problem, depending on the screenreader used. Unfortumately, screenreaders are not a very well developed end of the software industry; ones I have tried only read in markup-order, and do not respect relative positioning of text blocks with respect to reading order. Of course, this favours well organised content. But it doesn't take CSS into account whatsoever (aural CSS rules do apply, but visual rules for the most part do not apply, and/or are not well standardized).

Using CSS makes your code as easy to understand as your code without CSS is easy to understand. If your code is not easy to understand, CSS will make it no easier. If your code is easy to understand, a lack of CSS will not make it more difficult.

It is good practise to keep the data and presentation layer separate, CSS and HTML are both presentation layers. Lynx sees HTML as the only presentation layer. Lynx doesn't care what your CSS stylesheet says. DIV hacks make Lynx-viewed pages vertically enourmous, tables are interprettatable in Lynx, because they are displayed as indented lists.

Finally, you shouldn't do anything to keep up with trends, by definition, a trend is in passing.

And even more finally, you can't move "on" to CSS. You can move "in" to CSS, but if you jump onto CSS and think you can leave HTML behind, you'll be more than a little marooned.

Personally, if I could design pages in Excel, I would. Excel has a predisposition for automation, and a concept of value transference across multiple dimensions through an infinate choice of functional gateways. Excel + CSS would kick a$.

[mrclean]

Personally, if I could design pages in Excel, I would. Excel has a predisposition for automation, and a concept of value transference across multiple dimensions through an infinate choice of functional gateways. Excel + CSS would kick a$.

Easy there Dennis Miller. No need to get all esoteric and completely literal (I think it goes without saying that you must have HTML) on everyone. This may be the first time ever that I was offered a chance to look at Excel on such a philosophical level. Thanks, but no thanks. Back to the point... Web technologies grow rapidily and will continue to be one step ahead of accessible browsing technologies. (Need we not forget that older screen readers could not parse tables correctly) This all comes down to what the designer prefers in the end. Tableless layout should be learned as another approach, because who knows if it will fade away or become the standard....

[MattEvans]

Well. I can't debate unless I'm permitted to be completely literal, and to take things said as completely literal. Anything else would be, or result in the necessity for an assumption, would it not?

----

Hey. Overall apologies; I'll even drop out of the debate mode. I absolutely agree it's down to designers to chose, and has always been.

I should warn, I'll probably always argue about this when it comes up. Perhaps it's because I've never heard a good reason to change my mind, and the same reasons always come up.

Personally, I minimize the use of tables wherever possible; but sometimes, CSS and minimal markup alone is just too darn unreliable across browsers/with variable content. If it doesn't work today, it isn't working.

As roryt said, he finds it quicker to get a result with CSS alone. For the most part, I find it quicker to get a result with tables. I understand CSS, I just find it unsuitable after multiple attempts, when trying to do things that to me seem simple, and easy, with tables; including the entire structure of a page. I visualize the entire page as a tabular data structure. And thus I conform to the W3Cs recommendation.

Perhaps that is the fault of browsers, perhaps that's a fault of gaps in the specification of CSS. Perhaps it's a fault in my use of CSS.

If I don't like a table, I get rid of it. But I don't aim to design with, or without tables. I just want to get my prototype/concept, onto the web, ASAP, and have it look the same everywhere.

And I suppose that's what all web designers want.

[mrclean]

Well said!

[roryt]

Personally, the only places i use tables are when I am displaying data that has to be set in rows, because then it just makes sense to do it that way. Otherwise my markup just gets so messy that it becomes unreadible and less productive.

[Vinoth]

because search engine likes it very much and you can make it compatible more with all browsers.

[stymiee]

because search engine likes it very much and you can make it compatible more with all browsers.

Untrue on both accounts.

Search engines couldn't care less if your site is tableless. They don't know the difference and it in no way indicates the relevance of a page. Going tablesless just means less code for them to sort through to find the content.

Only modern browsers support CSS enough that tableless designs can be used. Generation 4 and earlier browsers either can't handle them or handle them so poorly that they just don't work. Even generation 5 and 6 browsers have some issues with tableless design that requires a designer to know what they can and cannot do.

[roryt]

On the modern browser point: the large majority of people will have the latest version of their browser or at least on version back. But then again different browsers do display tables differently, the skill is to build the website so that it doesn't.

[MattEvans]

There's definately more output variety when it comes to some of the CSS placement/overflow rules in modern browsers than there is with table display rules, regardless of defined document type.

Tables are certainly more reliable when it comes to backwards display compatibility; there's not much that can go awry with a table: until you hit a text-only browser that is...

I disagree that everyone has the latest version of their browser... That's like assuming everyone uses Windows XP, and every WindowsXP user will be on Vista when it comes out publically.

I have a partition on this computer that boots Win98 with an IE version maybe before 5. MS have discontinued Windows 98 and ME support, so there's no neccessity for them to continue realeasing browsers that are compatible with Windows 2000 or lower. Luckiliy, I have more than one operating system on this computer; but not everyone has that luxury.

I haven't been on that partition since I installed the OS there, but it would be interesting to see how it renders newer standards of page..

It definately does pay to know, or at least be able to work out what you can and cannot do with or without tables, and it probably pays to define your target audience quite early in a project.

[roryt]

I disagree that everyone has the latest version of their browser... That's like assuming everyone uses Windows XP, and every WindowsXP user will be on Vista when it comes out publically.

All though there is alot of sense in what you have just said. I did have some logic in mine.

1. An operating system costs money, and alot of it, whereas browsers are mostly free and available quickly.
2. People who access the internet have an internet connection which means they will probably be notified by ms every 10 mins to download the latest updates, including browser updates.
3. People that have win 98 will most likely have ie6 if they are on the internet which remember is the only way they are going to view your site.

What i am trying to say is that browser compatibility should not be much of a worry when switching to css design, because most things can be fixed.

[MattEvans]

I'll agree, IE6 is about the lowest common denominator that IE user's are gonna be visiting from. But IE6 is in no way perfect.

I really want to get some standardisation for definitions; this is what I take to be the meaning for the following terms:

- CSS Only Design = Doesn't exist
- CSS Design = Any design that makes use of cascading style sheets
- Tableless Design = Not a decision you can afford to take until a project is finished
- Design with less tables = A design approach minimizing the use of tables except in situations where they are appropriate, or more viable than any other solution.

There's no such thing as switching to CSS design for me. It doesn't register as a valid switch of anything. If a solution with floating/positioned/hierachal DIV elements to arrange a layout isn't doing what I want it to do, (on every appropriate browser), I instantly transform it into a table if a table would be appropriate. I wouldn't then dettach my CSS stylesheets in shame and clean my mind by headbutting the physical table beneath my keyboard.

I know the points where a DIV + CSS solution is probably going to fail, and avoid using DIVs + CSS in those situations. In my case; I guess that puts me off using 'correct' methods as a first choice in some cases. But, I'm lucky in that I don't work much in HTML directly; I always generate my HTML using methods that are themselves modular and styleable; so if I change the overall template for my markup, it's either a batch job for the XSL processor or a rewrite to a real-time markup transformation template and a short wait for that change to filter through a system. I know that not all designers use these methods; and I certainly understand the usefullness of CSS however pages are generated.

But my biggest issue with CSS + DIVs over TABLEs (other than standardisation of display) is:

DIVs get really bad to use when you want a page to have an arbitrary number of justified block level elements fill the width of a screen or be relative to the width of a screen. In some situations, it's ideal for objects to jump underneath each other, or be allowed to hide behind boundaries. In other situations, it breaks the intention of a conceptually strict layout.

In these situations, using table elements to arrange a layout area produces smaller and more manageable markup compared to any other solutions I've seen, or can imagine, so tables are the first choice. IF CSS supported more specific relational bindings for positioning and sizing objects relative to objects that are 'sibling' or even 'distant' in terms of a document's element hierachy (in the same way as tables do automatically), a table wouldn't be the first choice. A CSS solution would.

If creating appropriate relational bindings depended on creating a div which acted like a table, containing divs which acted like trs, containing divs that acted like tds; it would still be the better solution, because it would indeed be more modular and mutateable than a standard table. There'd be no change to the manageability of markup, and, although that arrangement effectively binds those objects into an inheritance hierachy that best suits some kind of tabular arrangement, there could be a high level of potential re-arrangements within that structure (think cell-position swapping, or mobile merges between cells).

As it is, the potential properties in current CSS specifications can only create extremely vague positioning relationships based from a direct ancestoral hierachy. Often, implicit CSS positioning relationsips have to assume fixed or parent-relative sizes for blocks which is only ok if blocks never contain too much content, or if it's ok to hide content or scroll content. AS well as the 'standard' inheratance based property cascade; CSS allows absolute and relational flexibility with positions but in some situations thats more of a hinderance than a help,

In answer to the threads title question "Why do people wish for tableless with CSS?", it's for the same reason people wish for anything conceptually perfect. For the moment at least, CSS rules cannot do everything that table rules can (and vice versa). Wishing won't change that.

[MidiMagic]

Hello members

I've always wondered why, I found an answer in bandwidth economy, but other than that, how do they expect us to do it? With padding?
Any advice, comments?
thanks

The main push for elimination of tables is the use of tables to create predictable margins around the text. The padding attribute on the "body" tag in the stylesheet fixes this nicely.

But they really haven't come up with a "nice" way to create columns of text and photos without using tables. Every time I try to use the "div" tag to create columns, it tangles into a single vertical column if the browser is open in a small window.

[stymiee]

CSS 3 will offer columns.

[MidiMagic]

The fact that CSS3 will have it is another incompatibility between new browsers and old.

We need to remember the following when assuming that everyone can upgrade to the latest technology:

1. Many conmputer users don't have the money to upgrade operating systems every three years as Microsift demands.

2. Many computer users don't have the money to replace the computer every few years, to keep up with Microsoft enlarging the Windows operating system.

3. People in some foreign countries have to make do with older operating systems, because of one or more of the following:
- The US technology export embargo to some countries
- Their networks can't handle the latest material
- There is limited availability of hardware in that country
- Their government restricts what can be sent over the networks

4. Many people have legacy systems having nothing to do with the Internet that they have to keep running, often for scientific research purposes. The change to Windows has deprecated some types of time-dependent precision process control (Microsoft designed the system timing with business users in mind). This is why some users still have Lynx, Gopenr, or other text-only browsers. They need to be able to collect data with their legacy systems and transfer it over the net.

[MattEvans]

It's not so much incompatibility as unimplemented previously, or implemented to a lesser standard previously. It's not correct to expect older browsers to display things exactly as new browsers do; or even to work within the latest standards. For that; every browser would have to have been implemented with the ability to update and rewrite itself silently. A far better idea would be versioning...! wait a minute; that's what happens.

Development is certainly a good thing; unfortunately it's difficult to sit and wait for development to stop and be ready (i.e. everyone having it) because that's not really the nature of development.

Looking at a W3C page (first result in google for 'CSS3 date') shows it was scheduled to be conceptually complete by the end of 2000. Seven years later; 'modern' browsers are only just implementing the complete CSS2 spec. I'd say thats less an incompatiblity and more about what the impetus of new browser's development has been: I'd rather see well tested and correct CSS2 implementation than badly implemented CSS2 & 3. As it is, neither is really the case on any browser, but at least there are clear standards to aim for these days.

It would be bad, if using new standards made all pages inoperable under older standards. But that's very rarely the case. All HTML and CSS specs are quite backwards compatible (but certainly not pre-emptivly forwards compatible).

Anyone who releases information specifically for text only browsers makes an effort to release code compatible with those browsers. That's not impossible. People who use those browsers know what they're doing, and know the shortcomings of their browser. 'Hey, I'm going to go look for the nicest visual website designs; and I'm going to use Lynx'. You just wouldn't hear that.

[rasadesign]

It's not that tabled sites don't use CSS. The distinction is that layout and style tends to be shared between CSS and tables in a tabled design. Tableless design uses tables when appropriate, but Structure and Style (layout) is separated. Structure in the HTML, Style in the style sheet.

[rasadesign]

It's not that tabled sites don't use CSS. The distinction is that layout and style tends to be shared between CSS and tables in a tabled design. Tableless design uses tables when appropriate, but Structure and Style (layout) is separated. Structure in the HTML, Style in the style sheet.

Clarifying Further:

As an e-Commerce, designer, there's an SEO reason to use tableless design, but it seems to be little understood factor that isn't being picked up in the posts to this thread.

The ability to write semantically correct markup in the 'logical' contextual order that presents keyword strings within an readable hierarchy is what makes tableless design useful for e-Commerce. It's why we rewrote osCommerce into a tableless CSS osCommerce application for our clients.

The fact that we can put important content and navigation directly in line with TITLE, H1, H2 and P up at the top of the source code is what makes the page seem more relevant for that particular keyword string:

PAGE TITLE: Blue Widgets
H1: Blue Widgets
H2: Very Blue Widget description
P: "Our bluer than blue widgets are the best because they are made from..."

We can go further and create a DIV with an ID of header, then have that above information contained with "display:none" in the CSS with a background image consisting of the logo. Viola! Google sees keyword-rich text and readers see your $2,000 beautiful, graphical logo.

Right under that, another H2 followed by the main page content. Following that, the keyword-rich text links that lead to pages with matching TITLE tags. After that, all the rest of the less important content, 'about us' page links, etc.

That order in an e-commerce site pops the site up past tabled designs, all else (such as link popularity) being equal.

Why? Because, to Google and other readers, the hierarchy is clear. In a tabled design, the logical order of the content and its importance is not always so clear and rarely linear.

But, before we can let the whole debate between tables verses tableless, here's a couple of reality checks:

http://joeclark.org/book/sashay/serialization/Chapter10.html
http://css-discuss.incutio.com/?page=TablesVsDivs

[php_noob]

Sites that present dynamic lists of anything (forums are a good example) will almost always use a table to present something, somewhere. Tables line up their rows and columns, tables are easily visually interpretable, tables can easily be populated from a database. Using a combination of HTML DIVs and SPANs and CSS to emulate a tabular layout for the data is always going to be "150% hacky. "

Question1: What do you mean by 150%hacky?
Question2: Dynamic based websites always use tables is that what you say in here? I'm a table user ever since I use DIV recently and still figuring out the ways how can I implement make my layout-designs look good in every browser!

My friends discourage me in using tables

[MidiMagic]

I have some more insight now:

Using div tags for columns works fine if the divs are on the top level (i.e. inside only the body tag). But just try to make a set of columns with div tags inside some other structure, and you get a grade-A mess.

So I came up with a simple set of rules to use to decide whether to use a table to create layout, or to use divs and styles:

- Use styles to create the page margins that were formerly created by tables.

- Use tables to present tabular data.

- If the columns are supposed to be inside any tag other than body or div, use table. The div method won't render correctly inside many other tags (especially the li tag).

- If you have to cruft up a kludge to make your layout work with one method, use the other method.

- Decide what should happen if the browser window is too narrow for your content to fit. If you can tolerate any of the following, use div tags. If not, use tables:

-- The column format falls apart into a single vertical column.

-- Items end up in the next row when they don't fit.

-- Images cover each other, or cover text.

-- Text renders on top of images.