Forum Moderators: phranque
I am doing a makeover/redesign on our site which has loads of content but is lacking in useability.
Should I use Tables to lay it out ie one big table with some nested tables? I have heard that tables aren't like though.
I can't think of a better way of laying out things easily.
I also want a site which the search engines would be proud of,is simple, looks professional
Could anyone point me to a well laid out site which is user AND search engine freindly.
Just some personal preferances
I don't like
Flash
Java,
drop down menus
Thankyou
If your design requires tables, use tables.
There is nothing wrong with using tables if the need exits. However, using CSS just because you can is not a valid reason to use CSS either.
Anyway, the brief version is that you can do exactly the same as you are doing with <TABLE> by using <DIV> and <SPAN> and even more using the latter two. As you can do most of the same basic things using either method, your question boils down to: What's the proper way then?
Well, for one thing - the HTML purists will agree on this - tables are... well, tables: Columns and rows which lists prices, features etc. It is not intended for page layout at all. DIVs (and SPANs) are.
There's this "back to basics" thing going on with tables at the W3C... Tables specs will in the future (and do already) contain a lot of meta-information, that is information about the stuff that you are presenting in the table. It will not be (is not) just <tr> and <td> anymore. You'll have the table headers, the row-groups and column-groups, plus descriptive information about table content, table headers, table rows, and even table cells. It's developing into an XML-look-alike imho.
This is all done for one very nice reason: Making the web more accessible to all people, even those with physical disabilities (and yes, such people also have money to spend : )
Anyway, using DIVs instead implies a different way of thinking about page layout and positioning; that's perhaps the biggest hurdle. Once you are over this, however, you'll find that DIVs are much more flexible than TABLEs and that you can do more things with them - things that will even be valid code (if that is a plus to you).
----------
¦x¦...y...¦
¦x¦...y...¦
¦x¦...y...¦
¦x¦...y...¦
---------- x being your left navigation and y being your content. Then, if you use TABLEs you would have the navigation topmost in your page source (in your HTML, as tables have the leftmost elements on top). That means that the spiders will have to read this before they start reading your content. With DIVs you can place the navigation in the bottom of your page in stead.
One serious caveat here: This is not user friendly for PEOPLE using eg. Lynx or a screen reader. Left hand side navigation (using tables or divs placed topmost in your code) will always be displayed at the top of the screen for such user-agents, which indeed IS the preferred way.
This way it is easy to navigate to the desired page using [tab], [number] or other means without having to go through the whole text of an irrelevant page first. Remember that for people using such User-Agents, your layout is more likely to be an obstacle than a good looking experience (in these cases, content is not only king, it's the sole inhabitant og the kingdom - colors, images, bells and whistles just does not count as they are not even there).
IMHO, an alternative placement of the navigation in the code is only a valid option in the case of... well... whatsit... "super-keyword-optimized very competitive pages aimed specifically at SE spiders above people" - you get the point i think...
What you should base your decision on, is this: Do you want to actively pursue the aim of making the web more "transparent" and "accessible"? If yes, you really should start using tables for tables and divs for layout.
Tables are developing into a separate subclass of HTML-containers, one that is very usable for the purposes that tables normally are used for (outside the HTML-world) and DIVs are getting all kinds of formatting and positioning possibilities that make them just perfect for layout.
I don't say that we are there yet, as browser support is always the limiting point, but the standards are already in place and that's the direction in which we are heading imho.
/claus
The latter has the advantage, though, that you are not limited to thinking in terms of "cells" - two DIVs can easily occupy the very same screen space and be located two very different places in the HTML-code.
I still have a way to go but from what I'm hearing Tables ae not the way to go anymore.
I have noticed that when I tried the netmechanic html check it always has 30-60 errors with tables-even my newly created ones in my newly purchased Fron page (PLEASE don't say I shouldn't have brought this!)
One thing I like about tables is its easy to set background colours for cells etc so its easy to define columns in a differant colour-can this be done with css?
Ah ha! you may be hanging out in a certain crowd and talking to the techno lot or going to a lot of css sites. A lot of css fans have never really used tables, and of those who have, many have not learned to use them efficiently and simply and with a view to their advantages in Search engine optimisation.
That said tables were never designed for layout of pages and sites in the HTML spec, (then again, its the users that tend to mould how things are used, rather than the more theoretical designers) but heh.. im a pragmatist. i will let the young turks work out all the bugs for the next few years, and maybe one day we will use it much more.
I agree that css formatting can be useful, especially in reducing code and caching formatting info, but we have done a lot of work on deciding what designs to use for practical purposes over the past 3 years with various experiments, and we do use css for a lot, but always use tables (never embedded) for layout. Browsers are not quite up to the stage where they parse css correctly or consistently, depending on the level of CSS you use.
For example last time i looked the css guys were still agonising over how to reliably create 3 column layouts with a full row at the bottom or top, and using "patches" and extra code to make sure their solution was reliable. (This is NOT a troll! and i may be wrong these days ;))
So for us it is much less about "the right way to go" but more about using bits of each which work the best - now!
[edited by: chiyo at 1:05 pm (utc) on Aug. 17, 2003]
While you are there learning css, try to leave FrontPage alone and do some hand coding... It will be hard at the beginning, but it is a great way to learn and to have *clean* code. Maybe you should have a look at HTML-kit, which is free and helpful for hand-coders (any text editor would do, by the way).
Yes, you could do it this way:
IN STYLE-BLOCK or STYLE-SHEET:
---------------------------
.color1 {
background-color:#ff0000;
color:#ffffff;
} IN HTML CODE:
---------------------------
<td class="color1">some text</td>
or:
<div class="color1">some text</div>
or:
<a class="color1" href="some_link">some link</a>
--------------------------- Just add the class="color1" to what you'd like to use these colors for, this way the TD or the DIV or the LINK will automatically take on the colors defined in the class "color1". Note that i use both background-color and font-color at the same time.
>> last time i looked the css guys were still agonising over how to
yes, some things are still much easier to do with tables, i think you should use the method that solves the problem at hand.. sometimes tables are better and sometimes they are not. I just tried to give some perspective on the development of things the way i see it coming, i'm no CSS-fundamentalist when it comes to tables ;)
/claus
re: text browsers. I sometimes surf on a cellphone (Japanese iMode, reads old html fine) and they work best when content is high on the screen. Solution for the text browsers, though - how about a link at the top to an anchor at the top of the navigation? Won't make a difference to css-viewers. (especially if it's a 1x1 pixel trick, with the alt of the image being "click here for the menu", visible to text browsers)?
for me that sounds like a perfectly fine use for a table... after all, it is tabular data. I found one made with css here:
[la-grange.net...]
- i'd still prefer a table though ;)
>> it's a 1x1 pixel trick, with the alt of the image
Great tip, i didn't even think of that. Of course! - a link to the navigation does the trick :)
/claus
I'm fast learning about css after starting from zero when I first posted this.
I can find a lot of good info on formatting fonts etc and I think I'm OK with that but trying to find info/lessons on 'designing table like layouts wih css for dummies' is qite difficult.
The questions are:
Should I delay my redesign (which was going to use tables) until I know how to use css or should I plough on and use tables for the columns and css for the text? ie the bit of both approach.
Also with regard to seo does one have an advantage over the other?
Thanks
> ie the bit of both approach.
In theory, I'd like to follow the 100% css route, but in practice I've had to go with a hybrid, i.e., light(er) tables and heavy css. I'm a BIG believer in headers and footers and pure css gives up too much valuable footer real estate, imo.
<added>
>with regard to seo does one have an advantage
Perhaps a slight edge to pure css, though I'm not overly concerned about having content in the middle of the page.
1. With CSS you can keep the code cleaner by having all your colors and font styles, etc in an external style sheet. Goal is to be able to comfortably read your content in source code view ;).
2. Also with properly formed HTML you define the structure of the document more explicity making it easier for machines to parse the content.
3. Regardless of the approach you use, strive for ease of maintenance. A well written CSS or table-based layout can accomplish this.
If you go with a CSS layout keep it simple. Forget the 3-column hacks of the world and don't try to emulate tables. CSS give you other interesting possibilities to explore.
Nah, i think the bit-of-both might be the way for you until you get more used to the CSS approach. Just try to use a very minimum of tables, ie. not tables-in-tables-in-tables...
You might want to make one overall table and then use CSS for the rest to get you started, like this or whatever you choose:
--------------------
¦..................¦
--------------------
¦..¦............¦..¦
¦..¦............¦..¦
¦..¦............¦..¦
¦..¦............¦..¦
¦..¦............¦..¦
¦..¦............¦..¦
--------------------
¦..................¦
-------------------- /claus
What is puzziling me tough is just how do you work with it as surely its not wysiwyg and it must be coded and then tested-is that how it works?
At least with tables you can have an idea what the finished thing will look like.
Sorry if this is a stupid question....
That's the downside... or the upside, it depends on your view. You sometimes test a lot to get the desired effect, but once you've done it, you'll be able to re-use it at another occasion.
Personally i hand-write all, even tables, so i'm accustomed to it and i feel it gives me greater control and it's even easier for me that way, but i think WYSIWYG editors do have CSS modules as well, i don't know which are good though.
/claus
I'm getting pretty excited at the possibilities with style sheets, one BIG advantage I can see is that you can put graphcs in the background and they load after the main page.
>> graphcs in the background
When you get a little more comfortable with the CSS thing, you'll find that you can do a whole lot more with graphics using CSS than you can do without it - you can even have layers of different graphichs, one over another and switch between them - that requires a bit of javascript as well though, but you'll get there ;)
/claus
The first thing I learned how to do with CSS was to eliminate font tags in a site that used tables for layout. I stayed in that mode for a while, making pages based on simple table layouts, with CSS for formatting, rollover effects, and so on. Over time I learned to use div's for positioning, and I finally graduated to table-free pages in some recent projects.
Now that I know what I'm doing (or so I like to think!) it won't be difficult to "de-tableize" existing pages as time permits.
I love the way the contents fill he screen even if you drag the browser window smaller-with my table site I just loose info.
I think I'm a convert and thanks to this geat site-I will try and 'give something back' later on when I can be useful but I am a novice at the moment!
Iv'e copied one of the [CSS] layouts at Glish...I love the way the contents fill he screen even if you drag the browser window smaller-with my table site I just loose info.
Just for completeness auinfo, this also happens with tables when you use relative sizes eg width="100%" rather than a fixed size (pixels) eg width="600"
I'm trying to wrap my head around how you position pictures etc within those boxes-what are the boxes are they like cells in a table? Sorry but I thought I was getting it .
Does anyone know of a good book which explains EXACTLY how to do this for example Iv'e never heard of DIV and I still don't know how to use it!
Frustrated in Sydney!
Here's a few links, no1 is a good starting point, no2 and 3 are more advanced (but still very readable):
1) [brainjar.com...]
2) [alistapart.com...]
3) [glish.com...]
Basically you can position anything (text paragraphs, headers, images...) relative to the container it's in. This container, in turn, can be (examples) a <div>, a <td>, or even a <body>.
Here's a little funny image-css-thing [ooopps.sourceforge.net] in which an image is inside a div which can be turned invisible (using Javascript) - and this div is again inside another div which decides where on the page it (the other div+image) should be using positioning.
It's pretty advanced at first sight, but when you've been through some of the stuff on the links above you'll know what is happening position-wise (except for the javascript of course, but it's the postitioning that's important here)
/claus
surely EVERYONE will have a CSS compatible browser in 2003?
well, there's still some differences in how the different browsers will display your pages - even though they support CSS, in some areas they do it a little bit differently.
There's not 100% support for CSS but it's way over 95-98% afaik - there might be some differences for specialty/niche sites though.
/claus
So FOR NOW I'll stop annoyng you good people and settle down and work through the book.
I only asked the 'should I use tables question' expecting to have replies approving of my decision-instead after being advised to dabble with css its made me totally re think how to write web pages and hopefuly opened up big possibilities (Withouth using Flash or Java which I have a pet hate of). I honestly thoought css was only for formatting fonts!
I was going to use tables until I posted this but I am so glad I didn't now.
If anyone wants to take a look and comment I would appreciate it. the url is my name with a www before and .com after it.
it seems ok at 600x800 as well but our imac doesn't display one graphic for some reason and does some other strange things-I have seem this alot with macs though.
I brought two books- Eric Meyer on CSS ( Good for the fancy stuff but I needed another book to get me going properly(
Cascading Style Sheets By Example ( Stece Callihan-really excellent imo)
I noticed the z index can stop hyperlinks working if its set to a minus, had me puxxled for HOURS!