Hi all,

For quite some time, discussions are going on about "tableless design". Personally, I find the replacments with endless successions of utterly appalling, ugly, hard to manage and unwanted, but maybe that's just me. And I agree, a table structure with nested colspans and rowspans is equally hard to manage, but at least I am used to it :-)

I was wondering: is all this talk about tableless design based on solid technical grounds? Is a page constructed with and around tables bound to become hopelessly old-fashioned, or are we actually just talking about two alternatives to layout a page? Is tableless design becoming a "must", or is it just "fashionable"? What are good solid reasons to not use tables anymore (if any) ? And what about mixing both types of design?

I'm not looking for a discussion of believers and non-believers. I am looking for real, solid reasons why I should (not) use tableless design.

Ludo

Comments

Hmm, that should have been: "endless successions of divdivdivdiv /div/div/div/div", but I had put the "smaller than" and "greater than" brackets, so they were interpreted :-)

Ludo

It's not becoming a must, it's been a must for a while.

The main reasons are:
- maintainability. It *is* possible to go overboard with divs and wrap EVERYTHING -- but if you're sensible, you won't have tons of div/div/div/div. Besides, some will be li/p/h1/whatever, and they're clearer to read in source.
- flexibility. you can change a CSS-based layout in many more ways than a table-based one
- accessibility. at least where I live, making websites accessible is a legal requirement.
- size. table-free designs tend to be smaller files. Also, a smaller file is easier to read and maintain.

Mmmmh, dunno...
* Maintainability: as long as there are no tons of div/div/div things, yes, possibly. But sensibly arranged tables are equally maintainable. I mean: this is a matter of taste, and of knowing your code, no? I for one feel it's a HUGE hassle to dig through css files, to find out that some background color or some font size has been defined "miles away" and has undergone a load of cascades to finally be rendered somewhere. Or that some "display: none" at the other end of my file makes some line disappear. CSS's are powerful, I agree, but they are not exactly my ideal of readability and maintainability - au contraire! Before I knew Firebug, CSS's usually gave me daily heart attacks :-). But as I said, I suppose this is a matter of taste and of being used to your code.
* Flexibility: agreed, CSS structures are very flexible, much more than tables. But the thing is: I have to work in pre-defined, mandatory structures, mostly based on tables. I have to put X on top and Y to the left, end of story. To me, flexibility of structure is actually of lesser importance. I suppose this is different when you can design a site from scratch.
* Accessibility: umm, what do you mean by that? Making your site more accessible to visually impaired people? That's what I've been doing for years in my table-based designs, with a minor amount of Javascript... I admit that I have been told that tables are not so easy for having the site Read by voice synthesizers. That's possible, I don't know.
* Size: I don't think that's very relevant, or at least becoming less relevant, with today's broadband connections. Anyway, I fail to see the importance of file size in your code, when people don't hesitate to put 10 dumb rotating banners of 200 K each on top of their pages, nauseating Flash "Intro screens" or when they make a list with jpg bullets, 25 bytes worth of information, and 20.000 bytes worth of "fancy pictures". When a site is slow to load, in most cases it's not the programming code or the size of it which is the cause, but the flood of pointless graphics or, more horribly even, videos.

I know, I know... These are probably objections which can easily be countered. I merely wanted to state that tableless design is not the evident Walhalla of ease. Sometimes, I have the feeling of that little boy in the fairy tale of "The Emperor's New Clothes", that tableless design has become kind of Ordered By The Supreme Board. Oh well... I'm probably wandering in the desert. Now flame me :-)

Ludo

minor amount of Javascript

What if the user has JavaScript turned off? What if your user is not visually impaired, but deaf? What if your users are using cell phones?

Accessibility is not only for visually impaired people, but to screen readers and phones.

OK, for the sake of argument (I love to say things for the sake of argument, and as my wife knows, Sundays make me argumentative :-) ):
* have you ever actually met a person who had Javascript turned off?? I know, it can happen, probably in 0.01 % of the cases. Too bad. There's probably also a person who has his computer turned off. I won't be able to please him either.
* "What if your user is not visually impaired but deaf"??? Umm... Yes, as far as I know, that person should then be able to "visually read" my site, no?? I don't think many site designers provide special facilities for deaf people...
* With regard to cell phones, you may have a point. Although, come to think of it... I dunno. I'm running a site with a couple of thousand articles. I really wonder how many visitors have actually attempted to read an article on a cell phone display - and have made it a habit. I mean: the odd person who uses his cell phone to use the internet, will moooost likely just use it to check his mail when he's in the middle of the desert, or to check some tabular data like stock information or something, not to read articles. In any case, he has a phone budget about 50 times larger than mine. I may be wrong here, but I refuse to spend a couple of months redesigning my site for some technical show-off who insists on reading my articles on a display the size of a matchbox.

Which reminds me: a couple of weeks ago there was this huge business exhibition on New Telecommunication Things... You know what was one of the main innovative contraptions? A cell phone with which you could actually only make phone calls!!! New!! Revolutionary!! No sms, no radio, no camera, no waffle iron. I must remember to get one like that! A phone, just to make phone calls, imagine the possibilities!... They used to have pens which were also radios, they used to have shoes which were also an aquarium, they used to have cars which were also boats. They're all in the Museum of Forgotten Lunacies now.

Ready to receive your flames :-)

Ludo

I have JavaScript turned off! I started it back when Gmail was having the security problems, and I enjoy so much the things that are turned off that I may not go back. I can turn it on site by site, so if your site is interesting, and I am in a fairly good mood at the time, I may turn it on for you. Or, I may go somewheres else. :)

Hear hear. I browse with Javascript turned off by default as well. I turn it on only for sites I trust (including drupal sites that I build).

I also browse without Flash. If a site depends on Flash, it obviously targets a demographic that doesn't include me. (I'm especially amused by the Flash-only splash pages which, if they have a "skip intro" link, embed it in the Flash itself.)

I sometimes browser with lynx (a text-only browser), and while I agree that not many people do that, it's still good to know when your website renders perfectly in that form (as Drupal in fact does, or at least with all themes I've used so far). And the cell-phones were already mentioned.

Also, sometimes I really need to print out a page. Stylable divs that allow a print.css which formats the page in printable formats make that a lot easier.

Lastly, apart from making your site popular for accessibility, this technique can actually affect your search engine ranking positively - it's all about how well a robot can parse your site, after all, and paragraphs and divs make the document structure far more coherent than a table.

1) Some search engines have trouble penetrating a table, especially complex ones. Tables also tend to move the content away from the of "top" of the page. Both are bad for ranking.

2) A carelessly misplaced table tag (any of them) in content can mess up your whole site. Been there, done that.

Nancy W.
now running 5 sites on Drupal so far
Drupal Cookbook (for New Drupallers)
Adding Hidden Design or How To notes in Your Database

I have no real experience with the fact that search engines have trouble with tables. Possibly, when it's too complex, I don't know. Anyway, my tables are not "too complex", and I have no firsthand experience with Google disliking my sites. I thought the main criterion was still: how many sites link back to yours?
And a carelessly misplaced table tag can indeed mess up your site - as can a carelessly misplaced div tag...

Ludo

While the debate is neverending, using table-less layouts and css is about the semantics. People have turned HTML around and started doing things with it that it wasn't meant to do. Formatting should not be done in an html file, as it was created to simply DISPLAY content only. sure it can be done, but as long as producers of browsers continually let this invalid markup continue, the longer we go without standards.

also, another big reason is extensibablity. you simply add formatting into 1 file and it cascades through your entire site. this creates smaller .htm(l) files, which use less bandwidth and make re-designs a breeze.

And last but not least, in it's simplest form, a table was made to display data in a tabular format to provide relational data with an easy to read format. not to be used as a container for an entire website.

--------------------------
I'm a Drubie (Drupal N00bie)

I'm not saying CSS should be discarded. I know it is a splendid thing to change "red" into "blue" all over your site with just one line to be changed. I applaud CSS there. I'm just saying that CSS should most probably not be used to do everything, similar to what you say about tables and about html. I have the feeling the "Tableless Crowd" is pushing me to do Everything tableless, and that is what I don't like.

You are right in saying that htMl is about formatting, or Markup as the acronym says. Well, in the same line, cSs is about Style, as the acronym again says, not about STRUCTURE. I am Happy CSS is there for styling things, to make all blue titles red, but I feel it is a pain in the butt to use it as structuring principle, even less so as a means to add semantic structure to my information.

Ludo

I'm in the agnostic category about tableless design. Here's why:

  1. Tableless designs are replete with browser bugs which require a confusing array of hacks. Each hack has its own strange syntax, requiring the user to understand "non-standard" css.
  2. For anyone using a wysiwyg designer, none of them, in my experience render tableless designs properly.
  3. As soon as one "easily" changes the layout of tableless designs, old browser bugs can rear their heads, requiring another round of browser testing. While there are html and css mavens out there who can code tableless designs properly and easily in a text browser, the design is still inaccessible for the vast majority of less experienced web designers.
  4. The original advantage of tableless designs, ie. separating page design from content, does not apply to Drupal. Drupal's page template already separates design from content, so the advantages of tableless design are diminished in a CMS system.
  5. The "semantic web" advantage is still far in the future. Usefulness of the semantic web requires a critical mass of adoption, and we're nowhere near that now.
  6. The simple tables utilized by templates such as bluemarine add very little html to a page. The content elements of the page still rely on div placement, so this hybrid design works well.
  7. Many of the advantages of tableless design are theory more that fact at this time. Maybe in the future... Meanwhile, tables just work, and they work well in every browser. Since page layout in Drupal is isolated in templates, it's effortless to change to tableless themes later, when their advantages become overwhelming. When someone writes a killer tableless template that is easily changed, bombproof in all browsers, and looks great for commercial sites, then I'll "get religion." Meanwhile, stick to tables, IMHO.

