I miss my tables :( [Archive]

jagarco

11-21-2009, 06:55 AM

Mekhu

I've been designing with tables since 1999.

I'm gonna tell you one thing...

Do not, I repeat, do not start designing with CSS a semi-complex Web Site without knowing COMPLETELY how CSS works.
All its concepts, elements, rules, behaviors etc.

You have to STUDY at least a minimum of like 2 or 3 GOOD books about CSS, it'll take like 7-8 days. Do not practice the examples, just look at them, don't do nothing, just read and comprehend.
Sometimes you'll need to read again some chapters.

While you're at it, everything will start to fall in its place, you'll have ideas for how to achieve certain stuff.

I know there are tutorials, a lot of them, were you can create columns layouts and etc., but noup, it is necesarry to know everything from the begining, piece by piece.

I know also that it looks kind of easy to just put DIVs and borders, colors, backgrounds etc. and it motivates to start using them here and there, but doing this for a website with some elements without knowing the whole deal it just take you nowhere but to frustration and hating CSS.

I had A LOT of struggle to get the hang of tables for creating cool websites. Once I dominate it everything got easy.

But CSS is horribly more complex to learn.
Negative margins, Relative and absolut stuff, floats, display etc. But I do trust that it will help a lot once one can code with easy.

CSS is, actually, designing with numbers and letters, ugly stuff but that's how it is.

N1CK3RS0N

11-21-2009, 09:37 PM

I always use tables. Best way to keep things organized. I also use other block elements placed inside the tables as well.

I still don't get why some people want sites with "no tables". Kind of silly and pointless to me.

I had to work on some guys site where the people he paid to do his theme just floated a ton of divs all over the place and used strange padding which overlapped other div's and whatnot. Was so unnecessary. It actually has worse results, and takes longer, and is more complicated.

Sam [Vissol]

11-22-2009, 11:52 AM

It's perfectly acceptable to use tables for 'tabular data'.

Jamie Edwards

11-23-2009, 06:33 PM

I still don't get why some people want sites with "no tables". Kind of silly and pointless to me.
Because it is:

Hard to maintain in the future
Hard to read the code
Isn't easily changed
Is not accessible (i.e. does not gracefully degrade on mobile devices, blind people's screen readers etc)
It is not easily accessible to parsers (like search engines)
It is not future proof

I had to work on some guys site where the people he paid to do his theme just floated a ton of divs all over the place and used strange padding which overlapped other div's and whatnot.Then it was engineered badly - if HTML and CSS is not easy to understand and easy to (re)engineer, then it is a bad case of engineering. As is using tables to control the layout and positioning of everything on a regular website.

the_pm

11-23-2009, 06:43 PM

Then it was engineered badly - if HTML and CSS is not easy to understand and easy to (re)engineer, then it is a bad case of engineering. As is using tables to control the layout and positioning of everything on a regular website.Exactly - bad code is bad code, whether you use tables or not.

But when you use HTML elements properly, and you apply the logic necessary to do so in an efficient manner, there's simply no comparison between semantically valid (i.e. "tableless") site structure, versus table-based (discounting tabular data, of course). If you're still coding with tables, or worse, if you're just learning design and you're learning to use tables, you're going to find your skill set becoming obsolete very quickly. Present this markup to any serious design firm or respectable client, and you'll be shown the door.

You can push a nail into the wall using the flat part of a wrench, but if you try to tell a client or prospective employer that this is the proper way to drive a nail, you're going to be shown the door too. HTML is a tool - use it properly!

N1CK3RS0N

11-23-2009, 06:44 PM

Because it is:

Hard to maintain in the future
Hard to read the code
Isn't easily changed
Is not accessible (i.e. does not gracefully degrade on mobile devices, blind people's screen readers etc)
It is not easily accessible to parsers (like search engines)
It is not future proof

Then it was engineered badly - if HTML and CSS is not easy to understand and easy to (re)engineer, then it is a bad case of engineering. As is using tables to control the layout and positioning of everything on a regular website.

1. Hard to maintain? For amateurs maybe. I can organized anything using tables in seconds. People need to learn how to use colspan and rowspan. With that in mind, the possibilities are endless.

2. Again, hard to read? Maybe for amateurs. I tab and organize my coding very well. Its easy to read things and know where they are placed.

3. Makes no sense. Can be just as easily changed as div's. Quite possibly easier. Considering you don't have to fool around with floating and positioning.

4. Its every bit as accessible as div's... They are both block elements. The difference is div's display block, while tables td's display table-cell. Table cells align according to how the HTML says, as apposed to Div's breaking after each </div> unless you over ride with CSS. And even then you have to do positioning.

5. I wouldn't know about SEO, that really isn't my thing. But I would assume its every bit as capable as div's. Saying as Search Engines mainly run based off meta tags and the content itself, not the way the content is coded.

6. Nothing is future proof.

N1CK3RS0N

11-23-2009, 06:48 PM

Exactly - bad code is bad code, whether you use tables or not.

But when you use HTML elements properly, and you apply the logic necessary to do so in an efficient manner, there's simply no comparison between semantically valid (i.e. "tableless") site structure, versus table-based (discounting tabular data, of course). If you're still coding with tables, or worse, if you're just learning design and you're learning to use tables, you're going to find your skill set becoming obsolete very quickly. Present this markup to any serious design firm or respectable client, and you'll be shown the door.

You can push a nail into the wall using the flat part of a wrench, but if you try to tell a client or prospective employer that this is the proper way to drive a nail, you're going to be shown the door too. HTML is a tool - use it properly!

Give me an example as to where the use of a table wouldn't be optimal as compared to a div.

HTML is NOT a tool. It is an art. Everyone has their own style and own way of going about doing things. Whether or not you agree with the methods or styles another person uses, that is an opinion, not a fact.

To the trained person, tables are easier to organize, easier to maintain and just function better than floating and positioning div's. Not to mention the coding isn't as organized as some times you will have a div placed above another in the code, yet it displays after it.

the_pm

11-23-2009, 11:46 PM

Give me an example as to where the use of a table wouldn't be optimal as compared to a div.

HTML is NOT a tool. It is an art. Everyone has their own style and own way of going about doing things. Whether or not you agree with the methods or styles another person uses, that is an opinion, not a fact.

To the trained person, tables are easier to organize, easier to maintain and just function better than floating and positioning div's. Not to mention the coding isn't as organized as some times you will have a div placed above another in the code, yet it displays after it.I gave an example earlier in the thread - switching the order of columns in your markup without shifting their position on the page, without introducing any element breakage into a complex layout.

Sorry, HTML is not an art - it is a science, a standardized coding platform that is written by coders and interpreted by another standardized technology - browsers. From a visual perspective, the art is in the design. There certainly is artistry involved in finding ways to code more efficiently, but if you're practicing this sort of art, it's already assumed you've dropped tables in favor of leaner, more efficient markup. In basic terms, if you want to create a simple container using a table, you have to declare a minimum of three open/close tags, and only then do you get to put other objects in that space. Want to layer styles? Nest more tables. It's so grossly inefficient, the artist side of me cringes at the thought of pushing all that unnecessary code into place.

Luckily, in traditional browsing environments, using tables versus more efficient markup has little affect on most people's browsing experience. When you go beyond the traditional computer/browser, that's when things get a little testy, but regardless, why create the extra markup? I posted the results of a proof-of-concept on Digital point a few years back, where we figured out we could save a particular corporation $1.2 million per year by just recoding their intranet (here's a link to the post (http://forums.digitalpoint.com/showpost.php?p=683429&postcount=23). The design was fairly complex, and the design company that did it (back in 2002, to be fair), used tables. To do what they needed to do, the complexity of the tables used was necessary. Doing it without made a tremendous impact on time and costs.

Then there was a site maintained by another developer who frequents WHT that was struggling to take itself to the next level in search engines. We asked the site owner to authorize a complete site overhaul - removing the table-based layout in favor of semantically valid markup, while maintaining the exact same site look. The difference in SEO rankings was significant, as much as a full page maintained increase in rankings for each search term of importance. This is a story I've seen play out and had the pleasure of being involved in many, many times. I can't really go into much more detail, since there are rules about self-promotion, but most people who have been involved in search engine marketing and optimization understand the benefits of using proper markup for layout, having had similar experiences.

If you want to participate in a fun exercise, go to Monster.com (or the job site of your choice), find openings for experienced designers, and count the number that will not accept applications unless you are able to use semantically valid markup. I'll do this from time to time, and it's usually somewhere between 40-60%. The rest simply don't make mention one way or another. However there isn't a single job opening I've seen in the past five years looking for an expert in tables.

If you took the time to really learn semantic markup, if you committed yourself to becoming an expert in it, you'd do what everyone who makes that commitment does - you'd wonder how you ever thought it was acceptable to use tables for layouts. I've ventured quite far down both paths, and having spoken as an advocate for the use of tables myself years ago, I've experienced the transition first-hand. Once you "get it," there's no going back :)

N1CK3RS0N

11-24-2009, 01:38 AM

I gave an example earlier in the thread - switching the order of columns in your markup without shifting their position on the page, without introducing any element breakage into a complex layout.

Yes... and 1 single highlight/copy/paste will not shift the column?

Sorry, HTML is not an art - it is a science, a standardized coding platform that is written by coders and interpreted by another standardized technology - browsers. From a visual perspective, the art is in the design. There certainly is artistry involved in finding ways to code more efficiently, but if you're practicing this sort of art, it's already assumed you've dropped tables in favor of leaner, more efficient markup. In basic terms, if you want to create a simple container using a table, you have to declare a minimum of three open/close tags, and only then do you get to put other objects in that space. Want to layer styles? Nest more tables. It's so grossly inefficient, the artist side of me cringes at the thought of pushing all that unnecessary code into place.

Interesting... first HTML is a "tool" now its a "science"? ^^ Get your story straight then come back and let us know.

Luckily, in traditional browsing environments, using tables versus more efficient markup has little affect on most people's browsing experience. When you go beyond the traditional computer/browser, that's when things get a little testy, but regardless, why create the extra markup? I posted the results of a proof-of-concept on Digital point a few years back, where we figured out we could save a particular corporation $1.2 million per year by just recoding their intranet (here's a link to the post (http://forums.digitalpoint.com/showpost.php?p=683429&postcount=23). The design was fairly complex, and the design company that did it (back in 2002, to be fair), used tables. To do what they needed to do, the complexity of the tables used was necessary. Doing it without made a tremendous impact on time and costs.

What you don't seem to get is if you know HOW to use tables properly, its less time consuming the aligning and positioning div's. Div's are not a more "efficient" markup. They have their own use. There's actually less markup needed than positioning div's.

The post you provided seems to be a lot of "theory" but doesn't necessarily mean any of it is true. Not to mention as I already stated, if you know how to use tables properly it is less complicated than positioning and aligning div's with extra CSS elements for each div.

Then there was a site maintained by another developer who frequents WHT that was struggling to take itself to the next level in search engines. We asked the site owner to authorize a complete site overhaul - removing the table-based layout in favor of semantically valid markup, while maintaining the exact same site look. The difference in SEO rankings was significant, as much as a full page maintained increase in rankings for each search term of importance. This is a story I've seen play out and had the pleasure of being involved in many, many times. I can't really go into much more detail, since there are rules about self-promotion, but most people who have been involved in search engine marketing and optimization understand the benefits of using proper markup for layout, having had similar experiences.

So tables are "improper" markup now? Let me know when they remove tables from HTML coding. Then I'll believe you. As for now, there's no reason why using div's in every situation rather than tables would have any impact on search engine results. Tables and div's each have their own specific use.

If anything I'd consider floating and positioning div's less "proper" than using a simple table to organize the structure of a design.

If you want to participate in a fun exercise, go to Monster.com (or the job site of your choice), find openings for experienced designers, and count the number that will not accept applications unless you are able to use semantically valid markup. I'll do this from time to time, and it's usually somewhere between 40-60%. The rest simply don't make mention one way or another. However there isn't a single job opening I've seen in the past five years looking for an expert in tables.

http://weblogs.asp.net/alessandro/archive/2008/01/07/semantically-correct-markup-and-the-casual-table-can-they-co-exist.aspx

Read it.

If you took the time to really learn semantic markup, if you committed yourself to becoming an expert in it, you'd do what everyone who makes that commitment does - you'd wonder how you ever thought it was acceptable to use tables for layouts. I've ventured quite far down both paths, and having spoken as an advocate for the use of tables myself years ago, I've experienced the transition first-hand. Once you "get it," there's no going back

Nay, I understand the whole concept of so called "semantic markup", and I don't fully agree.

Basically what semantics mean is using a particular element of HTML for what it is intended to be used as. I kind of find it ironic when floating and positioning div's with CSS is considered "how they were intended to be used" when you have to over write any default CSS value that they have. Everything has its own use.

By the way, when you say "if you committed yourself to becoming an expert in it, you'd do what everyone who makes that commitment does"... by "do what everyone who makes that commitment does" do you mean act superior to others because you consider that there is 1 way and only 1 way of coding?

Its more than acceptable to use tables for layouts. Neither you or anyone else has proven to me why the use of a table to organize the structure of content is a "bad practice".

What I do 'get' is like anything, web design has its trends. If you want to not use any table at all for no reason what-so-ever by all means, be my guest, I'm sure it will earn you some cool kid points in the books of others who share the same point of view.

People are always trying to find means to prove superiority over others... Welcome to the internet.

N1CK3RS0N

11-24-2009, 02:01 AM

Now, the outlying structure of the site is where tables are not meant to be, but if you're only talking about particular pages of your site, then I must assume you're talking about the main content area, not these pages in their entirety, right?

HAHAHA. Wow...

Please send me your copy of "proper uses of HTML", I'd love to see where the developers of HTML say you should not use a table for the structure of your design.

Foolish statement.

Jamie Edwards

11-24-2009, 05:35 AM

HAHAHA. Wow...

Please send me your copy of "proper uses of HTML", I'd love to see where the developers of HTML say you should not use a table for the structure of your design.

Foolish statement.
:D

http://www.w3.org/TR/WCAG10/

Mark up documents with the proper structural elements.

Control presentation with style sheets rather than with presentation elements and attributes. Using markup improperly -- not according to specification -- hinders accessibility. Misusing markup for a presentation effect (e.g., using a table for layout or a header to change the font size) makes it difficult for users with specialized software to understand the organization of the page or to navigate through it.

Content developers may be tempted to use (or misuse) constructs that achieve a desired formatting effect on older browsers. They must be aware that these practices cause accessibility problems and must consider whether the formatting effect is so critical as to warrant making the document inaccessible to some users.

At the other extreme, content developers must not sacrifice appropriate markup because a certain browser or assistive technology does not process it correctly. For example, it is appropriate to use the TABLE element in HTML to mark up tabular information (http://www.w3.org/TR/WCAG10/#tabular-information) even though some older screen readers may not handle side-by-side text correctly (refer to checkpoint 10.3 (http://www.w3.org/TR/WCAG10/#tech-linear-tables)). Using TABLE correctly and creating tables that transform gracefully (refer to guideline 5 (http://www.w3.org/TR/WCAG10/#gl-table-markup)) makes it possible for software to render tables other than as two-dimensional grids.
Ensure that tables have necessary markup to be transformed by accessible browsers and other user agents.

Tables should be used to mark up truly tabular information (http://www.w3.org/TR/WCAG10/#tabular-information) ("data tables"). Content developers should avoid using them to lay out pages ("layout tables"). Tables for any use also present special problems to users of screen readers (http://www.w3.org/TR/WCAG10/#screen-reader) (refer to checkpoint 10.3 (http://www.w3.org/TR/WCAG10/#tech-linear-tables)).
And from the actual HTML specification (http://www.w3.org/TR/html4/struct/tables.html#h-11.1): (http://www.w3.org/TR/html4/struct/tables.html#h-11.1%29:)
Tables should not be used purely as a means to layout document content as this may present problems when rendering to non-visual media. Additionally, when used with graphics, these tables may force users to scroll horizontally to view a table designed on a system with a larger display. To minimize these problems, authors should use style sheets (http://www.w3.org/TR/html4/present/styles.html) to control layout rather than tables.

Its more than acceptable to use tables for layouts. Neither you or anyone else has proven to me why the use of a table to organize the structure of content is a "bad practice".
Here is some lighter (but ever true) reading: http://www.hotdesign.com/seybold/everything.html http://phrogz.net/css/WhyTablesAreBadForLayout.html and http://stackoverflow.com/questions/83073/why-not-use-tables-for-layout-in-html

AlbaG

11-24-2009, 06:02 AM

Hi,

I wonder how the no-table guys here would solve display of a pedigree. So far the only feasible solution I found was a rather much worked table, with loads of merged cells.

I especially wonder about accessibility regarding that topic, I've managed a CSS simili, but the code was even more bloated than the table and whether the divs display in a more logical manner than the table cells is the question.

So, what do the two fronts here say on such a juicy morsel?

Jamie Edwards

11-24-2009, 06:07 AM

I wonder how the no-table guys here would solve display of a pedigree.
I'm not quite sure what you mean by "display of a pedigree"..

I especially wonder about accessibility regarding that topic, I've managed a CSS simili, but the code was even more bloated than the table and whether the divs display in a more logical manner than the table cells is the question.
If your CSS and HTML is bloated, then it hasn't been engineered properly - either by a bad approach, a bad coder or a combination of the two.

AlbaG

11-24-2009, 06:24 AM

RemyHorton

11-24-2009, 06:31 AM

The problem CSS had was MSIE6's notoriously broken support. If correctness and compatibility were goals, the "misuse" of tables for layout ended up being a lesser sin overall.

Jamie Edwards

11-24-2009, 06:43 AM

Hi,

this is a pedigree (mark: I'm not related to that page, just grabbed the first which came up on google):

http://www.mojito-goldens.de/jeany/pedigree/

It's a short one, those for humans can go for 5 or 6 generations, juggling with 64 or 128 table cells.
This is a good use of tables - using tables to display tabular data.

The "no-table" crowd aren't gunning for the abolishment of the TABLE element. They are campaigning for the proper use of tables, as defined by the HTML specification.

AlbaG

11-24-2009, 06:47 AM

Hi,

well, the question was how accessible a table for a pedigree is over/less than CSS. The data per se are not necessarily tabular, though the table is the one form which is easiest to implement, even if getting quite convoluted with more generations.

BTW - I sent you a PM regarding some administrative matter :-)

the_pm

11-24-2009, 11:10 AM

HAHAHA. Wow...

Please send me your copy of "proper uses of HTML", I'd love to see where the developers of HTML say you should not use a table for the structure of your design.

Foolish statement.

:D

http://www.w3.org/TR/WCAG10/

And from the actual HTML specification (http://www.w3.org/TR/html4/struct/tables.html#h-11.1): (http://www.w3.org/TR/html4/struct/tables.html#h-11.1%29:)

Here is some lighter (but ever true) reading: http://www.hotdesign.com/seybold/everything.html http://phrogz.net/css/WhyTablesAreBadForLayout.html and http://stackoverflow.com/questions/83073/why-not-use-tables-for-layout-in-html

To that, you can add the WCAG work that's taking place now on the v.2.0 for that documentation: http://www.w3.org/TR/WCAG20/ - they're currently preparing a section on CSS for layout rather than using tables and the failure points associated with the incorrect use of tables as layout devices.

Everything we've been debating within this thread is codified, substantiated and put into professional practice as a standard, and all the arguments for or against tables for layout are moot, because the industry recognizes this as a bad practice as a whole. You'll look back on this thread one day, and you'll laugh at how misguided your "foolish statement" sentiment really was, when you realize just how applicable it is to your own position.

What strikes me as being most endearing about all of this is that six or seven years ago, I was you, and I totally understand why you believe you have everything figured out. :) I'm curious, did this philosophy of yours regarding tables for layout come from college/university study? I had to unlearn a lot of what I was taught in the late 90s and early 2000s, and I'm curious whether our higher educational system has caught up with the times or whether it's still lagging. Back when I was in school, tables were the only thing that was taught, because CSS was relatively new and browser support was just starting to emerge. It wouldn't surprise me in the least if academic theory regarding layout techniques is still stuck in those dark ages.

The problem CSS had was MSIE6's notoriously broken support. If correctness and compatibility were goals, the "misuse" of tables for layout ended up being a lesser sin overall. IE6 is actually pretty easy to handle, with just a few very basic techniques. I won't cry when the day comes that IE6 is eradicated, but it's really not as bad to work with as some people think.

Netscape 4.x was by far the worst, because it was a popular browser during the time CSS was really taking off, and it offered odious support for CSS specifications. IE5, IE5.5 and IE 5.2 Mac weren't exactly a picnic, but we're definitely at the point where in all but the most specific circumstances, we no longer need to account for these.

N1CK3RS0N

11-24-2009, 02:50 PM

This is a good use of tables - using tables to display tabular data.

The "no-table" crowd aren't gunning for the abolishment of the TABLE element. They are campaigning for the proper use of tables, as defined by the HTML specification.

What exactly is the difference from that example of "tabular data" and an actual design that would use a similar layout?

Tables were meant to be used to organize... You can use it as fit. In most cases its better than using div's for layouts.

The only HTML specifications there are, are definitions by third parties such as yourself and w3.org.

N1CK3RS0N

11-24-2009, 02:57 PM

To that, you can add the WCAG work that's taking place now on the v.2.0 for that documentation: http://www.w3.org/TR/WCAG20/ - they're currently preparing a section on CSS for layout rather than using tables and the failure points associated with the incorrect use of tables as layout devices.

Everything we've been debating within this thread is codified, substantiated and put into professional practice as a standard, and all the arguments for or against tables for layout are moot, because the industry recognizes this as a bad practice as a whole. You'll look back on this thread one day, and you'll laugh at how misguided your "foolish statement" sentiment really was, when you realize just how applicable it is to your own position.

What strikes me as being most endearing about all of this is that six or seven years ago, I was you, and I totally understand why you believe you have everything figured out. :) I'm curious, did this philosophy of yours regarding tables for layout come from college/university study? I had to unlearn a lot of what I was taught in the late 90s and early 2000s, and I'm curious whether our higher educational system has caught up with the times or whether it's still lagging. Back when I was in school, tables were the only thing that was taught, because CSS was relatively new and browser support was just starting to emerge. It wouldn't surprise me in the least if academic theory regarding layout techniques is still stuck in those dark ages.

IE6 is actually pretty easy to handle, with just a few very basic techniques. I won't cry when the day comes that IE6 is eradicated, but it's really not as bad to work with as some people think.

Netscape 4.x was by far the worst, because it was a popular browser during the time CSS was really taking off, and it offered odious support for CSS specifications. IE5, IE5.5 and IE 5.2 Mac weren't exactly a picnic, but we're definitely at the point where in all but the most specific circumstances, we no longer need to account for these.

Don't think so. It seems as if I've been doing web design as long as you have, and I have known of "semantic valid markup" just as long. I don't agree with the whole concept, and I certainly don't agree with the smug attitude of people who think it is the only "valid" way of coding. Who gets to decide wrong from right? You? Me?

Tables weren't "made" just to display data. If so 99% of the web has that wrong and your part of the 1% who has it right. Numbers are against you.

Its easier to organize than div's, its less work and it works better. Nothing else can be said.

Jamie Edwards

11-24-2009, 03:06 PM

The only HTML specifications there are, are definitions by third parties such as yourself and w3.org.
w3 define HTML standards, including this one. What more authority do you want!? :D

Jamie Edwards

11-24-2009, 03:07 PM

Its easier to organize than div's, its less work and it works better. Nothing else can be said.
The only people who find using tables easier are, in my experience, inexperienced and not very good HTML/CSS coders. If the HTML and CSS doesn't flow and is not more manageable, you're doing it incorrectly.

N1CK3RS0N

11-24-2009, 03:11 PM

w3 define HTML standards, including this one. What more authority do you want!? :D

Cool. I'm starting a community right now that defines the standards of companies who can define standards.

Sorry to say W3 isn't on the list.... bummer dude.

N1CK3RS0N

11-24-2009, 03:14 PM

The only people who find using tables easier are, in my experience, inexperienced and not very good HTML/CSS coders. If the HTML and CSS doesn't flow and is not more manageable, you're doing it incorrectly.

Or the opposite. People who don't know how to use tables properly don't know that its easier and superior to using div's for content structure.

See how easy it is to throw bs out there. :D

Again. Enough with the smug attitude.

the_pm

11-24-2009, 04:19 PM

I certainly don't agree with the smug attitudeEverything was roses until you decided I was foolish for making a perfectly factual statement regarding the availability of an industry standard for how markup should be used.

Ok, so it turns out that statement wasn't so foolish, was it? Now can you see that maybe there's something new for you to learn and you have something to study and investigate further, or do you still believe we don't know what we're talking about?

Who gets to decide wrong from right? You? Me?Neither of us. The ones who get to decide are the organization that stewards the specifications, and the browser manufacturers who have all uniformly pledged to uphold them. And we're not just talking about IE, Firefox, Opera, Chrome and Safari (the traditional browsers), we're talking about Lynx, Blazer, JAWS (a vocal interpreter for users with visual impairments), Opera Mini and others who play in the fast-growing field of non-traditional computing. And yes, even Microsoft is fully on-board with standards, and have been so for the better part of this decade.

We don't get to decide who's right and who's wrong. We just decide if we're going to support what the industry has committed itself to supporting or not. I'm not telling you that you're wrong. W3C is telling you that you're wrong, as are the higher-level technology companies that create the software that display what we make. Most of them are willing to support both "right" and "wrong" techniques, and will probably do so for the foreseeable future (though some cannot support the "wrong" way, because the nature of using markup in an unintended way cannot be supported in many non-traditional browsing environments). But their willingness to do so should not be viewed as an endorsement of such techniques.

For your reference, the idea of using tables for layout is generally credited to one man, David Siegel, who shortly thereafter expressed great remorse for having done so, after he saw that his idea was actually catching on. I talked about this a couple years ago in a similar discussion (http://www.webhostingtalk.com/showpost.php?p=4420757&postcount=10). For more information on the history behind this mistake, enjoy this article (http://www.westciv.com/style_master/house/good_oil/dead_layout/index.html) written on westciv.com, as authoritative a resource as you're going to find on the subject of Web design and development.

Tables weren't "made" just to display data. If so 99% of the web has that wrong and your part of the 1% who has it right. Numbers are against you.We've been kind enough to give numbers and reference our sources. Please return the favor and cite your references! Please provide a credible reference that supports your assertion that 99% of all pages on the Web utilize tables for the structuring of their layout.

Its easier to organize than div's, its less work and it works better.So far we've cited plenty of sources that expound on the exact reasons why this isn't the case. We've introduced you to the standards for Web Accessibility that until today you didn't know existed. We've given examples of measurable cost and time savings associated with designing in a semantically valid manner, and I'm certainly not the only one who has reams of data regarding positive search engine impact associated with creating properly structured HTML documents.

You asked for evidence tables are not optimal for layout design. We gave you hard numbers, facts and links to source. You said we were foolish for believing there was a standard for use of markup. We gave you links to multiple documents and quoted sources that showed our statements to be true. You said you have no idea what the SEO implications of semantic validity were. I shared information that directly addressed this point, in order to educate you in this regard.

We're sharing resources from the highest authorities as well as articles and theory from many independent and well respected individuals and organizations across the industry. We've been very accommodating with your demands that we back up our points with examples, facts and references. Could you please do the same in return?

Cool. I'm starting a community right now that defines the standards of companies who can define standards.

Sorry to say W3 isn't on the list.... bummer dude.If you don't like the standards, you'll go write your own? You're welcome to do that. You won't be the first to try, and if you succeed in capitulating the powers-that-be, I'll be happy to adapt to this new way of doing things.

For what it's worth, Ian Hickson, the man in charge of creating the specifications for HTML5, was going to do something similar with the invention of predefined classes. He and I exchanged a number of emails about the matter. He was very gracious with his perspective, and we debated the merits (and demerits) of such a system. It turns out he ended up agreeing (http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-May/011343.html) with me (and many others who believed this as well), and he removed predefined classes from his specification (to reiterate, this was influenced by many discussions with industry peers - I'm not taking credit, just relaying my experience). But if he had opted not to do so, and the specification was approved with them, then the industry would adapt. As it stands, it's possible we'll all be adapting to new tags and ways of using them within the next 5-10 years anyway. I'm looking forward to the progress, even if I don't entirely agree with everything Ian codified in the HTML5 spec.

Coincidentally, the first time I made this type of transition was when I went from tables to non-tables. I was a little more resistant at that time, but having gone through the process, I'm in a much better frame of mind to add HTML5 to my arsenal in the future!

Ramprage

11-24-2009, 04:54 PM

haha jeff a lot has changed since the glory days!

Try to only use tables for tabular data. So if it doesn't fit in an excel sheet it shouldn't be in a table.

The worst 2 browsers to get things working in are IE6 and 7. They are just the bain of web development. You can use CSS conditionals so only IE6.css is loaded for *fixes* so the page renders properly. This is pretty much the common practice.

the_pm

11-24-2009, 05:56 PM

Yes... and 1 single highlight/copy/paste will not shift the column?With tables, it will shift both the markup and the actual position of that column on the site. What technique do you use with tables that allows you to do only one of those things, without altering the look of the site in any way?

By the way, when you say "if you committed yourself to becoming an expert in it, you'd do what everyone who makes that commitment does"... by "do what everyone who makes that commitment does" do you mean act superior to others because you consider that there is 1 way and only 1 way of coding?Not at all. I'm simply making a prediction that if you made the commitment to learn semantic validity as it relates to page layout, if you really learned it at the expert level, I think you'd view your own position differently. That's all.

See, I've been in both positions, argued vehemently for both, coded plenty of sites in both styles and expounded on the virtues of both, committing myself to learning both methods with an expert level of understand along the way (tables first, and later tableless), for better or for worse, it is what it is. My understanding up to this point is that you are intimately familiar with the use of tables, and not as experienced with the use of tableless layout markup, and I wonder if you're making a fair comparison between the two without the same level of knowledge in each. As a simple statement of fact, I've never met someone who was expertly proficient in tableless design who wasn't also familiar with the Web Content Accessibility Guidelines Jamie posted. Having introduced you to these guidelines for the first time today leads me to believe you may not have pursued the same level of understanding and proficiency with both tables and non-tables to be able to compare them fairly.

There's nothing wrong with that. There's a TON of stuff about the Web design industry I don't fully understand, that I cannot and probably will not ever be able to call myself an expert in. By the same token, I won't argue for or against those things, or if I do enter into discussion, I'm going to do so in such a way that I'm open to learning more about what I'm debating. After all, it's this attitude that propelled me to learn how to be a practitioner of both table and non-tables sites.

Give the various links we've peppered through this thread a good read, and consider taking semantic validity more seriously. Again, as a practitioner of both sides, I can tell you from experience it's worth the effort to learn, and I don't think you'll go back once you do!

N1CK3RS0N

11-24-2009, 08:21 PM

With tables, it will shift both the markup and the actual position of that column on the site. What technique do you use with tables that allows you to do only one of those things, without altering the look of the site in any way?

Why would you want the coding to not match the way the website is displayed?...

Kinda stupid. And that's thought of as a "benefit"?...

Not at all. I'm simply making a prediction that if you made the commitment to learn semantic validity as it relates to page layout, if you really learned it at the expert level, I think you'd view your own position differently. That's all.

I know it just fine, the argument doesn't make sense, and neither do the reason people justify for using it other than they can.

See, I've been in both positions, argued vehemently for both, coded plenty of sites in both styles and expounded on the virtues of both, committing myself to learning both methods with an expert level of understand along the way (tables first, and later tableless), for better or for worse, it is what it is. My understanding up to this point is that you are intimately familiar with the use of tables, and not as experienced with the use of tableless layout markup, and I wonder if you're making a fair comparison between the two without the same level of knowledge in each. As a simple statement of fact, I've never met someone who was expertly proficient in tableless design who wasn't also familiar with the Web Content Accessibility Guidelines Jamie posted. Having introduced you to these guidelines for the first time today leads me to believe you may not have pursued the same level of understanding and proficiency with both tables and non-tables to be able to compare them fairly.

One again, assumptions. And they are wrong.

There really isn't anything to tableless design. Its just using div's with CSS to position them. Not rocket science. Yet not as simple as a clean organized table.

There's nothing wrong with that. There's a TON of stuff about the Web design industry I don't fully understand, that I cannot and probably will not ever be able to call myself an expert in. By the same token, I won't argue for or against those things, or if I do enter into discussion, I'm going to do so in such a way that I'm open to learning more about what I'm debating. After all, it's this attitude that propelled me to learn how to be a practitioner of both table and non-tables sites.

So basically you learned tableless design so you could "fit in". Sounds like... highschool...

Give the various links we've peppered through this thread a good read, and consider taking semantic validity more seriously. Again, as a practitioner of both sides, I can tell you from experience it's worth the effort to learn, and I don't think you'll go back once you do!

I already know it... Have you been reading..? You're assuming 100% of people who know both style will only like tableless design. Tables are easier to use, better organized, easier to code, takes less time, functions better. That's enough reason for me to use tables as apposed to tableless because its "semantically valid".

Jamie Edwards

11-24-2009, 08:26 PM

Why would you want the coding to not match the way the website is displayed?...
So that you don't need to delve into HTML to make major layout and repositioning changes, and do so repeatedly across all of your pages. Instead, you just have to tweak a few CSS classes.

N1CK3RS0N

11-24-2009, 08:35 PM

So that you don't need to delve into HTML to make major layout and repositioning changes, and do so repeatedly across all of your pages. Instead, you just have to tweak a few CSS classes.

If you know how to do table design "properly" you wouldn't have to make "multiple" changes. One change will suffice. Not to mention the whole scenario doesn't happen often, not for me at least. Don't know if you often layout something incorrectly the first time or whatever.

the_pm

11-24-2009, 08:40 PM

Why would you want the coding to not match the way the website is displayed?...

Kinda stupid. And that's thought of as a "benefit"?...Let's look at what you think is stupid. You have two columns - one has your site's content, and the other has your sidebar. Let's say during the evolution of your site, you decide you want to put helpful tips into the sidebar, and these tips have lots of great keywords that relate to your site, and a different one randomly displays on every page load.

For maximum search engine benefit, you decide you want to switch the position of the sidebar and your content area within your markup, so that an element that displays constantly changing, keyword-dense content is given higher priority within the page. But you don't want to affect the visual look of your site in doing so - you don't want to physically swap the position of your content and sidebar.

Because they're floating next to each other, you can swap them in your markup without affecting the look of your site, and you don't even have to make a change to your CSS document! Of course if you wanted to change their positions, you could just swap left/right within your CSS, and never touch your markup. This both has real-world benefit, and it is fast and efficient, and it is the use of markup in accordance with WGAC that makes it possible to do things like this with your sites down the road.

It's unfortunate you decide anything that doesn't fall into your immediate knowledge set is "kinda stupid" before you take the time to understand it. There's a lot to learn here if you're willing to do so...

So basically you learned tableless design so you could "fit in". Sounds like... highschool...What in God's name are you talking about? I decided to round out my education, learn more about my industry, and...high school...what?

Again, we've presented facts, figures, real life results and sources/references. Try to keep on track and make this a meaningful debate please.

vito

11-25-2009, 12:10 AM

Quite an interesting thread thus far. :)
Then there was a site maintained by another developer who frequents WHT that was struggling to take itself to the next level in search engines. We asked the site owner to authorize a complete site overhaul - removing the table-based layout in favor of semantically valid markup, while maintaining the exact same site look. The difference in SEO rankings was significant, as much as a full page maintained increase in rankings for each search term of importance. This is a story I've seen play out and had the pleasure of being involved in many, many times. I can't really go into much more detail, since there are rules about self-promotion, but most people who have been involved in search engine marketing and optimization understand the benefits of using proper markup for layout, having had similar experiences.
Paul is referring to me. I have a local design client with a very successful retail site that I built 7 years ago and have been updating/maintaining it for him ever since. We decided to do some SEO work on the site. Part of the project included recoding the site, which is where Paul (the_pm) came in.

Before recoding it, my client would be around position 15 in a google search for most of his important keyword searches. Paul recoded the site, and immediately after Google revisited the site, my client enjoyed a fantastic boost up to position 2 or 3 in most of the various keyword searches. Amazing improvement. (And let me say parenthetically that it takes a LOT more to go from 15 to 2, than it does to go from 100 to 15). Needless to say, my client was absolutely thrilled with the results, and he is now enjoying much more organic traffic to his site.

Let's compare just one page to see the difference - the home page. Before recoding, I had the site completely built with tables. And I had a bunch of JS code in the <head> section. So when you would visit the home page and click to View Page Source, it would take 2 or 3 page scrolls to finally see actual content. Move forward to after Paul's recoding. Now, when I click to View Page Source, keyword rich content is visible half way down the first screen, no scrolling required. Right there, up front and center. All because of more efficient coding. Here is another illustration of how efficient his code is. Pre-Paul, the home page was 25 KB. Post-Paul, it went down to a staggering 5 KB. Absolutely amazing.
Let's look at what you think is stupid. You have two columns - one has your site's content, and the other has your sidebar. Let's say during the evolution of your site, you decide you want to put helpful tips into the sidebar, and these tips have lots of great keywords that relate to your site, and a different one randomly displays on every page load.

For maximum search engine benefit, you decide you want to switch the position of the sidebar and your content area within your markup, so that an element that displays constantly changing, keyword-dense content is given higher priority within the page. But you don't want to affect the visual look of your site in doing so - you don't want to physically swap the position of your content and sidebar.

Because they're floating next to each other, you can swap them in your markup without affecting the look of your site, and you don't even have to make a change to your CSS document! Of course if you wanted to change their positions, you could just swap left/right within your CSS, and never touch your markup. This both has real-world benefit, and it is fast and efficient, and it is the use of markup in accordance with WGAC that makes it possible to do things like this with your sites down the road.
Do not under-estimate the importance of this. Properly coded, you are able to push all your keyword-rich content up very high in the source code. Invaluable. Does not affect the display of the page, but does wonders for SEO.

As far as I'm concerned, Paul is brilliant. And let me also say that over the past few years, in spite of his encouragement to learn CSS, I have been totally resistant to "crossing over to the other side". I have been a "table" guy for many years. But the more I am exposed to Paul's work, the more I am convinced that there are better ways to code a site.

Vito

N1CK3RS0N

11-25-2009, 04:29 PM

It's unfortunate you decide anything that doesn't fall into your immediate knowledge set is "kinda stupid" before you take the time to understand it. There's a lot to learn here if you're willing to do so...

Once again, wrong. Once again, I understand tableless design and "semantic valid" design. Once again, why would you want to switch the order of your coding to not match your website? It has no effect on search engine results the way content is listed in the coding.

Since no one else other than you and Jamie are involved here I'm done. Its like arguing with a wall. Two of them make that.

EddieN120

11-25-2009, 05:02 PM

Let me summarize the last four pages of this thread:

"CSS-only, or die!" : "Tables, now and forever!" :: Mac : Windows

Techno-religious wars, in other words. I notice that so far no one has brought up the pros/cons of using either technique when one wants to create sites that conform to web accessibility standards. Maybe the tenor of the conversation would change in that case.

Use tables for tabular data, and endeavor to use CSS/table-free layout for everything else. Problem solved.

the_pm

11-25-2009, 05:22 PM

I understand tableless design and "semantic valid" design.Two days ago you didn't even know WCAG existed, which is the bible of semantic validity.

Not to sound like a broken record, but we've given you facts, data, sources, resources and real life implementation experiences that corroborate with those sources and provide example of the positive effects associated with coding in a semantically valid manner.

You've given us essentially "I don't like tableless," along with a couple stats that for some reason you refuse to substantiate with any evidence whatsoever and a few snide remarks tied to subject matter about which you are not knowledgeable (e.g. WCAG documentation and SEO impact of semantic validity).

You are correct - there's nothing to debate here. There never really was a debate to begin with.

Techno-religious wars, in other words. I notice that so far no one has brought up the pros/cons of using either technique when one wants to create sites that conform to web accessibility standards. Maybe the tenor of the conversation would change in that case.

Use tables for tabular data, and endeavor to use CSS/table-free layout for everything else. Problem solved.Save your breath on this topic. Two page ago we brought up WCAG (Web Content Accessibility Guidelines), and we've mentioned them multiple times since then with no acknowledgement in return (he didn't know they existed - called me foolish for suggesting they existed).

This whole thing is a farce. There are much better debates within the archives on WHT than this thread.

Use tables for tabular data, and endeavor to use CSS/table-free layout for everything else. Problem solved.Exactly!

Jamie Edwards

11-25-2009, 05:26 PM

Once again, why would you want to switch the order of your coding to not match your website? It has no effect on search engine results the way content is listed in the coding.
Yes, it does have a big impact on search engine optimisation.

N1CK3RS0N

11-25-2009, 05:37 PM

Two days ago you didn't even know WCAG existed, which is the bible of semantic validity.

Not to sound like a broken record, but we've given you facts, data, sources, resources and real life implementation experiences that corroborate with those sources and provide example of the positive effects associated with coding in a semantically valid manner.

You've given us essentially "I don't like tableless," along with a couple stats that for some reason you refuse to substantiate with any evidence whatsoever and a few snide remarks tied to subject matter about which you are not knowledgeable (e.g. WCAG documentation and SEO impact of semantic validity).

You are correct - there's nothing to debate here. There never really was a debate to begin with.

Save your breath on this topic. Two page ago we brought up WCAG (Web Content Accessibility Guidelines), and we've mentioned them multiple times since then with no acknowledgement in return (he didn't know they existed - called me foolish for suggesting they existed).

This whole thing is a farce. There are much better debates within the archives on WHT than this thread.

Exactly!

I didn't know it existed? Your psychic? Where did I say I didn't know it existed. Just curious.

Yes, it does have a big impact on search engine optimisation.

No. No it does not.

Nothing I've read has said anything like that, nore has anything I've seen show it.

XHTML valid data can help the results because it is coded properly. But using a table to organize the design as opposed to floating and positioning div's. Makes no sense.

You guys have your "opinions" and act like they are "facts".

the_pm

11-25-2009, 05:48 PM

Where did I say I didn't know it existed. Just curious.Page 2 - this thread. Let me refresh your memory:
Please send me your copy of "proper uses of HTML", I'd love to see where the developers of HTML say you should not use a table for the structure of your design.

Foolish statement.You had no idea where "the developers of HTML say you should not use a table" was - Jamie was kind enough to introduce you to the documents those very same developers created that you said we were foolish for believing existed:

:D

http://www.w3.org/TR/WCAG10/

Mark up documents with the proper structural elements.

Control presentation with style sheets rather than with presentation elements and attributes. Using markup improperly -- not according to specification -- hinders accessibility. Misusing markup for a presentation effect (e.g., using a table for layout or a header to change the font size) makes it difficult for users with specialized software to understand the organization of the page or to navigate through it.

Content developers may be tempted to use (or misuse) constructs that achieve a desired formatting effect on older browsers. They must be aware that these practices cause accessibility problems and must consider whether the formatting effect is so critical as to warrant making the document inaccessible to some users.

At the other extreme, content developers must not sacrifice appropriate markup because a certain browser or assistive technology does not process it correctly. For example, it is appropriate to use the TABLE element in HTML to mark up tabular information (http://www.w3.org/TR/WCAG10/#tabular-information) even though some older screen readers may not handle side-by-side text correctly (refer to checkpoint 10.3 (http://www.w3.org/TR/WCAG10/#tech-linear-tables)). Using TABLE correctly and creating tables that transform gracefully (refer to guideline 5 (http://www.w3.org/TR/WCAG10/#gl-table-markup)) makes it possible for software to render tables other than as two-dimensional grids.
Ensure that tables have necessary markup to be transformed by accessible browsers and other user agents.

Tables should be used to mark up truly tabular information (http://www.w3.org/TR/WCAG10/#tabular-information) ("data tables"). Content developers should avoid using them to lay out pages ("layout tables"). Tables for any use also present special problems to users of screen readers (http://www.w3.org/TR/WCAG10/#screen-reader) (refer to checkpoint 10.3 (http://www.w3.org/TR/WCAG10/#tech-linear-tables)).
And from the actual HTML specification (http://www.w3.org/TR/html4/struct/tables.html#h-11.1): (http://www.w3.org/TR/html4/struct/tables.html#h-11.1%29:)
Tables should not be used purely as a means to layout document content as this may present problems when rendering to non-visual media. Additionally, when used with graphics, these tables may force users to scroll horizontally to view a table designed on a system with a larger display. To minimize these problems, authors should use style sheets (http://www.w3.org/TR/html4/present/styles.html) to control layout rather than tables.

Its more than acceptable to use tables for layouts. Neither you or anyone else has proven to me why the use of a table to organize the structure of content is a "bad practice".
Here is some lighter (but ever true) reading: http://www.hotdesign.com/seybold/everything.html http://phrogz.net/css/WhyTablesAreBadForLayout.html and http://stackoverflow.com/questions/83073/why-not-use-tables-for-layout-in-html

You guys have your "opinions" and act like they are "facts".Actually, we have results - http://www.webhostingtalk.com/showpost.php?p=6512153&postcount=47 - and they speak louder than anything else in this thread (or did you miss my link earlier in this thread to the post regarding $1.2million in savings based on converting a company's Intranet to tableless design?).

Now show me that source that verifies 99% of the Web is created using tables. You posted this "fact" earlier in this thread and conveniently ignored repeated attempts to have you substantiate it.

N1CK3RS0N

11-25-2009, 06:56 PM

Page 2 - this thread. Let me refresh your memory:
You had no idea where "the developers of HTML say you should not use a table" was - Jamie was kind enough to introduce you to the documents those very same developers created that you said we were foolish for believing existed:

Actually, we have results - http://www.webhostingtalk.com/showpost.php?p=6512153&postcount=47 - and they speak louder than anything else in this thread (or did you miss my link earlier in this thread to the post regarding $1.2million in savings based on converting a company's Intranet to tableless design?).

Now show me that source that verifies 99% of the Web is created using tables. You posted this "fact" earlier in this thread and conveniently ignored repeated attempts to have you substantiate it.

Uh... The developers of HTML didn't say anything about it... W3 isnt the developers. They are an organization who have the support of the developer of HTML. Their opinions are their own, not necessarily his.

Not a single thing you have provided is a fact.

You didn't save anyone 1.2 mil. anyone can make up numbers.

Also, boosting the results of a page is based on traffic and meta tags. Not the use of divs. I'll just throw 1,000 div's at the bottom of a page and outrank everything on Google if that was the case, fortunately, it isn't.

Feel free to post non-factual ******** though. By all means :)

Jamie Edwards

11-25-2009, 07:59 PM

W3 isnt the developers.
I shouldn't laugh, but I did :(

http://en.wikipedia.org/wiki/World_Wide_Web_Consortium

"The World Wide Web Consortium (W3C) is the main international (http://en.wikipedia.org/wiki/International) standards organization (http://en.wikipedia.org/wiki/Standards_organization) for the World Wide Web (http://en.wikipedia.org/wiki/World_Wide_Web) (abbreviated WWW or W3)."

http://en.wikipedia.org/wiki/HTML

" The W3C (http://en.wikipedia.org/wiki/W3C), maintainer of both HTML and CSS standards, encourages the use of CSS over explicit presentational markup.[1] (http://en.wikipedia.org/wiki/HTML#cite_note-deprecated-0)"

Also, boosting the results of a page is based on traffic and meta tags.You could not be more wrong :(

http://www.seomoz.org/article/search-ranking-factors#ranking-factors -
Meta tags listed as a #1 'ranking myth': http://www.rankforsales.com/meta-tags.html

Not the use of divs. I'll just throw 1,000 div's at the bottom of a page and outrank everything on Google if that was the case, fortunately, it isn't.This comment proves that you do not understand what the semantic web is about. Before engaging in debate, I urge you to at the very least familiarise yourself with basic, fundamental facts.

the_pm

11-25-2009, 08:19 PM

Tables weren't "made" just to display data. If so 99% of the web has that wrong and your part of the 1% who has it right. Numbers are against you.Cite your source. At least make some sort of attempt to participate in this debate in a meaningful way.
You didn't save anyone 1.2 mil. anyone can make up numbers.You didn't even read the information in the link, did you...

the_pm

11-25-2009, 08:23 PM

Uh... The developers of HTML didn't say anything about it... W3 isnt the developers. They are an organization who have the support of the developer of HTML. Their opinions are their own, not necessarily his.Ok, I get it now. This is a joke. Real funny. You got me - you totally got me. I thought you were completely serious all the way up to here. Now I know you're just having a laugh :)

You had me going until you started getting silly :)

N1CK3RS0N

11-25-2009, 08:43 PM

I shouldn't laugh, but I did :(

http://en.wikipedia.org/wiki/World_Wide_Web_Consortium

"The World Wide Web Consortium (W3C) is the main international (http://en.wikipedia.org/wiki/International) standards organization (http://en.wikipedia.org/wiki/Standards_organization) for the World Wide Web (http://en.wikipedia.org/wiki/World_Wide_Web) (abbreviated WWW or W3)."

http://en.wikipedia.org/wiki/HTML

" The W3C (http://en.wikipedia.org/wiki/W3C), maintainer of both HTML and CSS standards, encourages the use of CSS over explicit presentational markup.[1] (http://en.wikipedia.org/wiki/HTML#cite_note-deprecated-0)"

You could not be more wrong :(

http://www.seomoz.org/article/search-ranking-factors#ranking-factors -
Meta tags listed as a #1 'ranking myth': http://www.rankforsales.com/meta-tags.html

This comment proves that you do not understand what the semantic web is about. Before engaging in debate, I urge you to at the very least familiarise yourself with basic, fundamental facts.

Standards.

NAMBLA (North American Man Boy Love Association) is the standards for child rape. Guess that makes them right doesnt it?

^^

Theres no reason div's would raise search results. None.

And once again. You need to familiarize yourself, not me. You cannot prove it increases SEO. Its quite simply a stupid argument. :/

Nice sources. Some random website based on random numbers. :/

You guys are cute.

N1CK3RS0N

11-25-2009, 08:45 PM

You didn't even read the information in the link, did you...

Ofc I did. Its random numbers based on theories. You didn't save anyone anything...

Let me write an article of how I saved Google 50 trilion dollars. Brb.

I'm guessing your 14 years old? Am I right? Why else would you spend all your time trolling a forum. And why else would you ever consider putting the word "1337" in your BUSINESS name?

N1CK3RS0N

11-25-2009, 09:04 PM

threads dead

jagarco

11-25-2009, 09:59 PM

Also, boosting the results of a page is based on traffic and meta tags. Not the use of divs. I'll just throw 1,000 div's at the bottom of a page and outrank everything on Google if that was the case, fortunately, it isn't.

Nick3rson

I'm gonna point just a couple of things.

You have disaproved that someone study or checks something that(maybe) won't help him, these are the kind of wrong comments that you have done through the thread, like if you were 15y old, you have a problem with assumptions, you assume without thinking logicaly.

You see, how this person gonna know if CSS is the way to go if he doesn't check it out or study it?. Once this person knows about it will then know if CSS helps him. Doesn't mean CSS is better o worst, again, don't make wrong logical and reciprocal assumptions, he even may have used it wrong or learned deficiently and that also, logically, doesn't mean CSS is necessarely useless.
It just means it is a good or bad option for his needs. BUT, now that he knows it, then he is in position to give an objective opinion.

Have you studied and practiced suficiently the CSS?. <-- This is basic for one to talk about CSS, if you haven't then go study and practice for a few days and then comeback an give and objective opinion, with ofcourse the aknowledge that if it didn't work for you doesn't mean it doesn't work for the rest and that they are wrong(you do understand this logic, right?)
And then this thread will make sense, on the way that you say why you think CSS doesn't offer advantages by giving valid arguments and LISTEN and UNDERSTAND the other's opinions.

Another example and evidence of your disability to see things or understand clearly is the following:
You say that, if DIVs are SEO boosters then one would just use a lot of DIVs...¿¿!!, this comment just puts you on evidence.
You see, Divs are part of a tool to achieve the organization of the data.
According to the logic you thought people here is saying about the SEO of CSS, is if tires help someting to move faster(instead of draging), then if we put more tires, it will go faster and faster.
You're right, that's wrong and makes no sense, but people here ARE NOT saying that,... YOU ARE the one who takes it all wrong, just stop and think, don't jump and start typing.

ALSO, keep in mind I'm not saying CSS is better than Tables or either way.
I've been designing with tables for 12 years and have just like 15 days learning and working with CSS...
So far, IN MY SPECIFIC CASE, I've seen that..

We don't need CSS IF if...
1) The site is 8 pages and gonna be changed drasticaly every year
2) if is done faster by using tables.(our experience in tables)
3) Uses a lot of graphics, we find hard and time consuming to layout in CSS a graphic heavy website, like the ones the customer wants and pays for it and gets upset because his fast and SEO friendly CSS website looks "very simple".

We would need CSS for(so far)
1) Info heavy and well paid websites
2) For our website
3) The customer asks for it because he read it on a magazine or heard it from someone.

We may not target the same market the CSS agencies and developers target.

the_pm

11-26-2009, 12:12 AM

If you're ever interested in finding out what the actual savings for the focused proof-of-concept that was actually implemented, let me know. We implemented the redesign to just 1% of the intranet, and the savings generalized out to closer to $3m.

I'm guessing your 14 years old?Cory, you say you're 22, and yet you compared the W3C to NAMBLA. What more can possibly be said?

I do agree, this thread is dead. I think there's enough information and perspectives available for anyone who wishes to sift through it to get an accurate picture of what's been presented and to draw reasonable conclusions.

Steven

11-26-2009, 01:14 AM

Ofc I did. Its random numbers based on theories. You didn't save anyone anything...

Let me write an article of how I saved Google 50 trilion dollars. Brb.

I'm guessing your 14 years old? Am I right? Why else would you spend all your time trolling a forum. And why else would you ever consider putting the word "1337" in your BUSINESS name?

HAHAHAHA you made me laugh so hard. Paul is probably one of the most professional business men on this board. Do research before you start spewing crap. Studio1337 is a professional design company. They designed my site, filled it with content: It started paying revenue from new customers within hours of it being deployed. Paul know's his stuff.

Try doubling that number and adding some more, to get to pauls age.

bear

11-26-2009, 09:01 AM

Netscape 4.x was by far the worst
Netscape 4.75 and the dreaded @import kludge. I remember it well.
Quite similar to needing the IE "[if lte IE 6]" workarounds these days.
Once again, why would you want to switch the order of your coding to not match your website? It has no effect on search engine results the way content is listed in the coding.
You apparently failed to read all but your own posts, then. It was explained in great detail, and was incredibly interesting, at least to me. I wouldn't turn my back on something that could have that sort of result. ;)

I've been a tables guy since the 90's, but see the huge value in CSS. I've been trying to come to terms with layout using it, but I'm not at the level yet where I can do all that I need, but see the inherent value.

- Will tables be removed from the standard?
Only if a better way of showing tabular data comes along (doubtful).
- Will CSS fully replace tables for site layout?
Not while some hang on to the old ways, and not see the benefits of keeping up with standards and improvements. I do foresee a time, however, when using tables for site layout will hinder SEO and usability (won't be long now), and I hope I'm far enough along with learning how to create with CSS to be proficient at it by that time.

I won't get preachy about CSS (except maybe to clients) to those that hang on to tables, I'll just quietly do my thing, and smile while I get hired and they don't. ;)

rcallaghan

11-26-2009, 10:24 AM

Lucky for me when I started development, I was "mentored" away from using tables.

But for the company I work for the CMS actually activly uses tables, so I have to deal with them a lot.

Tables are the devil.

mochadelight

12-08-2009, 03:48 AM

Yes, it does have a big impact on search engine optimisation.

Did no one read that google's headers algorithm takes into account the first portion of the page (if there's tables there's much more fluffing and much less content) and then put's it against the rest of the page and then that is how relevance is calculated. Relevance is in the top 5 important things about having a site recognized and ranked higher by google.

I just explained that very simply, I'm sure it's way more complicated than that, but that's the basic idea.

Just saying

RemyHorton

12-08-2009, 08:37 PM

IE6 is actually pretty easy to handle, with just a few very basic techniques. I won't cry when the day comes that IE6 is eradicated, but it's really not as bad to work with as some people think.

It still makes CSS look like a gotcha-ridden technology. To someone who does websites occasionally rather than as a career, it doesn't take many gotchas to get a technology dumped.

Netscape 4.x was by far the worst, because it was a popular browser during the time CSS was really taking off, and it offered odious support for CSS specifications. IE5, IE5.5 and IE 5.2 Mac weren't exactly a picnic, but we're definitely at the point where in all but the most specific circumstances, we no longer need to account for these.

I think the version of MSIE shipped with Windows Mobile is pre-MSIE6, and it is certainly painful to use.

User10001110101

12-23-2009, 03:51 PM

Maintaining my website is one of my responsibilities. I'm self taught and been doing it for a few years. I've been growing less dependant on dreamweaver for it's WYSIWYG editor and have a decent grasp on what's happening with the coding.

I've relied on using tables for layout and I can't seem to break that. I'm in the middle of doing a revamp and trying my best to avoid tables, except for tabular data. I've read several tutorials how to layout a website with CSS but I cannot grasp it. The part that frustrates me (and coding in general) is that if one small thing is off, it doesn't work.

User10001110101

12-23-2009, 03:56 PM

I'm having trouble making my new page:
http://proof.vision-marketing.com/visiontron/prod-crowd-accessories-umbrella-bag-stand.asp
look like my old page:
http://www.visiontron.com/wet-umbrella-bag-stand.htm

My feeble attempt at doing a three column layout inside of a two column layout is here:
http://proof.vision-marketing.com/visiontron/prod-crowd-accessories-umbrella-bag-stand3.asp

How long did it take you to break the table habit? It's so tempting to just give up and use a table in a few minutes vs. spending hours learning css. Does anyone have a tutorial that gave them that final "ah ha"? I know it will be beneficial in the future, but I can't seem to make the jump. There's never enough time in the day as it is and I want to get this site up...

iamzen

12-27-2009, 11:52 AM

CSS takes time to learn, but there are many benefits of a table-less design. With Google also recommending speeding up your website it is now imperative that you code in CSS.

PingVPS

12-28-2009, 08:39 PM

Oh I wish I had seen this thread earlier.

Nvm, I'll keep my 2 pennies short.
CSS3 and HTML5 will be an awesome setup for the future of design, and the ability to work creatively in CSS3 will be nothing short of brilliant when it becomes better supported.

I gave up tables years ago, unless it is actually tabular data, and anyone still designing in tables really should widen out.
But thats all just imo, what do I know... ;)

bear

12-28-2009, 09:54 PM

I love CSS for formatting (not so much for layout), and can work around most browser issues, but for anyone to state that the next version will be the best ever and all problems will be resolved is not paying attention to history.
The day the browsers agree on ONE standard and render the same tags in the same way, I'll be first in line to use and promote it. Until then, it's just another tool to be used sparingly, and we all need to use kludgy methods to make it work in them all in the same (well, similar) way. This is not so different from Netscape 4.75 (shudder) not understanding much CSS and requiring the @import workaround. Today it's IE and the < ! --[if lte IE 6] > hacks.

It'll happen again...but CSS7, now there's the one. :angel:

PingVPS

12-29-2009, 02:57 AM

but for anyone to state that the next version will be the best ever and all problems will be resolved is not paying attention to history.
Well you are going to have to show me where I said that exactly...

I said nothing from a cross browser point of view, I spoke from a design PoV.
That said, it WILL be the best YET with some clarity on semantics in html5 and even IE9 will finally support major CSS3 features.

You seem to be looking at some very nice design advancements from a negative PoV whereas I simply love design and will be very happy to see the arrival of "the next best thing".

Cross broswer tweaking is part of the course, it's not a big deal and doesn't take long to work out if you know what your doing.
But that's not what the topic was about, and not what I was commenting on.

123 Logo Design

12-29-2009, 08:13 AM

I moved from tables a few years ago and haven't looked back, there are some issues with browser compatability, especially with IE8 compatability mode thrown into the mix too, but nothing a few IF tags won't sort out.

The-Host

12-30-2009, 06:36 AM

Tables are still good for aligning certain things for the contents, but it's definitely not a good way for coding the whole website.

RWD-Jay

12-30-2009, 02:44 PM

I have to agree with Nick3rson.

For example, something like the ISO standard. You can't pass certain things without an ISO standard, they are the official body for that standard. You don't need anything from W3, you can make a website, however you want and there's NOBODY to say that's the correct or incorrect way to do it.

If you want to use tables as the entire structure/layout of your site, it displays properly in all browsers, who cares? Just because they say you shouldn't do it, doesn't mean **** to me. If I want to use an entire tabled structured site, I will.

I'm not bothered about complying to the latest web standards, I look after number one and that's me, not you.

Jamie Edwards

12-30-2009, 03:08 PM

If you want to use tables as the entire structure/layout of your site, it displays properly in all browsers, who cares? Just because they say you shouldn't do it, doesn't mean **** to me. If I want to use an entire tabled structured site, I will.
Tables are not accessible to screen readers or friendly to processors (such as search engines) which is a typical webmaster's want.

the_pm

12-30-2009, 03:13 PM

I'm not bothered about complying to the latest web standards, I look after number one and that's me, not you.That's actually a very telling statement, and I can't say I disagree with it.

If the #1 consideration for a Web designer him or herself, then WCAG documentation is useless.

If the #1 consideration for a Web designer is the visitors who will use the site, that's when understanding of WCAG documentation becomes indispensable.

W3C coding standards are meant for browser manufacturers and indirectly for Web designers. W3C WCAG documentation is meant to benefit site visitors. If you care, you follow it. If you don't, you have no reason to follow it. I can't imagine anyone but the site visitors being #1, but that's just my take.

This is a very easy "agree to disagree" scenario :)

RWD-Jay

12-30-2009, 11:42 PM

Don't get me wrong, the customers interests are at the forefront of my mind but I don't think most of them give a **** about it being accessible to blind people and SEO isn't hugely affected.

I code html templates into CMS and they achieve good results organically and the clients are always happy so why bother with complying to web standards?

Each to their own though, nobodies hurting me coding to the latest standards and I'm not hurting anyone else using tables.

the_pm

12-30-2009, 11:59 PM

I code html templates into CMS and they achieve good results organically and the clients are always happy so why bother with complying to web standards?Because the sites you create are not for your customers, they're for your customers' visitors. Most design customers don't know enough about our field to understand the difference between coding techniques and the broader implications of coding decisions we make (though this is changing - out of the last half-dozen RFQs I've read, five out of six did not allow bids without commitment to standards, tableless layout and semantic validity - it's quickly becoming a fact of life, not a choice anymore).

Actually, every RFQ we've received in at least the last two years where the client budget is more than $15,000 has explicitly mentioned accessibility standards compliance (including one slightly under, $14,500, from one of our local Port Authorities who needed a new site BADLY, but needed a custom CMS, and their budget was just too low for their needs). Clients are getting better about educating themselves. When there's more at stake, you tend to see all sorts of things requested that you'd never expect to see out of a potential client!

I don't think most of them give a **** about it being accessible to blind peopleThere are actually some pretty critical legal implications regarding accessibility in a number of countries (UK and Australia are particularly well known for this). We didn't know just how important this would be until we start researching it more thoroughly back in 2004, when we started looking to expand into specific markets more. You have to be really careful how you code! This is why most job descriptions from design firms looking for front-end designers insist on full understanding of standards and familiarity with accessibility guidelines.

HOD-Jardin

01-01-2010, 02:51 PM

I'll keep it short and sweet. CSS is overrated.

If your viewer is rocking the latest and greatest browser then wonderful. However, toss in some Safari, older versions of IE and FF and you have yourself a nice little mess. Alignments change, page rendering is ugly and slow, etc.

Explain to me why we don't use tables? And don't give me this "they're for data". IT'S CODING... IT WORKED... AND IT WORKED WELL :D

Anyways, just my rant :D I think we're 100% going back to table design on our pricing and order pages. Not willing to take the chance that those aren't rendering correctly.

Hey... there not gone.

Maybe you could bring back tables ;) keep it nice and old skool

