44 replies to this topic

[SlipStream]

I've been researching a ton and finding a lot of contradictory tutorials as to; which is better than this, that's better than these and don't use this use that. Quandry? that's an understatement! I now recognize that xhtml is the way to go as I have a basic understanding of its predecessor. The latest target practice is tables vs CSS. I have been checking the source on quite a few sites and I see that tables are in use everywhere. However, not being well versed in CSS, I am not sure if these are tables as I learned years ago in HTML, or, if they're CSS using table elements and attributes. What is the proper structure for a table, so to speak, in CSS? Maybe one of you can illuminate this for me. And, for a person just starting to get back into this, am I correct that xhtml is the best way to go with my limited knowledge. I would hate to spend another week practicing web page construction only to find that the sun is coming up from the south, not the east.

[Wit]

For SEO, it doesn't really matter (yet) if you use tables or css (or xhtml or html for that matter).

With tables it's easier to make dynamically resizing columns and stuff, but css-only code (using divs) is often cleaner and easier to maintain. Often, that code is a bit more compact (and the css file can be separate and cached so it doesn't have to be reloaded every time).

Same with xhtml. It has no direct SEO advantages over classic html, but the stricter your language of choice, the less likely you'll make a coding error that can choke some bots. A page does not NEED to be "valid" code, but you should at least TRY to validate it, to see if there's something terribly wrong with it....

[manager]

Howdy SlipStream, nice ta meetcha !

Since you seem to have had a gut full of theories allow me to use a simple analogy which I hope will serve to clarify some of the key concepts involved in the whole html / xhtml /css malarkey

Pretend you are a greengrocer and you sell apples, pears, and oranges.
You could simply chuck them all on a table in a disorganised mess, and save yourself some time. However this would not be appealing or convenient to your potential customers, for obvious reasons.

In reality you would separate the apples, pears, and oranges into separate boxes or containers. You might want to use different coloured containers of differing sizes to display your wares to the best effect.

Using my analogy
- The fruit is your content
- You use the html or xhtml to create your boxes or containers
- You would use CSS to specify how the containers would be presented, eg colour size, background image etc.

There is no debate on css v tables

To use my analogy, it’s about the type of containers you display your apples, pears and pears in, eg tables or divs

Don’t worry about the leap from html to xhtml; since you are familiar with html you just need to be aware of the differences. You can check out the differences here:

http://www.w3schools.../xhtml_html.asp

Hope this helps,
TreV

[A.N.Onym]

I have to disagree that CSS doesn't help SEO.
The code is cleaner and it makes crawling your site easier and puts the content higher in the page, which search engines value, as far as I know.

Most importantly, CSS helps you and your visitors.
CSS makes it possible to design user-friendly websites that load fast and are easy to maintain.

Here is a brief shot at why one needs to use CSS (there also is a link to how one can convert his site from tables to CSS, too)