Let the gnashing of teeth begin...... :-)

Hear hear, brother!

I thought I was alone with my opinions about tableless design. It's good to know there is someone else around :-)

Ludo

The tableless "non-believers" are hesitant to speak up, lest they be labeled heretics. :-)

I subscribe to several SEO publications, and they all say that tableless is the way to go. I currently have some 14 sites under my control or personally designed. Some use tableless themes and some use tabled themes. From an administrative standpoint, I don't care which I use. From am SEO standpoint, I would rather go tableless, but only with a theme that moves the content to the top, which few do (the only one I know that advertises this is Aberdeen).

From a user standpoint, I would rather see a layout based on frames, but that's an even bigger no-no to the search engines. Having a navigation menu that does not scroll is a better usability feature, IMHO. Unfortunately, your site will never rank well, if at all, with frames.

But certainly the argument that one may easily change the look of one's site with Drupal is valid, as is the browser bugs issue. Maybe, someday, someone will come out with a browser that is "right," fast, and installed easily (and by computer vendors) and the search engines will get smart enough that content will be found and properly weighted wherever it is rendered. Oh, yeah, and the Easter Bunny and Santa Claus will visit my house once again.

Nancy W.
now running 5 sites on Drupal so far
Drupal Cookbook (for New Drupallers)
Adding Hidden Design or How To notes in Your Database

Having a navigation menu that does not scroll is a better usability feature, IMHO.

Isn't this possible with position:fixed ?

FWIW, I try to go with the table-less layouts when possible. Mostly I'm just following the trend, and I agree with those who believe the semantic meaning of the table tag is "this is tabular data".

However sometimes I regress to tables when I just can't figure out another way. For example I recently ported this album theme to drupal. Tables are used to make a grid to lay out the thumbnails, and again to place border elements around each thumbnail. Maybe it would have been possible to rewrite it with divs... but why fight it? The page is still valid XHTML Strict.

Content positioning was the big buzzword in SEO a couple of years back, but the latest buzz is that content positioning is not so important anymore, with Google emphasizing other areas.

With simple tabled themes like bluemarine, the amount of code dedicated to tables is far less than the div markup found in many tableless themes.

I'm beginning to think that the hybrid designs are the best compromise.

Right now, for me, the easiest thing for me is to have one big three (or two) column table and do everything else with CSS. I also don't try to do every last thing the easiest way, because I want to be somewhat ready when tables are not needed anymore. They are so much less important than they were just a short time ago.

A blind friend sent me a link to a site he considered accessable. It was full of tables. I would be surprised if Google really cares one way or the other.

I am pretty set against frames because the individual pages can't be bookmarked. And I am always way out front in any "Death to font tag" rally.

I speak as someone who poked his head briefly into the "tableless" world and was faced with 5k of stylesheet hacks to get the damn thing working in all browsers on all OS's...that I actually took the step back and now do sites like this:

<table>
<tr id="left-col">
  <td id="menu">
  </td>
  <td id="ad-box">
  </td>
</tr>
</table>

what some people call a hybrid system. I know I won't have to open up a rarely-used browser and see my top nav bar sitting just below my footer. (which has happened on solely CSS-based sites)

As for file size, the hybrid system actually comes out smaller because, as I said, you don't have to fill your style sheets with line after line of hacks to make it work.

My fear is that the browser world isn't quite ready for tableless, just as it isn't/wasn't ready for xhtml. In 2-3 years, I'll have another look at it. I think when we're at IE8 and FF3, it might be worthwhile.

The original advantage of tableless designs, ie. separating page design from content, does not apply to Drupal. Drupal's page template already separates design from content, so the advantages of tableless design are diminished in a CMS system.

I'm not sure about that - a table is content, so it's use as a layout/presentation device rather than to present information in a table immediately goes against this.

The comment "Formatting should not be done in an html file" is one that I think most people would agree with, and a good idea, but how many times do we still see un-classed <strong> tag or a <em> tags used? It is a goal, but there are certainly exceptions.

And when talking about SEO, <h1> - <h6> tags become an issue, how often do we see them used simply for formatting purposes. How many drupal templates use <h2> for both block titles and node-teaser titles, to do so suggests that block titles have the same level of importance as node titles; surely "Login" and "Search" aren't that important to my SEO? Those are easy enough to change in the the template files, but my point here is that it was some arbitrary decision someone had to make.

Formatting is one thing, but Layout is another thing altogether.

To have a 3-column layout with header and footer you could use:

Table: CSS File

body {
  min-width: 550px;
}
#container {
  width: 100%;
}
#left {
  width: 200px;
}
#right {
  width: 150px;
}

Table: HTML File
(note the placement of Left-Center-Right columns)

<table id="container">
  <tr colspan="3">
    <td id="header">HEADER CONTENT</td>
  </tr>
  <tr valign="top">
    <td id="left" class="column">LEFT CONTENT</td>
    <td id="center" class="column">CENTER CONTENT</td>
    <td id="right" class="column">RIGHT CONTENT</td>
  </tr>
  <tr colspan="3">
    <td id="footer">FOOTER CONTENT</td>
  </tr>
</table>

Table-Less: CSS File - example from A List Apart - Holy Grail

body {
  min-width: 550px;      /* 2x LC width + RC width */
}
#container {
  padding-left: 200px;   /* LC width */
  padding-right: 150px;  /* RC width */
}
#container .column {
  position: relative;
  float: left;
}
#center {
  width: 100%;
}
#left {
  width: 200px;          /* LC width */
  right: 200px;          /* LC width */
  margin-left: -100%;
}
#right {
  width: 150px;          /* RC width */
  margin-right: -150px;  /* RC width */
}
#footer {
  clear: both;
}
/*** IE6 Fix ***/
* html #left {
  left: 150px;           /* RC width */
}

Table-Less: HTML File - example from A List Apart - Holy Grail
(note the placement of Left-Center-Right columns)

<div id="header">HEADER CONTENT</div>
<div id="container">
  <div id="center" class="column">CENTER CONTENT</div>
  <div id="left" class="column">LEFT CONTENT</div>
  <div id="right" class="column">RIGHT CONTENT</div>
</div>
<div id="footer">FOOTER CONTENT</div>

None of the above instructions will do anything in terms of "formatting" but provide the "layout"

  • Size: the "table-less" version is a smaller .htm file, but not substantially but the reverse is true for the CSS file. I would be surprised if the time difference to render the two would be noticable.
  • Easier: how easy would it be to change the layout from Left-Center-Right to Left-Right-Center, the "table" is much easier but requires a change to the html. You could get the change I suggest by purely changing the CSS file with the "table-less" option, but I wouldn't want to try it.
  • SEO: the "table-less" version is better - assuming your CENTER CONTENT is the main page content, it puts that content closer to the top of the file. But, as noted, this is less important today than it was years ago.

One issue not brought up substantially is browser support. If I could control which browser (and version) my users used, I would be a happier designer - but not a good human-being. CSS is still pretty new, constantly advancing, browser support for certain things is shotty at best.

There is this meme with CSS that all one has to do is change the CSS file and you can change the whole look and feel, simply and easily. CSS Zen Garden certainly proves that point. But if it were truly true, then there would be no reason for more than one set of drupal template files, visually everything in theory could then happen in a CSS file. But it can't (not yet anyway). Unfortunately too, I would have to write a lot of theme function over-rides to get full control of all the html that is output by drupal modules - and how many CSS files are floating around in drupal? Sometimes it makes me crazy.

When I design a new site, my goal is to always try for "table-less" first, but every once in a while, it is just easier to insert one simple table for my primary wire-frame. And frankly, done is good. In time, I have no doubt that "table-less" will be the only way it's done, but we are just not there yet.

You really nailed it with the examples. I've always been amused by the Zen Garden worship. Yea, so you can completely change the look of your website with a new css file, assuming you've mastered the "Zen" of changing all those placement, padding, and margin styles, and can think like a zen master. :-)

Just how often does one need to completely change the look of an existing website? Guess what? I can do that in Drupal with a 5 second template change, whether the new template is a table based or tableless.

Right now, Drupal's theming is just scattered over so many areas, that table vs. tableless is a moot issue. Too many other things matter more to speed and efficiency. And because table formats save me the headaches of browser compatibility, it just seems the easier and more productive alternative.

What I think Drupal REALLY needs a is new theming paradigm, with a new theming engine, that simplifies and merges theming into one set of master files to make this whole theming process easier.

You point about decreasing html while increasing css is true and you bring up a valid point. Yes, it will take less time to load the html and more time to load the CSS. But, this in only on the first page load. On the first load, CSS is cached. Subsequent page loads are HTML only.