Its like everything nowadays...

Vinyl replaced by cds, VHS replaced by DVDs :)

jason_21218

01-13-2010, 12:21 AM

Quite an interesting thread thus far. :)

Paul is referring to me. I have a local design client with a very successful retail site that I built 7 years ago and have been updating/maintaining it for him ever since. We decided to do some SEO work on the site. Part of the project included recoding the site, which is where Paul (the_pm) came in.

Before recoding it, my client would be around position 15 in a google search for most of his important keyword searches. Paul recoded the site, and immediately after Google revisited the site, my client enjoyed a fantastic boost up to position 2 or 3 in most of the various keyword searches. Amazing improvement. (And let me say parenthetically that it takes a LOT more to go from 15 to 2, than it does to go from 100 to 15). Needless to say, my client was absolutely thrilled with the results, and he is now enjoying much more organic traffic to his site.

Let's compare just one page to see the difference - the home page. Before recoding, I had the site completely built with tables. And I had a bunch of JS code in the <head> section. So when you would visit the home page and click to View Page Source, it would take 2 or 3 page scrolls to finally see actual content. Move forward to after Paul's recoding. Now, when I click to View Page Source, keyword rich content is visible half way down the first screen, no scrolling required. Right there, up front and center. All because of more efficient coding. Here is another illustration of how efficient his code is. Pre-Paul, the home page was 25 KB. Post-Paul, it went down to a staggering 5 KB. Absolutely amazing.

Do not under-estimate the importance of this. Properly coded, you are able to push all your keyword-rich content up very high in the source code. Invaluable. Does not affect the display of the page, but does wonders for SEO.

As far as I'm concerned, Paul is brilliant. And let me also say that over the past few years, in spite of his encouragement to learn CSS, I have been totally resistant to "crossing over to the other side". I have been a "table" guy for many years. But the more I am exposed to Paul's work, the more I am convinced that there are better ways to code a site.

Vito

I am a newb here, but I keyed in on this quote. I am learning web design, and I want clarification of this point. When you talk about pushing key word rich content further up the code, and thus getting better SEO, is this because no matter where you put your 'key word rich content' in your code- CSS will position said content anywhere on the page without disturbing code?? Just trying to get the concept here.

Thanks
Jason