As far as using tables and CSS together.
Clearly, you can move inline styles (<table align=right bgcolor=#ffffff>) to an external CSS style sheet (text-align:right;background:#fff;). This will reduce the webpage site a lot and will make it easy for you to adjust the site appearance. As it was said earlier, a website on CSS is much easier to edit just because the inside structure is much leaner.

Here is an example of how a properly structured table with CSS may look like:

<style>
.maintable {border:1px solid black;}
.row1 {background:#6cf;}
.row2 {background: #90f;}
.row1, .row2 {text-align:center;}
</style>

<table class="maintable">
<tr class="row1">
<td>John has</td>
<td>5 apples</td>
</tr>
<tr class="row2">
<td>Jane has</td>
<td>3 oranges</td>
</tr>
</table>

Disclaimer: this table lacks tags that are important for accessibility, like <caption>, <th>, etc. Just showing how tables are used with CSS here.

By the way. There is no debate 'tables vs CSS'. It is a matter of education, knowledge and skill. Of course there are sites that are on tables - they were designed years ago. Some of them may have been designed recently by designers who don't know how to write CSS. Of course, tables are to be used for tabular data (charts, etc) but not for the layout.

Edited by A.N.Onym, 25 April 2006 - 08:09 PM.

[stinhambo]

Oh CSS all the way. The only reason you see a lot of sites built with tables is either because the developers are too lazy to learn or (and this is most likely) the cost and time to retrain their staff is too high.

Learn CSS and you will be future proofing your skills.

[joedolson]

I don't think that "CSS vs tables" is the right path for discussion. CSS and tables are by no means exclusive! What needs to be looked at is the semantics of HTML code. That is, what the code you are using says about the content it surrounds.

A table says to a parser that "the data here is tabular data". This means that it is expected to have columns and rows, with a specific relationship between the data in the columns and the data in rows. When tables are used to design a site ("Layout tables") that correspondence between the meaning of the tag and its content is lost.

CSS is purely a design language - it has no bearing in and of itself on the meaning of the code it is effecting. But the choice of tags to surround your content should be given thought. If you consistently use "blockquote" to surround quoted blocks of text, for example, you can be confident that non-visual browsers can identify this as a quote (if necessary or relevant) and also that you can change the style of the blockquote without accidently changing some completely unrelated piece of the site where you just happened to use a blockquote. The same is true of tables or any other semantically designed code.

HTML should be used for the structure of the site, CSS for design. Tables, although perfectly valid for structuring tabular data, should not be used for design.

[Adrian]

Right, I'm typing this before reading the previous replies, so apologies if I go over something already mentioned

CSS Vs Tables.

What this is actually about, is positioning elements like <div>'s with CSS, or using tables for structure.

The tables re the same tables you learnt in HTML years ago, they haven't changed one bit.
CSS layout doesn't generally use tables, 'pure' CSS sites will use <Div>'s and things as the main containers, positioned and styled with CSS.
You do get a lot of 'hybrid' sites though, using an overall table or 2 for the main structure, possibly with CSS being applied to them for main styles, sometimes some HTML code for overall structure, then everything inside those couple of tables is styled and positioned with CSS.

An example of a hybrid I coded recently is http://blog.pcplus.co.uk
The template had to be relatively flexible, as it's to be used on other sites too, in this case, I decided to use one overall table for the main structure for consistancy, then all internal areas are styled with CSS.

Technically, using tables for layout is wrong, it's not what they were meant for, but lacking workable ways of creating anything other than a very plain design, they got used for laying pages in the grid like frameworks.

They work.

To a degree....

Most sites currenlty use tables, regardless of what any CSS advocate might say about CSS gaining popularity (and it is), tables are still far and away the most used method of page structure.

There are problems with both CSS layouts and table layouts. A badly coded CSS layout is not better than a well coded tbale layout. Argueably, a well coded CSS layout, is better than a well coded table layout though. Why? well, lets analyse the problems with tables...

Usually(bearing in mind how table sites are often coded, compared to a generally well coded CSS layout), table are more trouble to maintain and make alterations later on. They are generally less flexible, less accessible, and cause more code bloat.

I am not joking when I say I've striped out tables from code and turned 400 lines of into 40 by doing it with CSS.

I've been doing alterations to some older sites recently and I'm finding filtering through the table code a bit of a nightmare at times. On the other hand, I helped code a site at the start of the year, which we did in all CSS (not as nice SS as I would've liked...) and going back and making changes to that has been a lot easier.
Someone could argue that as I was involved in the build, I was just more familiar with the code I think there's more to it though

The thing with learning CSS is, and I see from elsewhere you've already picked up on it, is that you need to pretty much unlearn the HTML table approach, and look at it from a completely different point of view.
I've been doing that for a few years now, so it's become fairly 2nd nature, believe me, when you get used to it, it's a hell of a lot easier.

You have to forget how you might achieve soemthing in tables, and do it differently. I think a lot of peoples problems and frustrations with CSS invovle them trying to do exactly what they do in tables, in CSS. It just doesn't work like that.

On the side, I tend to think that learnign CSS and coding that way encourages better coding. Tables for layout is a hack in it's very essence, it gets the job done, that's about all.

Some people still argue CSS support is not good enough in browsers to rely on it.

That's rubbish. There is a hell of a lot you can do with CSS now in the real world, and has been for a few years. Yeah there are some fructrations, beware of implimenting lots of CSS hacks to get round quirks, as we've seen with IE7, they can come back and bite you in the donkey. there are going to be some hacks that people have used that will break in IE7. If you can avoid using hacks, all the better.

I'd certainly recommend you get to grips with CSS.
You'll end up with less code, that is lighter in terms of bandwidth, is easier to come back and update later, and is generally more accessible and performs better across different browsing devices.

[eron19]

xhtml + css.

thats how i do all my sites.

[Adrian]

I think Slipstream was after some reasoning, rather than a simple vote eron....

[manager]

Adrian,

Maybe like you, eron19 simply, typed his reply without reading the contributions of others.

Sorry but I thought that was rude, and I am glad you apologised, and yes you did repeat a lot of stuff.

TreV

[eron19]

use xhtml + css....

it promotes seperation of content and design...and plus...its xml compatible...

its newer and cleaner...

a table is for laying out tabular data....not for formating a web site.

ever seen a css web site with the styles off? well usually it lays out real nice...and is very readable. can you do that with your tables? i dont think so.

trust me when i tell ya...css+xhtml is the only way to go. thats why...like i said...i use it for all my sites.

Edited by eron19, 26 April 2006 - 04:30 PM.

[DaveChild]

CSS vs Tables ... ahh, the old argument.

Look at it like this. One technique involves building a house, using bricks for the outside, tiles for the roof, glass for the windows and paint to decorate. The other technique involves using mud and straw for everything. Both create a house of sorts, but one technique is going to create something more stable and sustainable.

What you've started with is a misunderstanding however, and that's what needs addressing first. You can't build a website "in css". It doesn't work like that. CSS is decorative - styling only. It's coats of paint, fancy trinkets and nice paintings. The question you are asking is - semantic markup vs hacked markup. Do you want to use the right material for the right job, or use the same material for everything. Use tables and font tags and next time you need to rebuild you'll need to tear everything down and start again. Building a site using HTML properly, and using CSS to style it, will give you great control and power, and will give structural meaning to the parts of your site.

As far as SEO goes - one technique or the other isn't going to get you to a top spot for a competitive keyword. Using HTML properly might just help a spider make more sense of your site, and that may help your positioning slightly, but the benefits in terms of accessibility and maintenance costs are far more important.

[Adrian]

Sorry but I thought that was rude, and I am glad you apologised, and yes you did repeat a lot of stuff.

I didn't have time during in my lunch break to read all the responses and then think about repsonding to Slipstream's intial questions, and addressing the resposnes, as it was I only just fit it in. And having gone over this topic many times before, I find it a lot easier to just state my case, and sum up the things I've learnt as a whole.
Skimming over the thread now, there's quite a lot I expanded on and explained in more detail, though from the sounds of it, you feel I added about as much value as eron's 1st posts.....

Coming back to the SEO aspect of using CSS, and whether it is of benefit or not....

Personally I don't think that a page built using CSS for positioning is any better than one built with tables generally. If you've got sloppy table code that is invalid, it could be possible that code is parsed incorrectly, but that's about it. The same could happen if you have badly coded div's all nciely styled in CSS....

If you use table layouts relatively semantically (I tend to think of semantics as using the right tag for the right job, so using tables for layout is never very semantic) by using hx tags well etc... then you could out perform a site positioned with CSS that's using CSS styles to make normal text look like headings (i.e. no using hx tags).

Let me repeat something I've said many times before, CSS positioned sites can be coded badly.
CSS positioned sites do not necessarily have good code that is better than something done in tables.

When people talk about advantages of CSS in SEO terms, they tend to say things like less/cleaner code, ability to have content first in a page, and other arguements that are mroe about HTML semantics than CSS.

Less/cleaner code: I just don't see that this makes much of a difference. The SE's will strip out a lot of if the HTML anyway. It may mean they can parse the code a bit quicker, but that has no bearing on whether your page is more relevant for a query or not.

The quality of the underlying code has no bearing on how relevant the content is to a particular query. As long as the engines can parse it and read it, it likely doesn't make much difference.

Ability to have content first in the code:
I'm still not convinced this has much bearing, I've seen a lot of comments about it, and if someone can point me to some proper tests and their results supporting it, I'll go along with it, but I've not seen it. I tend to think this is one of those SEO myths, something that sounds good, and makes acertain amount of sense, but perhaps isn't actually in effect.

Other arguements more about semantics:
People who get into using CSS fully, also tend to start looking into writing more semantic code in my experience. More semantic CAN have an effect, if code was previously fairly unsemantic.

That is, if before you weren't using things like h tags, and you change the code to start using things like that, it could well have an effect (how much is up for debate). But that's little to do with moving from tables for layout, to CSS for layout.

[bwelford]

Just picking up the XHTML side of the equation, I would thoroughly recommend going for coding according to XHTML Strict. I wish I did. However I now have a legacy of web pages that validate according to HTML 4.01 Transitional. It would be quite a spring-cleaning job to make all the changes.

One reason why I'm so emphatic is that I think Microsoft is now smelling the coffee. IE version 7 now in Beta renders XHMTL Strict according to standards. That we can all understand. Everything else will be rendered in the IE Quirks mode. What that is precisely probably noone knows in its entirety, although a few Microsoft types may be pretty good at that. The IE Quirks mode is what you've been trying to fit in the past. So your web pages will probably look the same. How long that will last is anyone's guess.

[Adrian]

I've not seen anything about IE7 and quriks mode specifically, but I thought they only went into quirks mode if you didn't have a full and valid DTD? Irrespective of what DTD that is.

I don't even use XHTML1.0 strict much. And besides which, I don't think IE7 is going to support serving XHTML as application/xml still? SO part of the reason for using XHTML is out of the window anyway....

[bwelford]

You may be right, Adrian. I thought I had read recently what I wrote but the best I can find from the IEBlog is the following:

To find a balance we introduced a strict mode in IE6 that lets authors opt in into the more standards compliant rendering (and, if you’re putting in a modern DOCTYPE declaration, you’re being opted in automatically). Pages authored under non-strict mode (or “quirks mode”) will not change behavior in IE7 – so the fixes we’ve done to be more CSS compliant won’t appear under quirks mode.

I'm not clear whether that only means that Strict versions of standards will be applied or that they will strictly handle even Transitional standards. Does anyone else have any more precision on this?

[DaveChild]

By "Strict", they mean simply adhering to standards and using a DTD, rather than "STRICT" as in DOCTYPEs. Transitional with a proper DTD, for the purposes of the above, comes under the strict heading.

[bwelford]

Thanks, ILJD, that's a relief - I think.

[bearmugs]

Pretend you are a greengrocer and you sell apples, pears, and oranges.

I'm shocked that TreV would discriminate this way. LOL
To mention apples, and not Windoze is pretty naughty.
Of course, it should go as follows.

Pretend you are a greengrocer and you sell apples, pears, oranges, and Windows.
You put all the stuff at the back of the room, reduce the price on the windows to an affordable price, and set them up so people trip over them when they walk in. "YOU BROKE IT YOU BOUGHT IT" policy is prominently displayed however, and the apples rot away at the back of the store. And by the way, did you notice this "greengrocer" doesn't sell anything green. The green reference is to money.

The way I see it anyway.
John EH!

Edited by bearmugs, 27 April 2006 - 09:57 AM.

[manager]

Oops Sorry Adrian !
I usually start off by writing down my true reactions and thoughts, then "tone them down" before posting. I made the mistake of hitting the Add reply button; instead of the preview post button, then I was too tired to edit my post, no offence intended.

I'm shocked that TreV would discriminate this way. LOL

I often discriminate against Chaff and Goats, in favour Wheat and Sheep. Thanks for your comments bearmugs

TreV