Browsers are at a point now where you no longer have to do a lot of hacking to make table-less pages render roughly the same. Market share is such for CSS2 compliant browsers that there is really no longer any business case for supporting NS 4.7 nor pre-v6 editions of IE.

That said there is a lot of flat out bs being espoused by the table-less evangelists. Using, say, one table as a container to make your layout nice and stable, is certainly not going to violate any but the strictest accessibility standards. It might also be less inclined to break when poorly sighted users magnify text. A lot of accessibility amateurs think about screen readers and little else.

Also, ludootje is right on the money in complaining about divs wrapped in divs wrapped in divs -- it's neither semantic nor particularly maintainable. These layouts may be free of inline styling, border attributes and font tags, but they are still formatting via the markup. If your markup can't be completely re-skinned with the css, in any way you want it, then your markup is doing some of the formatting. However, this issue (as well as in-line styling) becomes less pressing when you're using a cms, where reskinning is simply a matter of changing a handful of templates. Even so, folks really should be putting the styling in separate stylesheets. It's not hard and the gains are great in terms of maintainability and user bandwidth.

As for search engines, again, conservative use of tables won't cause any problems. Search engines won't like it certainly if things that semantically belong in an H1 tag are instead placed in a th tag, but they would probably like a <div><strong>Heading</strong></div> even less. The problem is endlessly nesting tables in tables and doing padding and other kinds of formatting with spacer gifs. There really is no reason for this and any developer who is still doing it at this point should really update in a hurry. I would never hire anyone who still uses spacer gifs and nested tables. It's like announcing "I have read and learned nothing about my field for the past 5 years."

As in all debates, it's best to be empirical rather than religious. That is, understand why the rules are what they are and when it makes sense to apply them. This goes for folks on both sides of the debate.

When designing with tables, you can't really change how the page is displayed on a mobile phone, or a printer. It's easier to hide a div than it is to hide a table column.

Creating style sheets for each device I anticipate will go to any site I built makes it easier to manage how the site is displayed. These luxuries were invisible to me when I designed websites using tables.

I once worked at a web dev company that did their sites in tables, and they had their menu's organized in table cells. Don't get me started on the amount of headaches we had with those menus.

Can someone show me a csszengarden where the designs table based? Because I'd love to see it. Changing a website design that is based on tables takes a very very long time (due to nesting). When people see nested divs on a design, it is easily fixed by using absolute positioning (that div becomes a child of the body node).

Has anyone read a web design book where they teach you to build a web page with tables? I haven't seen one like that since the late 90's. Everything now is web standards, advanced web standards solutions, CSS2, CSS3, unobtrusive javascript, jquery, etc., etc..

There are so many positives to designing a tableless website, but in the end, it's the designers choice. Table based designs are easy, but down the road when you want to do something more, or change the design, it will be difficult. But as Chris Rock would say "You can drive a car with your feet if you want to, but that doesn't make it a good idea."

======
Jason

======
Jason

Can someone show me a csszengarden where the designs table based? Because I'd love to see it. Changing a website design that is based on tables takes a very very long time (due to nesting). When people see nested divs on a design, it is easily fixed by using absolute positioning (that div becomes a child of the body node).

You're using some of the arguments against tables that caused the tableless movement in the first place, but you're ignoring the way Drupal uses tables for layouts. I don't see any nesting or use of cells for menus in table based Drupal themes.

Changing a website design in a tabled Drupal template is as easy as changing the template. Drupal table based templates use the table cells more as "regions" rather than stylistic elements.

And a "template" in Drupal is essentially the same thing as a style sheet in a static website. You change it out to alter all the content on your site.

You're using some of the arguments against tables that caused the tableless movement in the first place, but you're ignoring the way Drupal uses tables for layouts. I don't see any nesting or use of cells for menus in table based Drupal themes.

Drupal itself does not use tables for layout. It is the designer/creator of the theme that decided to use tables. If anything, Drupal is praised by many people in web dev industry for its lack of tables in the output.

http://www-128.ibm.com/developerworks/ibm/library/i-osource1/ -

The ease of adjusting the way the content was displayed was crucial; we needed to remain flexible during iterations of the design and any future adjustments. This so-called "themability" also was required for using the current best practices of Web design with respect to semantic xHTML, CSS, and accessible design.

Tables in Drupal are used for tablular data (views, logs, etc.), which is what tables are meant for. That is the only time core Drupal will output tables, never for a layout. You might argue that there are a handful of themes that come with Drupal that have a table based layout, but those are just for starters to get their head around use of the phptemplate variables.

That said, you can use the same theme code base (page.tpl.php, node.tpl.php, etc.) for different themes. Each theme would need to be a subdirectory of that theme directory (example, marvin and chameleon themes). In those directories, you can specify a style.css file that defines the style of that theme. Now if the code base for the themes are tables based, it would be difficult to move elements around if they are locked into tables. When creating a theme, it's easier to change the style sheet than to make copies of the code base and modify that code base every time to want to change the layout.

If you're not a designer, and you have people making your designs and themes for you, than I'm sure you don't care.

======
Jason

======
Jason

Drupal itself does not use tables for layout. It is the designer/creator of the theme that decided to use tables. If anything, Drupal is praised by many people in web dev industry for its lack of tables in the output.

What do you call Bluemarine? It's the most used and modified theme out there and it's included in core. That seems to qualify as a Drupal element to me.

Now if the code base for the themes are tables based, it would be difficult to move elements around if they are locked into tables. When creating a theme, it's easier to change the style sheet than to make copies of the code base and modify that code base every time to want to change the layout.

Double huh??? Do you actually do theming with Drupal? "moving elements around" in a Drupal template consists of loading the code into an editor and changing it, exactly the same thing you do to alter css. Then the changed code is copied up to your live site. There is NO difference between altering tpl.php code and css from a practical standpoint, and since the Drupal page.tpl.php file is like Drupal's version of a stylesheet, the changes to this one file alter the content of your entire site, just like a stylesheet does.

What do I call Bluemarine? One of Drupal's ugliest themes! They were looking for a replacement for Bluemarine for a long time before they came out with garland/minnelli for Drupal 5. The reason why "it's the most used and modified theme out there and it's included in core" is because the code base is easy to read and highly modifiable, and is why it continues to be released with core. Majority of the instructions on "How to create a Drupal theme" indicate that you should copy the Bluemarine theme and work from there. Since majority of web designers aren't web standards freaks like Zeldmann, then they really wouldn't care if the site is standards or not. You're obviously one of them.

Do you actually do theming with Drupal?

http://drupal.org/project/nautica09

And I have 2 more designs coming. It is based on the Bluemarine theme, but I ripped out all of the tables.

When it comes to theming Drupal, I can see why you are getting so upset with me on this issue. I have a very formal approach to developing themes. The less html I have to play with, the better. I prefer to just have 1 file (style.css) open for me to work in. My xhtml is documented (both on screen and on my whiteboard at home), so I can find elements and style them accordingly.

You're saying that the you don't mind having the 3 files open to work in because it's easier, and that tableless designs would be overkill when you only need to modify those 3 files. And I would agree with you.

This thread has more than enough reasons why tableless designs are better than table based, but keeping your site in tables is perfectly fine. Like I said before, it's the preference of the designer to use tables or not.

I didn't come here looking for an argument. I just wanted to add in my 2 cents based on my experiences with CMS and Non-CMS based websites.

======
Jason

======
Jason

amen +2

Sometimes something interesting appears on http://litwol.com

it's included in core" is because the code base is easy to read and highly modifiable, and is why it continues to be released with core.

I'm certainly not getting upset with you. You are certainly entitled to use whatever method works best for you. It's just that you mentioned a few points that I found to be inaccurate, and I wanted to correct them. There is no issue with anything being "frozen" in a table format. Tables are just as easy to change as tableless designs, IN DRUPAL.

And in fact, after the initial design of a table-based template, one seldom has to touch the html. Most design changes occur in css, WITHOUT the constant tweaks necessary to make tableless designs render properly in all browsers. That's the point.

As as for Bluemarine being ugly, that has NOTHING to do with tables, and has EVERYTHING to do with the skills of the designers making Drupal themes. Garland is a very impressive, but very impractical template for general use, and part of the reason it's impractical is the difficulty in changing the design based on its css. And it's tableless. Go figure.

When designing with tables, you can't really change how the page is displayed on a mobile phone, or a printer. It's easier to hide a div than it is to hide a table column.

I am an advocate of tablelessness but I am also an advocate of saying true things and this just isn't. If you are using one three-celled table to deliver a columnar layout in the same way your are using three divs to the same end, display:none will act the same way. I have done print stylesheets on simple table layouts this way to remove navigation and peripheral content. You can make a stronger argument for divs if the future requirement is to put something contained by a table cell in a different place depending the device. In those cases, divs definitely rule.

Creating style sheets for each device I anticipate will go to any site I built makes it easier to manage how the site is displayed. These luxuries were invisible to me when I designed websites using tables.

There are two separate issues here which you are conflating. The question isn't tables vs. css. Tables are exposed to css and can be made to render quite differently for different devices. You can, for instance, linearize a table for a handheld by setting display:block on all your table, tr, th and td elements. You do not need to go tableless to produce device agnostic documents. It helps, but it's not required.

Can someone show me a csszengarden where the designs table based?

Of course not. All the designs are done using the same tableless markup. That's the point. At the same time, if you look at most of the designs there's not a whole lot of magic going on with positioning. The structural formatting in most cases is pretty run-of-the-mill. The heavy lifting is being done by the graphics used as the backgrounds.

Because I'd love to see it. Changing a website design that is based on tables takes a very very long time (due to nesting). When people see nested divs on a design, it is easily fixed by using absolute positioning (that div becomes a child of the body node).

Not if you're using a cms and you have only a few templates. The hardest part of a redesign is the css which you have to do with or without tables.

You do your thing, brooklyn brotha.

In my 5 years of table based designs, I've never had the the same amount of flexibility that I can have with standards based designs.

If you can accomplish the same effect with tables as the standards evangelists do with divs, then you are one talented individual. I couldn't do it so I crossed over.

======
Jason

======
Jason

I do tableless markup and advocate it.

I was simply pointing out areas where your post was misleading.

pobody's nerfect.

======
Jason

Coming from a background of knowing/using multiple programming languages i can say this: Every technology has its own uses, and decision to use that technology should come on per-need basis.

there as so many questions to consider when choosing a particular technology, and when you answer the questions that are appropriate to YOUR project then it should help you choose whether to use css or tables or perhaps a mix of the two to some extent.

canseling any one technology just on principal is plain stupid IMHO. there are things that tables accomplish easier/faster than CSS and there are other things that CSS accomplish faster/better than tables.

Sometimes something interesting appears on http://litwol.com

This is why perhaps the best template approach in Drupal right now is a hybrid template design: Use table cells for the main columnar layouts, to isolation menu and banner regions, and to make liquid designs simpler. Then use divs and floats for the page elements where you can control some of the Browser bugs more easily.

A good example of the css browser compatibility problem would be the vote up/down module. They still haven't figured out how to make their digg style widget display properly between IE6, IE7, and Firefox. Imagine having to handle those compatibility issues across the entire page. I just don't have the resources to test my web designs across 10-12 different browsers every time I make a change.

It will be some time before all the old browsers disappear.

for a large page, is that the content starts displaying as it is loaded by the browser, as opposed to tables, which only appear when the whole table has been loaded.

For whatever reason, Drupal doesn't begin displaying a page until all queries are executed, so you won't find any visual rendering differences between tabled and tableless themes.

Regardless of how the page is created, the browser still has to load the html from the server. Tables appear on the screen all in one go - no part of the table will appear until the entire table is downloaded and rendered by the browser. For a large chunk of content there can be a very dramatic difference in rendering speed between using a table, or some other container.

If you can't remember seeing this, you have grown used to the luxury of broadband. :)

And let me share with you about some ironic fact here.

I hate labels but I guess some people could label me a "web developer" (whoo hooo), and I am poor enough to still use a modem at home with a dialup connection. So what you're talking about Patrick I am experiencing.

And despite that I want to be original, I doubt that I am a rare oddity. I am sure that there are other people out there STILL using a dialup connection.

And there are areas in the world where you cannot have broadband even if you could afford it.

Caroline
A coder's guide to file download in Drupal
Who am I | Where are we
11 heavens

Caroline
11 heavens.com

I've only been on broadband a few months myself, so it still feels like a glorious novelty. Hey - good luck with your Drupal theming e-book!

If you're looking at a website without the css, though, a table-based site is a disaster. Same goes for looking at it with a handheld. Or visually impaired.

The #1 advantage to table-less design is that you can build your page with meaning, and not according to layout. Ideally, your page will be laid out this way:

[branding]
[primary navigation]
[main content]
[supplemental content]
[site info]

A table-based layout precludes this in most instances.

The thing is about all this is that the arguments presented here are from the perspective of dogma, of "religion." If you don't care about accessibility and building semantic websites, then good reasons won't sway you. If the counter-argument is that CSS-only pages break in Internet Explorer, then I say it's worthwhile to learn some IE hacks (and it's okay to curse Microsoft in the process).

I do however recommend most highly Andy Clarke's "Transcending CSS. This wonderful book discusses the why's of building websites (which entails, incidentally, doing so without tables), and he does it without browbeating or stone tablets. It just makes sense, when you stop and consider all the angles on the websites you're building, and he explains it much better than I can.

As for the what-wysiwyg-editors-can-do argument, I'm sorry, it makes me giggle.

But really, check out Andy Clarke's book. It's in most of the chain bookstores and well worth the money. (It has some good thoughts on general design, as well as some nice CSS tricks, too.)

Laura
_____ ____ ___ __ _ _
design, snap, blog

_____ ____ ___ __ _ _
Laura Scott :: design » blog » tweet

but his ideas are really for the future. Who can get interested in his chapter on css3, when css 2.1 hasn't yet been implemented properly by the main browsers?

Hi

I posted a poll in http://groups.drupal.org/node/3462

Which is the better technique to Drupal design?

If you're looking at a website without the css, though, a table-based site is a disaster. Same goes for looking at it with a handheld. Or visually impaired.

How often in the real world, is one able to display a site's content, and not see the css? Why is this capability important?

I do agree that if your site is serving up data to handhelds regularly, then the advantages of css tip the balance, but I'd venture that 90% of the web developers out there do NOT render to handhelds. There's no doubt that if you feel comfortable with tableless css, know all the hacks, have semantically important content, then css is the way to go.

But for the vast majority of web developers who just want to customize a Drupal theme and have their website "just work" in a short development cycle, then I think it's a disservice to suggest they move to tableless designs immediately.

The #1 advantage to table-less design is that you can build your page with meaning, and not according to layout.

Again, this is theory, not practicality. To a viewer TODAY of a person's website, semantic meaning has zero value. Sometime in the future that will change. But in the meantime, Drupal developers need solutions that work today without tons of tweaking. Thanks to the ease of switching themes in Drupal, there's plenty of time before we need to worry about "Web 3.0"

Programmer's note: Having watched the three-decade-old birth, gestation, and comatose status of the artificial intelligence community, I have SERIOUS doubts that the semantic web will have any real impact anytime in the near future.

[branding]
[primary navigation]
[main content]
[supplemental content]
[site info]

That's actually wrong. Standards evangelists advocate this --

[branding]
[main content]
[primary navigation]
supplemental content]
[site info]

--since most folks going to a page are after the content, not the navigation. A screen reader will read all of those links before getting to the content. That's why if your content isn't at the top of the markup you should put a skip to content link at the top of your markup.

BTW -- The order you proposed as a standard is exactly what the following table will produce without css:

<table>
  <tr><td colspan="3><h1>My Site</h1><td></tr>
  <tr><td id="nav"><ul></ul><td><td id="content">content</td><td id='"supplemental">Supplemental</td></tr>
</table>

In a hand-held, setting the display attribute to block on all the table children will produce the same sequence.

Actually it was just a typo. You are indeed correct, which is another reason to put away the tables and save them for tabular content. Thanks for catching that.

Laura
_____ ____ ___ __ _ _
design, snap, blog

_____ ____ ___ __ _ _
Laura Scott :: design » blog » tweet

I do however recommend most highly Andy Clarke's "Transcending CSS. This wonderful book discusses the why's of building websites (which entails, incidentally, doing so without tables), and he does it without browbeating or stone tablets. It just makes sense, when you stop and consider all the angles on the websites you're building, and he explains it much better than I can.

I wish I could get a refund for that book but it's too late. That book is inflated like pop corn. No... like a balloon.
The actual substance of that book can be reduced to a 20-pages pamphlet.

To be fair, a few sidebars are somewhat instructive.

If you know CSS, and know why to use a tabless design and why you should use semantic markup, then stay away from Transcending CSS or get it for free (from a public library of course!). That book is a joke.

I don't mean to offend you laura AT ALL with this comment.

Andy Clarke is a reallllly cute guy though. Totally kissable, but his book is imo not to spend money on.

Caroline
A coder's guide to file download in Drupal
Who am I | Where are we
11 heavens

Caroline
11 heavens.com

It's more of a philosophical "why" with some examples. It's a visioning book. What I liked about it is that it got into the discussion deeper than the various blog posts out there on the topic, many of which really are more of the stone tablets variety. Like most people, I got into CSS on my own several years ago, learning on my own, working largely alone until a year or so ago. I found his discussion of the kinds of questions you ask yourself when building a page from scratch to be reassuring, frankly. "Yeah, I've asked myself that all the time." So I like it. And I like it in part because it goes beyond just xhtml/css, and ponders user interface design in general. These things will become more and more important as we move from the rather primitive protocols we have to work with now into more robust solutions when, hopefully, nightmares like IE are fading memories.

And goodness, I am not at all offended! I am quite sure I probably absolutely despise a book you like. We'll just have to live with the consequences! ;)

Laura
_____ ____ ___ __ _ _
design, snap, blog

_____ ____ ___ __ _ _
Laura Scott :: design » blog » tweet

I don't know you well enough to say this but let me say it anyway : I already like you, Laura ;)

By the way, this presentation you gave on themeing was awesome. I wasn't present, unfortunately. However, I downloaded the pdf slides from your web site. They are very well-done.

Boy I am sure you would dislike many books I read and love. And like you I can be-friend people who hate what I love and love what I hate LOL...

Another book that goes into the philosophy of standards, but in a different way, is Zeldman's book, Designing with Web standards. I bought the first edition (and the second edition IS a re-hash for the most part).

I am also (like yourself) self-taught... for the most part, that is.

Caroline
A coder's guide to file download in Drupal
Who am I | Where are we
11 heavens

Caroline
11 heavens.com

It's time we all stopped hacking for IE. This discussion about tables vs. CSS-only would not even be happening were it not for the rendering inconsistencies of Microsoft's browser. I've just read this thread up to this point, and I decided to stop reading. When I see people advocating the use of tables to lay out a site and then CSS on top of that, I cry a little. This "hybrid" way of thinking is not only unnecessary, it's a bad way of marrying two technologies of which one arose to combat the first.

All of us are guilty of hacking for IE. Laura just made mention of learning some CSS hacks to get around IE's quirks, but it doesn't have to be that way. Microsoft has now given us a way to send good, solid, well-planned CSS to all the browsers that get it right, and then override IE with just the styles it wants in order to be happy. This entire discussion on the merits of tables for site layout is meaningless. Tables used to work great. That was before we built a newer, faster spaceship called CSS. The only reason that anyone is still arguing for tables is because they either don't yet understand the advantages of CSS, or they are fighting the IE browser and need a rock-solid fix. That's fine. If you wanna use tables, they'll still work. For a while. I'm going to use CSS-only because it's cheaper for my clients, and in return, I'll get richer for it.

It's 2007 now, and handheld browsing devices now outnumber desktop computers in Japan. Why would we designers continue to feed table cell code + content text + images to a user, and then send them yet more code in the form of a stylesheet that serves to undermine the very essence of the table we just send them? Why? Would someone tell me why? Is this type of thinking the reason I have to wait for three minutes to see a single screen of text on my Blackberry? Users who only want the content. Designers who are straining against forces of nature to send the users a pretty design.

I just don't see the point. Oh wait. The content *is* the point.

[/senpai]

****
Joel "Senpai" Farris | certified to rock score
http://transparatech.com
619.717.2805

I haven't read all of the discussion, but in 2007 you shouldn't be using tables for layout. This is from a design, technical, accessability, standardization and semantical point of view. Their purpose is to present tabular data (thus the word "table"). Using tables for building layouts are more of a hack than a technique, and although it may be the best option in some cases, I think if you design in a way that requires tables for layout, you are not doing it right.

The problem is this: A lot of webdesigners don't design for the web. They still design websites as if they were designing brochures or posters to be printed. The web has a completely different character and use, and one should design thereafter.

These articles on A List Apart are all worth reading:
http://www.alistapart.com/articles/dao/ (my #1 reference article on web design)
http://www.alistapart.com/articles/outsidethegrid/
http://www.alistapart.com/articles/journey/

Joakim Stai – Kollegorna

I really like A List Apart, the site has great thoughts and how-to's.

The article referencing the Tao Te Ching doesn't reference enough of chapter 2 which is pertinent.

When people see some things as beautiful,
other things become ugly.
When people see some things as good,
other things become bad.

Being and non-being create each other.
Difficult and easy support each other.
Long and short define each other.
High and low depend on each other.
Before and after follow each other.

Therefore the Master
acts without doing anything
and teaches without saying anything.
Things arise and she lets them come;
things disappear and she lets them go.
She has but doesn't possess,
acts but doesn't expect.
When her work is done, she forgets it.
That is why it lasts forever.

Absolutely. The whole book is relevant, so here's the link to GNL (GNL's Not Tao), a GPL licenced interpolation of Tao Te Ching translations:
http://alistair.cockburn.us/index.php/Peter_Merel's_Tao_Te_Ching_translation

Joakim Stai – Kollegorna

I started this animated discussion, and I hope it will go on for some time. It's been both fun and instructive to read what y'all have shared.

There are some intermediate conclusions to be drawn, at least with regard to my personal situation. The most important one is that there is a discussion. From what I've read elsewhere, I got the uncomfortable feeling that allowing even a single table in my design would beam me back to the Flintstones. From what I've read here, I have at least gained the conviction that I can allow tables in my design, and that much of the criticism on table-based design comes more from "religion" than from hard facts. I'm not all that religious, I want things to work.

With regard to those, hard facts I mean, I have learned that:
* tables don't work well with cell phone displays. To be honest: I couldn't care less... Call me stubborn if you feel like, but on a site with a couple of thousand of articles like mine (not data, not short tidbits, but real articles of a couple of five-thousand and more characters), cell phone readers are an extremely rare breed. I simply don't have the time nor the urge to accomodate them. If they want to visit my site, they're welcome, but then they should come with a real computer, not with some tech thingy which is simply not meant to read articles. Hmm, come to think of it, nice analogy: if tables are not meant to layout sites, then cell phones are not meant to read websites * grin *.
* I have also learned that there are many, many browser-specific idiosyncracies with regard to complicated CSS constructions, which do away with the supposedly increased maintainability of CSS-based table-less design. Now, I now there are also idiosyncracies with regard to tables, but my impression (and practical experience) is that tables are a very reliable tool to construct something, also across various browsers.

I have also learned that "table-less advocates" claim that tables should only be used for tabular data, address lists, that kind of stuff. But, umm, isn't the idea of most websites "tabular", actually? I mean, just look at the efforts of table-less design: what are they after? They want to create a table-like look - but then without table markers. Strange, actually :-) Why not simply use, darn, what's the word, tables?

The most important thing for me to remember is that at this moment there is nothing wrong with using tables (or a hybrid approach). CSS is a very important tool to style certain elements of a website, and it's a stupid person who refuses to incorporate the benefits of CSS in his site design, but there are limits to everything, even to the usefulness of CSS.

The bottom line for me is: don't worry too much about tables or table-less. Worry more about good contents, about easy navigation, and about the next query to reveal unexpected connections between your data.

Ludo

I agree that one shouldn't worry too much about tables vs CSS, the contents and thought behind your website is what's most important. And in essence, it's really what floats your boat. It's great that you asked these questions, have listened to the arguments, and then made your choice. After all, it's not the end of the world if you use tables :)

Still, like I said in my post just above yours, it's all about how you go about creating your design. If you design like you're used to (or taught to) - for the printed medium - your website will most likely not fit that well on the web. On the web, the information stays the same, but the presentation always change, depending on the browser and the viewer. Resorting to tables and a rigid design, you won't play along with the nature of the web, but fight it. That's why I don't like table layouts.

Also, if you design your website following the W3C standards, you will get a website that is more accessible, easier to maintain and probably more future-proof. The browser quirks are still there though.. It's not easy to be a webdesigner! And unfortunately, most designers aren't programmers. Naturaly, they want to focus on what they do best, the creative stuff, not all the tedious CSS tweaking to accomodate for the numerous browser bugs.

Joakim Stai – Kollegorna

Also, if you design your website following the W3C standards, you will get a website that is more accessible, easier to maintain and probably more future-proof. The browser quirks are still there though.. It's not easy to be a webdesigner!

The following quote is the crux of the issue for me. So many tableless advocates say css is easier to maintain, but in practice, that's simply not true. The browser quirks are maddening. You can't make a single change to a tableless structure without retesting the design in about 10 different browsers. There are scores of tableless themes on Drupal.org that won't render properly in some browsers, because the designers were unable or unwilling to work out all the browser bugs.

I come from an entrepreneurial background, and I've seen tons of programmers who saturate themselves in their "art" to the point where very little actual work gets done. It's good to have core programmers and designers concerned about the future and the "art" of their craft, however, for the general user population of Drupal, we should be recommending solutions that work for people's needs.

But, umm, isn't the idea of most websites "tabular", actually?

No. Tabular means tabular: that is, data that is best presented in labeled rows and columns. A product list featuring name, price and quantity is an example of tabular data. Paragraphs and headings in a teaser list aren't. You're right that a hybrid approach can work but only up to a point. Graphical table use needn't and shouldn't go beyond one big uncomplicated table to contain your body elements. You shouldn't be nesting tables.

A very good discussion of tables is available at webaim.org a site dedicated to accessibility issues. I recommend you read it. It's nice and reasonable rather than religious.

I don't know if anyone's mentioned it yet, but one of the great things about Drupal is that developers have control over markup and therefore can avoid tables altogether. You can't do that yet in Joomla without a lot of hacking.

"I don't know if anyone's mentioned it yet, but one of the great things about Drupal is that developers have control over markup and therefore can avoid tables altogether. "

I agree, 100%

Earlier I noted "I would have to write a lot of theme function over-rides to get full control of all the html that is output by drupal modules", I also said that "sometimes it makes me crazy," but the simple fact is that designers ultimately have full control over the markup, without hacking. Drupal was designed with the idea of "default" markup which anyone can change by including an appropriate function in the theme's template file.

Amazing! Thank you Drupal developers!

isn't the idea of most websites "tabular", actually?

I learned to design in the post-table-era, and the above is a conceptual framework that is not instinctual to me personally. I think of my sites as chunks of discrete content - each in a div that I can move around, cut 'n' paste, slap anywhere and fiddle with in a very granular way. Trying to ease that same content into the cells of tables generally confuses the heck out of me and I give up trying to count everything out in rows and account for all those empty cells and end-tags. Perhaps I just have a less linear brain, or with me tablelessness is more a matter of habit than anything. Although come to think of it, I've taught blind students who use JAWS readers and have seen the conceptual mess some nested-tabled sites can create for sightless visitors.

Drupal is itself pretty modular with its literal building-blocks; thus it fits right into my sense of chunks of content that are positioned however I want via CSS. But I imagine the same is true for those who are used to squeezing content into table-boxes. I say (granting a certain modicum of competence on the part of the designer) live and let live.

Standards – tables were intended for tabular data not layout. CSS Files are cached and therefore the styles do not need to be reloaded for each additional page load. Reducing code combined with cached files makes for fast page loads. Fast loading pages will rank slower than very slow loading pages which may be overlooked completely.

Tables require much more overhead as a result of the number of tags necessary to create a simple box. IE: In a very basic example:

<div>Text Line 1<br />Text Line 2</div>

is essentially the same as

<table><tr><td>Text Line 1</td></tr><tr><td>Text Line 2</td></tr></table>

We haven’t even discussed formatting yet and you can see how much more efficient tableless layout is.

Add formatting, JavaScript, Flash, etc and now you have a serious code bloat issue. The SEs now are forced to sift through information which they generally don’t understand (though they are getting better) in order to finally read the content that they and your visitors want to see.

Google and many other search engines are text readers (“The Anatomy of a Large-Scale Hypertextual Web Search Engine”). Your visitors want text as well. Would you show them table code? If table code were visible to the visitor as it is to the SEs you wouldn’t use it.

Additionally, some search engines limit how far on the page they will scan (varies with engine). If the top part of your page code is cluttered with overhead and superfluous, bleeding edge gadgetry, then how successful can the page/site be?

There are always exceptions to every rule and there are millions of web pages ranking quite well with table layout. You do however have to question whether, taking some liberties, Occam’s razor will prevail. That being, if two pages are essentially the same, will the simpler page prevail? Since the SEs are looking at HTML code (for the most part) then the answer should be yes.

Tableless design is initially more complicated to develop. If it were easier then no one would be debating this. It is quite easier to use over time however. Most of the folks who are sticking with tables are doing so because it is quick and easy. Or they don’t have the time or interest to learn how to do tableless. From a marketing and maintenance standpoint tableless is the top choice.

On the other hand, if you don’t care about achieving the ultimate in rankings – you are willing to leave something on the table (no pun intended) and want to do something easily, then tables are for you.

People seem to become agitated with these types of discussions because posters seem to say that one way or another is the only method you should use. The simple truth is that you should shoot for a pure tableless design and if you need to, go ahead and use tables. This, at least, is my recommendation. FWIW.

How does this relate to Drupal? Depends on your theme.

Tableless design is initially more complicated to develop.

Why does this falsity continue to hang around? Tables are vastly more simple to use when you consider all the css, hacks, and skill involved in developing a page.

Your example above comparing tables vs. tableless failed to include the css necessary to make the two examples work. You also failed to include all css hacks that must be included for tableless designs. You also failed to include all the knowledge about all the hacks and how they relate to all the various browsers out there.

This is why I compared tableless css to a religion. Most of the people touting it, aren't looking at the real world facts involved in implementing css properly. It's more of an assumption and belief, rather than a conclusion from factual evidence.

That said, I know there is a handful of css mavens who can code tableless designs in html inside of a primitive editor, who can visualize their design from the command line, and have memorized every IE hack. Kudos to them. They don't need advice on theming. Beginners do, however, and they need accurate comparisons.

This is why I compared tableless css to a religion. Most of the people touting it, aren't looking at the real world facts involved in implementing css properly. It's more of an assumption and belief, rather than a conclusion from factual evidence.

No. See my post above - in real-world practice, I personally find tables to be frustrating & illogical and they can't ever quite seem to provide the means for what I need my content to do: float it, position it, etc. To simulate attractive designs I've done in CSS via tables, I have to start nesting them in awful snarls that take forever to pick apart if I goof. I love tables for tabular data, but definitely not for layout.

There aren't that many CSS hacks necessary these days, as browsers improve, and there are tons of web resources with free cross-browser CSS templates. Sure it takes time to learn CSS, but I'm not sure this is as black a strike against CSS-based design as you seem to think, zoon. You can't really argue against a method just because it isn't in your particular skillset and would take time to learn. Anyone who wants to poke around in the guts of an open-source application has to be willing/curious to spend the time to learn a new coding language or two -- otherwise they can just use it out of the box and godspeed to 'em.

Creating new block or page snippets in Drupal requires some PHP; this doesn't seem particularly objectionable to anyone. Well, ditto for design: creating a new theme requires some CSS. What's the big deal?

...if you've invested the time to learn css skills, it's a worthy cause. But the number of css hacks aren't going down, because the number of browser versions are going up. There are still plenty of broken browsers out there, IE 6 being one of the worst, and it still makes up half of all browsers.

To each their own, but there's so much talk of theory on Drupal boards, and yet tons of beginners are frustrated with its complexity. Why add to that complexity by layering in tableless css? We're trying to make Drupal more accessible.

If you doubt the lingering problems with tableless designs, just download ten or so tableless templates. You'll find 80% of them have rendering problems with one browser or another.

Dumbing down web sites because beginners don't understand how to create complicated web sites is not the answer.

Having a web page is better than not having one. So, if it is poorly designed and coded it is still better than not being in the game. As skills grow, so should the quality of the layout and code.

For me it is not a religion. Tableless layout is initially easier. From a cost standpoint it is better develop sites quickly. But, when clients come to me they understand that their site is performing poorly and they need the cold, hard facts on how to turn it into a performer. Suggesting table layout is not on the menu because, as I've stated previously, Occams razor takes effect. When all things are equal the simpler code will prevail. The way to have simple code is to eliminate tables from layout, to utilize CSS as much as possible, and to move Javascript, CSS and flash to external files.

And, to be reasonable for a moment, I'm really not saying that tables should never be used. I do say that there are many benefits to tableless design and if the budget is there it should be used. The number of sites that do not benefit from CSS let alone tableless layout is mind boggling. As an SEO I strongly suggest that client's sites have the cleanest possible pages. Sometimes this is not possible for numerous reasons but there are usually some areas that could be improved without much drama.

I don't preach religion. But from a marketing perspective I do prefer to use what works. Using tableless layout alone won't make a winning site. But it is one more element which will help in achieving objectives in a marketing campaign.

I don't preach religion. But from a marketing perspective I do prefer to use what works.

This is precisely why I use table based templates: they work. And they work in all browsers. I don't have to spend time checking for an endless number of hacks.

As pointed out in other parts of this thread, Drupal table based themes use the same or LESS code than tableless designs.

To each their own I guess.

zoon_unit,

It is very important that you do what requires the less effort from you. Both at the time of creation, and when it comes to maintenance as well. (There is not a hint of irony in what I am saying).

If, for you, it's easier to use a table or some hybrid layout, then that's what you should do. It's that simple.

I agree that some people are very defensive (even aggressive) about some new aspects of web design.

Semantic markup & tabless design really seems like a religion.

I am myself pretty much brainwashed with many aspects of web design. (No irony here.) From having read "gurus" tell me the same stuff over and over again. Although I do understand the logic behind all this, I am often oblivious of the reasons why and left with retaining the "do this and don't do that" 10 commandments.

I have learnt CSS and XHTML from whom I name (affectionately and ironically) "the Standards Village People", a more or less closely knitted group of people who are associated with the cause of pushing standards forward.

I am pro-tabless design, but you have my respect and my gratitude to have instigated this interesting discussion.

Best regards,

Caroline
A coder's guide to file download in Drupal
Who am I | Where are we
11 heavens

Caroline
11 heavens.com

I hope I haven't come across as too harsh in this thread, but it's really an attempt to challenge the css mavens a bit. I see so much talk about the promise of css standards, but there are very few sites that actually fulfill that promise.

The truth is, good tableless design that WORKS in all browsers is still very hard to do, but certainly not impossible. Some sites have done it. (there's some great Joomla templates out there) I even pointed out in another thread that drupal.org's tableless design still doesn't handle wide images and urls very well. (blocks overlap)

Most of the tableless themes submitted by Drupal users are not fully realized and debugged. Almost all of them have rendering problems with one browser or another. Garland, while pretty stable, is a pain to try and modify for someone's custom theme.

Table based layouts are old tech, and tableless is the future, BUT, I'd like to see the tableless proponents make a more convincing argument for young web developers to switch NOW. And the most convincing argument would be a stable, professional looking, easily modifiable, tableless theme for Drupal.

Until that happens, I feel no guilt in urging new Drupal developers to start with a tried and true table based design to get their site up and running with a minimum of hassle. :-)

It may be easier to code but it doesn't work better from a marketing perspective and that is what I stated in my post.

I said: "Tableless design is initially more complicated to develop"

You said: "Why does this falsity continue to hang around? Tables are vastly more simple to use when you consider all the css, hacks, and skill involved in developing a page."

How is this false?

My bad. I read your statement wrong.

Apologies.

(where's that forum edit when you need it?) :-)

Let’s not forget the seminal “To Hell With Bad Browsers”. In that article about CSS-based layout from 2001, Jeffrey simply states:

If you’re a web designer […] in six months, a year, or two years at most, all sites will be designed with these standards. […] We can watch our skills grow obsolete, or start learning standards-based techniques now.

If you are a web developer and are still using table-based layouts, you are way behind. Your skills are already obsolete; when your clients wonder why they have such poor search engine positioning they will find out your skills are obsolete, too.

If you are not a web developer, you should still care about accessibility issues (blind, color-blind, poor-vision, learning-disabled, screen-reader-users, etc.)

And even if you don’t care about that, you probably care about SEO-issues. CSS-based layouts are way better for SEO (Search Engine Optimization) and for accessibility.

  - John

Albin.Net : friendly web development

  - John (JohnAlbin)

In that article about CSS-based layout from 2001, Jeffrey simply states:

If you’re a web designer […] in six months, a year, or two years at most, all sites will be designed with these standards. […] We can watch our skills grow obsolete, or start learning standards-based techniques now.

It's now 2007, six years after that quote was made, and STILL, IE 7 isn't fully css compatible, IE 6 is a horrendous mess and still makes up over half the browsers out there. Firefox still renders completely differently from IE 6, IE 7, and Safari.

What good is it to design to standards when mega corporations like Microsoft ignore said standards??

Here's how:

First, here's a statement I think we can all agree on:

Tableless, css designed pages are the designs of the future. They provide semantic context, are usable for all browser formats, and follow well established css standards. When fully supported by all browsers, tableless designs will be the only practical solution.

Now, to end the debate, we only need to deliver a tableless Drupal template with the following attributes:

1) A design that is malleable and easily changed by moderately skilled developers, where logo placement, menu placement, colors, graphics and background images are easily updated.
2) A design that displays consistently between all browsers and won't break with moderate design changes.
3) A design that is usable by commercial sites and approaches the visual acumen of many Joomla templates.

When the preceding features are available, I will gladly switch to tableless formats and never look back!

Use Garland.

Or write your own.

There are tons of resources on the web for instruction in tableless design. Also lots of free layouts for the taking. Try to understand the css behind them and you'll know more about how not to break them when making modifications.

The w3c has a good tutorial on tableless design. Thre are tons of other resources only a google away.

If you are an American, it is only a matter of time before the ADA requires you to make your sites accessible for screen readers. Complex, table-based design won't cut it in that world and the best shops won't hire folks who refuse to update. For professional reasons alone, it makes sense to come to grips with this as well as other aspects of standards compliance and accessibility. Tables are only a piece in the puzzle.

Garland is neither malleable, nor easily customized. Name a single new template based on the Garland code base. Garland, while a nice looking theme, is also not appropriate for commercial sites.

Since css is so easy, and has so many advantages, I'm eagerly waiting for someone to turn out a bunch of these "easy" templates. Zen might be a step in the right direction, but as I understand it, the Zen template designers are STILL struggling with rendering issues three months after its inception.

Doesn't sound too easy to me.

Is Garland really that hard to customize? I did my site in half a day. http://www.joelfarris.com

I found it to be well-thought out, highly intuitive and sorta well documented too. I actually think that with a bit more inline notation, Garland would be my first go-to template for new sites. Heck, it's not even that hard to turn a three-column Garland site into a two-column layout just for the admin section.

[/senpai]

****
Joel "Senpai" Farris | certified to rock score
http://transparatech.com
619.717.2805

When I went to your site and the text extended out past the end of my 1024x768 Firefox browser window, requiring me to scroll right to see everything.

Yeah, I guess Garland and CSS is easy when your standards are low.

not happening for me in IE7

I belong to that 25% of the population over the age of 50 and I use larger font sizes. (as do many, many people)

If he had used a table based design, the extra large title of his website would have wrapped to the screen and remained visible at least. Score another one for tables.

This is my point. So many CSS mavens rave about how easy CSS tableless is, but then they sometimes don't even test their designs thoroughly. What happens when users increase their font size? Use large images or extra long urls? Have ultra high resolution screens? Low resolution screens? Have javascript turned off? and so on.

I see many websites written tableless that continue to have rendering problems, yet their designers "claim" that CSS works just fine. (even drupal.org can't handle wide images without blocks overlapping the images) That's not my idea of a reliable, professional design. Maybe I'm just picky. :-)

True enough, Senpai, the title would be a good fix even with small text and then you would look brilliant. Might want to think twice about the wide images, too, those on dialup will thank you. By that I mean anything much wider than what you have. Nice Harley!

If those are your needs, zoon, as always with open source: deliver it yourself. Design one; all of those attributes are perfectly achievable in tableless design.

I love the standby Drupal answer to everything: "just do it yourself."

Well, you'd think by now some hotshot Drupal developer would have "just done it himself" already.

Why haven't they? Maybe because it's difficult?

hey Zoon, "Drupal" is all just single contributors like me and you, not some faceless conglomerate hoarding arcane design secrets. I'm saying: empower yourself! If the "hotshots" are too busy to provide you with free labor, well, then become a hotshot. If hotshottitude is really what's required to deliver a tableless theme.

Dunno where you're looking for themes, but I use 4.7 and find wireframe to be a perfectly solid, elegant, infinitely malleable tableless theme base. Try playing with it and you might be surprised how easy CSS can become.

So wireframe isn't an option. The point of this thread was not to complain about the lack of good tabeless themes, (although that IS a problem) but to answer a question about what kind of theme a beginner should start with. Table based themes are easier to manipulate and render more reliably. That's just a fact.

I believe all you would need to do is replace the primary and secondary navigation code with the new standard, and that is simple and snippets are there in the handbooks. It's a very minimalist design and not difficult to update. Now I've not tried it, and IE7 did end up breaking many css-only layouts, so maybe it needs some IE7-focused love. The theme has a new maintainer but he hasn't posted any updates yet.

As for what's easy, tables may be easier to create, but they aren't easier for the wide variety of users out there. A site-visitor-focused approach would lean heavily towards leaving tables out of it.

Laura
_____ ____ ___ __ _ _
design, snap, blog

_____ ____ ___ __ _ _
Laura Scott :: design » blog » tweet

As for what's easy, tables may be easier to create, but they aren't easier for the wide variety of users out there. A site-visitor-focused approach would lean heavily towards leaving tables out of it.

Don't get me wrong. I'm not against tableless design. Far from it. But your statement above is the part that confuses me.

How is a table based site not easier for the users? You've already pointed out that the tableless theme you mentioned has some rendering problems in IE. Isn't that a problem for users?

The SINGLE reason I advocate tables at THIS POINT is that most tableless designs have rendering problems. And that's bad for users and web developers. Heck, even Drupal.org can't render images properly. (blocks overlap and obscure wide images)

So what's easier for a user? A site that renders like it's supposed to, or a broken site that can handle mobile users and is semantically correct?

The ultimate answer would be a site that does both. So I'm plenty interested in finding a truly bombproof tableless design that "just works" as well as table based designs.

How is a table based site not easier for the users?

For JAWS and WebEye users, table-based visual design is a semantic mess that renders many sites unreadable. FWIW.

I'm certainly no expert on screen readers, so a few questions:

1) Are the limitations in tables for screen readers intrinsic to their function, or more an issue of poor table design? Div based designs can also be poorly designed semantically, can they not?

2) Can't the limitations of tables be overcome with proper design and the use of css tags, the same as with divs?

The use of tables in Drupal templates is usually, and should be, limited to zoning of content. This use only requires the simplest of tables: one table, 2-3 columns, 3 rows, etc. In such a design, the reader should be working its way down the page sequentially much like a div based system.

The reason why tables are superior to divs for content placement is because browsers act more consistently and "smartly" toward elements that would typically break a tableless design, where blocks typically "ignore" and overlap one another. Fluid layouts are much easier to program with tables.

If tables simply can't be read properly by screen readers, then I would definitely call that a major user limitation.

There are two things that are being wildly overstated in this discussion, which is pretty near the circular point if not there already. First, the table-less evangelists are wildly overstating the problem of tables and screen readers. Meanwhile the pro-table diehards are wildly overstating the difficulty of cross-browser css.

First -- screen readers: Screen readers deal amiably with a basic table or two used to constrain a layout and in which the content sequence works logically with the way screen readers read tables: Row by row and within each row from left to right. In areas where it's not optimal: such as putting the navigation before the content, skip-to-content links allegedly suffice.

Screen readers don't deal well with table layouts that use elaborate setups of nesting, empty columns and spacer gifs to achieve visual ends since these do make a semantic mess of the document. That said, it has been shown that folks using screen readers deal with a document in much the same way sighted users do: they do the aural equivalent of scanning, zipping by content that doesn't interest them and pausing when they hear something that does. It's doubtful that any content-rich document is made completely useless by its layout. And you are right zoon_unit that many table free designs are not semantic either with wrappers in wrappers in wrappers. However, I don't think screen readers deal as explicitly with divs and they do with tables. I think wrapper divs and things like that may be more or less 'invisible', though I'm not sure.

Second -- about all those terrible css bugs and the sparseness of layouts to resolve them: There are hundreds of css layouts on the web. If you're not finding them, you're just not looking hard enough. And where is written that web designers and developers should get by ENTIRELY on other people's code, anyway? As to how well they deal with different browsers: really, the only problem left in this regard is IE and even it has gotten marginally better with the latest release. If I create a layout, testing only in Firefox during development, I can be reasonably certain that it will be consistent in Firefox on all operating systems. Nine times out of 10 it will also play well with Safari. The best way to handle IE is not to even bother trying to find some compromise between the way it renders vs. the other browsers. Just create a stylesheet for IE (that gets included with your main sheet and includes only the styles where IE is choking) and use the conditional syntax that Microsoft developed for this purpose.

This shit is not rocket science now and plenty of folks have done the hard part for you.

I find it ironic that the websites for the two software programs you mentioned use tables for their layout.

I guess that ends the screen reader argument! :-)

Alas, it's not my job to lobby on behalf of a certain percentage of web users. One can choose to familiarize oneself with the accessibility recommendations of the W3C and ADA and their basis, or not. Totally up to you as a sovereign web designer.

You've availed yourself of the myriad educational resources on the web and made a well-reasoned decision to use tables for layout? Then use tables! No "argument" here.

I'm laughing because the vehemence in this thread comes from the tables advocates, which is ironic given that the tables advocates assert that the rest of us are part of a "religion."

From what I read, tables are the way to go because:

  • Tableless is too hard.
  • The reasons for semantic design are too futuristic.
  • Accessibility doesn't matter.
  • Tableless is too hard.
  • Poo-poo-head!

Okay, just kidding about the last. Still, I haven't seen any reason to pursue table-based page layout. My feeling is that if you want to do it, go ahead, have fun. I'm not convinced, though. If you're not convinced either, well, c'est la vie.

Laura
_____ ____ ___ __ _ _
design, snap, blog

_____ ____ ___ __ _ _
Laura Scott :: design » blog » tweet

And I'm the worst offender I suppose. :-)

But I still contend that if you look at real world applications, tableless design still doesn't deliver on its promises and beliefs. That's the definition of a religion: belief in a system that is unprovable in the real world.

I'd like nothing better than to see a good, malleable, tableless template that works well in all browsers, and can be altered as easily as bluemarine without breaking. I'll jump on the bandwagon.

Still waiting, though.

And yes, I'm going to try and write my own, called appropriately enough, "malleable." However, it will be a hybrid with tables to overcome some of the rendering issues. When it's done, I'll be happy for some css maven better than me to make it tableless.

I whipped up the Gutenberg theme over a long weekend to give Drupal users access to the large pool of Movable Type layouts that have been released. I think it's a pretty good example of how CSS skills and a reliable base layout (sans tables) can be whipped into a variety of new forms. http://gutenberg.cookingwithdrupal.org/gallery is an example of the various layouts that a simple drop-in css file enable.

We're using a similar technique on a client's site -- they want a core multisite setup for over a hundred different band/artist sites, and want to use CSS to design the different themes for each artist rather than hacking up the theme code itself. Occasionally they need to add a new tpl.php file to do something crazy, but with CSS it's possible.

Are these things possible using a combination of CSS and tables? Sure, in most cases. Is doing perfect column-structures in pure CSS annoying if you're not an expert? It certainly can be. Is doing anything other than 'Header, sidebar, center text, sidebar' in tabled HTML annoying? It, too, can be. Is basic page layout the main frustration with cross-browser CSS? No, not hardly. Anyone with ten minutes and google can find bulltproof CSS code for doing multi-column layouts that previously required tables. The real challenges come when doing complex nesting, tricky bits that touch on box model quirks, and so on. Those cases (like the vote-up-down issues mentioned in an earlier post) have nothing to do with tables-versus-tabless at all, and reveal the real issue: lack of CSS expertise and mistrust of the Markup + Styling paradigm.

There's no shame in that. I built web sites professionally as far back as 1997, and I watched table-based layout transition from a 'neat trick' to 'the norm' to 'an abomination.' Table based layout is a misuse of HTML; it may work for you, but please recognize that it's an abuse of the intent of the language. Your familiarity with the tricks used to make it work do not mean that it is a better way, just that it's a way you're able to make work without outside help.

--
Lullabot! | Eaton's blog | VotingAPI discussion

I'm not trying to "preserve" table design for all posterity. I'm just a pragmatic person. (comes from starting five companies) Table based designs are easier to grasp for new Drupalers, especially since there's so much to learn anyway. (I've just gone through this painful process)

You are right though, that excellent tableless designs are possible. And given a choice between an easy to use, stable, tableless design, vs. tables, one would be foolish to choose tables.

We're not quite there yet. Gutenberg and Zen are definitely steps in the right direction. (and even Garland, with it's color picker) But the css code is really disjointed and hard to understand for newbies whose css skills are lacking.

I'm hoping we'll start to see better tableless designs, ones that use the latest css techniques, ones that are more "modular," making it easier for themers to drop in and change certain elements without breaking the design.

I truly feel theme development is a huge ACHILLES HEEL for Drupal. Joomla templates simply look and perform better for users, who seldom see the code underneath. (under the covers, Drupal is more beautiful)

But we need to give the big D some new clothes. :-)

Some of the folks here who are advocating tablelessness are using tables for layout.

scattered sunshine is nearly two years old. And in the web 1.0 days I used tables a lot. I admit it. We all learn from experience. There's no way I would build such a simple theme using tables today, and if I ever get the time, I will update the theme into a tableless layout. Time is the issue. These days I hardly have the time to do photography, let alone post it on my photoblog -- let alone revamping the photoblog's theme.

Laura
_____ ____ ___ __ _ _
design, snap, blog

_____ ____ ___ __ _ _
Laura Scott :: design » blog » tweet

The best argument for tableless design is that you can serve content differently depending on the "media" : print, screen, and handheld.

A trivial example : say I want to make my web pages printer-friendly, I create a stylesheet that simply gets rid of the content I don't need for print with display:none, and I give that stylesheet a media attribute "print" in my web page header (that's a simplification... I may do other things in that stylesheet).

And I can propose alternate layouts for the same page, i.e. the same HTML, with two or more different stylesheets. And these layouts can be radically different.

If my content is in a table, I cannot swap anything on the web page. Also, I cannot make anything truly invisible leaving NO white space behind, unless I am making entire rows disappear.

Caroline
A coder's guide to file download in Drupal
Who am I | Where are we
11 heavens

Caroline
11 heavens.com

I said the same thing up above, http://drupal.org/node/132899#comment-217430 and both zoon_unit and brooklynwebguy decided to jump down my throat about it.

In the end, I decided to just walk away. I have far more important things to do than convince people that tableless is the way to go. I was actually surprised people were still arguing about this!

The Drupal community used to be so peaceful. This is by far the most hostile thread I've ever seen on drupal.org. :-(

======
Jason

======
Jason

Maybe I haven't read the hostile posts, but this thread seems to be a heated discussion about using tables vs divs for layout. I don't think it's got too ugly yet!

There's certainly no hostility intended on my part. I've tried to engage in good debate and provide evidence for my views. That is the foundation of good debate. If one believes something strongly, you should have good arguments for your beliefs. Otherwise it might be time to change said beliefs. I tried to provide that evidence and also acknowledged other posters' legitimate points.

I certainly don't have any hostility toward you or anyone else here. If you've mistaken my spirited debate for hostility, you have my apologies. I thought I made that clear on the other thread:

I'm certainly not getting upset with you. You are certainly entitled to use whatever method works best for you. It's just that you mentioned a few points that I found to be inaccurate, and I wanted to correct them.

We don't all have to agree to get along.

In the end, I decided to just walk away.

Oh good God. I didn't jump down your throat, I said you were wrong.

I am also won over to tableless design, as I made clear. Folks can just disagree over facts -- really.

Speaking of which -- your hiatus from this snakepit of heartless table enthusiasts hasn't made you any more correct: Table elements can be rearranged and also made to disappear on a granular level. An example is below. You can also set your trs and tds to display:block in which case they essentially behave like divs.

This is a demo, not a recommendation.

<html>
<head>
<style>
  td#one {
    background: red;
  position: absolute;
top: 400px;
left:10px;
}
td#two {
    background: pink;
  position: absolute;
top: 300px;
left:10px;
}
td#three{
    background: blue;
  position: absolute;
top: 200px;
left:10px;
}
td#four {
   display: none;
}
</style>
</head>
  <table>
  <tr><td id="one">one</td><td id="two">two</td><td id="three">three</td><td id="four">four</td></tr>
</table>
</html>

Extracts fromWCAG 1.0;

And if you use tables (Priority 1)
5.1 For data tables, identify row and column headers.
5.2 For data tables that have two or more logical levels of row or column headers, use markup to associate data cells and header cells.

And if you use tables (Priority 2)
5.3 Do not use tables for layout unless the table makes sense when linearized. Otherwise, if the table does not make sense, provide an alternative equivalent (which may be a linearized version).
5.4 If a table is used for layout, do not use any structural markup for the purpose of visual formatting.

And if you use tables (Priority 3)
5.5 Provide summaries for tables.
5.6 Provide abbreviations for header labels.
10.3 Until user agents (including assistive technologies) render side-by-side text correctly, provide a linear text alternative (on the current page or some other) for all tables that layout text in parallel, word-wrapped columns.

Don't forget it is a legal requirement (in UK) for websites which "provide a service" ( see DDA1999 and PAS78) to conform to WCAG1.0 level A as a minimum standard.

I would like to know how many of these tabular designs mentioned on previous posts will conform to any of the above requirements.
I only ever use tables for displaying data, never ever for layout, using CSS is much easier anyway.

please delete this.

thank you.

Sometimes something interesting appears on http://litwol.com