homepage Welcome to WebmasterWorld Guest from 54.227.146.68
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Become a Pro Member

Home / Forums Index / Code, Content, and Presentation / HTML
Forum Library, Charter, Moderators: incrediBILL

HTML Forum

This 155 message thread spans 6 pages: < < 155 ( 1 [2] 3 4 5 6 > >     
Tables - What is so bad about them again?
SirTalksalot




msg:3704281
 9:49 am on Jul 22, 2008 (gmt 0)

Hi all,

I've had it driven into me for so long now that 'tables are for displaying data', and not to be used to format your page any more, and the way forward is forever CSS.

I've tried my best to stick with CSS, but I've always found it a massive pain in the ass compared to simply using tables. The text is still readble on a page, the links still work, what's the big deal?

In short, I'm thinking of making life a lot easier by simply reverting to tables for formatting, with a little CSS to tweak it. Is this really such a crime?

 

Demaestro




msg:3726585
 7:58 pm on Aug 19, 2008 (gmt 0)

It isn't about semantics.

Fact, HTML elements are meant to describe their content. If the content put in an element is not what is being described by the tag it is simply the wrong tag. This isn't really debatable, it is fact.

Like I said, will it work? Yes.
Is it right? No

The real question shouldn't be, "why is it wrong?"

The real question should be "What are the implications of doing it wrong?"

There are lots of answers to that question.

Some implications are: (and there are more)
1) Pages are not optimized for indexing.
2) Screen readers will have problem sorting out layout from content, and will take longer to do so.
3) As modern browsers become more standards compliant non standard compliant sites' expected behavior will not happen.
4) As modern browsers become more strict what will you have to go back and change to accommodate?

Example, <b> tags? Is it wrong to use them? Yes.
Do they work now? Yes.
Since they work should you keep using them? No...
Why? Because in 3 years when they don't work you don't want to go back and change all the sites that use them.

Can you deep fry bacon? Yes
Does it make it crispy and cooked? Yes
Ask any chef if it is right and they will say? No

Not a matter of semantics
[w3.org...]
Tables represent relationships between data.

Use them improperly if you want. Just know that your HTML elements are not defining their content.

Herenvardo...

About the penalty and bot issues.

One thing I know for sure is the issue of what text shows up under your link in the search results pages, I find that table based layouts will show nav links and side widget text as the indexed "content" more often then what is actually the content of the page.

This in my view can drastically affect rankings for many keywords, as you will point out I am sure this is avoidable yes, but you are doing more work to compensate having done something wrong in the first place.

<specualtion type="pure">Going deep into nodes could also affect ranking because load times can affect ranking. I am just not sure if parsing the HTML is considered part of the load time or if that is measured simply by time it takes to transfer the file and all dependent files, but if parsing the html is part of the load time then deep node levels can matter</speculation>

(Notice how the above tag defines it's content, that is the nature of a markup language, if I put <fact></fact> tags around that it wouldn't be right.. but it would still work)

[edited by: Demaestro at 8:03 pm (utc) on Aug. 19, 2008]

mattur




msg:3726594
 8:19 pm on Aug 19, 2008 (gmt 0)

<table> is meant to contain tabular data...

Tables were designed "to markup tabular material or for layout purposes" [w3.org]

There are some good reasons for using a CSS layout, but the idea that using tables for layout is an unconscionable abuse of the theoretical "semantic" purity of HTML is not one of them ;)

The main advantages of CSS layouts are progressive rendering as the page loads, leaner HTML, and source ordered content.

The main disadvantage with CSS layouts is they are a monumental pain in the ass to get working - at least until you get a handle on the various browser bugs. The learning curve is steep.

Is it worth investing time in converting a successful table-based website to a CSS-based layout? I'd say 95 times out of 100 you'd see a bigger return from developing new content or new features.

SuzyUK




msg:3726614
 8:54 pm on Aug 19, 2008 (gmt 0)

Mattur you quote HTML3.2 we're about to move to HTML5 (which I know you well know)

3.2 is where it went "wrong" we didn't have CSS then (everyone was apparently learning ;)) and is possibly why we're even still having this debate.. anyway if you want to get to 5 properly then

, but the idea that using tables for layout is an unconscionable abuse of the theoretical "semantic" purity of HTML is not one of them

is not the way to go IMVHO, instead the term "deprecated" in HTML4 & 4.01 takes care of most of this debate/argument

[edited by: SuzyUK at 9:04 pm (utc) on Aug. 19, 2008]

mattur




msg:3726643
 10:00 pm on Aug 19, 2008 (gmt 0)

Yes, I take your point Suzy. As I (hopefully) emphasised, CSS-based layouts do have advantages over table-based layouts. Even I now use CSS for layout(!)

Some people will continue to use layout tables as a pragmatic choice, and not just ma and pa sites - look at news.bbc.co.uk or Google. Although I would expect their use to gradually die out over time, "because the W3C says so" is not a particularly convincing or effective argument imho (see XHTML1/2).

BTW: HTML3.2?! HTML went wrong when Marc Andreessen introduced the img tag... ;)

Herenvardo




msg:3726674
 11:24 pm on Aug 19, 2008 (gmt 0)

Tables were designed "to markup tabular material or for layout purposes"

Although a definition from the 3.2 spec doesn't hold too much value (IMHO, HTML 3.2 is the worst thing ever happenned on the Internet), at least we should quote the full definition, keeping the part that says "Note that the latter role typically causes problems when rending to speech or to text only user agents."
(don't forget that web crawlers fall in the category of "text only user agents").

Using DeMaestro's notation (this is no irony at all, I really think it will be quite descriptive):
<fact>Tables for layout are wrong by definition.
<exception>Documents marked as HTML 3.2 are explicitly warning the user that tables in them are ambiguously used for either layout or tabular data representation; and they presumably predate this fact.</exception></fact>
I hope we can all agree on that, because it is stated since the earliest standard after 3.2 [w3.org]:
Tables should not be used purely as a means to layout document content [...] authors should use style sheets to control layout rather than tables.

So, let's see the issues and alternatives of table-based layouts:
<fact>The use of tables for layout is just one of the many atrocities commited by HTML 3.2.</fact>
<fact>The Web was able to survive HTML 3.2's atrocities</fact>
<implication>The Web is able to survive one remaining aberration, such as tables used for layout.</implication>

<fact>The recommended way to render a table-like layout is by using CSS.</fact>
<fact>The currently most used web browser's support for CSS sucks.</fact>
<fact>Creating a minimally complex, CSS-based layout that renders properly for a majority of the users is, when possible, a pain.</fact>

<summary type="opinion">
I agree with the fact that tables for layout are a bad thing; but pages that don't render are a worse thing.
I really prefer to entirely rely on CSS for layout, and if my layout can't properly rendered properly on most major browsers, I'd rather adapt or simplify my layout than miss-use structural markup. However, not all sites have this flexibility on their layout designs; and hence I consider justified the use of tables for layout on some situations.
<speculation>Based on the efforts made by MS to perpetuate bad mark-up, it seems that they hate Internet.</speculation>
<fact>I do hate MS.</fact>
</summary>

Mattur you quote HTML3.2 we're about to move to HTML5 (which I know you well know)

:o Really? Are you? I'm definitelly not. Have you seen the current HTML5 draft? (hint: it supports things like the <font> tag, adds other stuff like the <audio> and <video> tags, requires user agents to "properly" render things like "<b>bold <i>bold and italic</b> italic only</i>", and, above it all, XHTML2 is strictly superior in every comparable aspect.)

BTW: HTML3.2?! HTML went wrong when Marc Andreessen introduced the img tag... ;)

Maybe, but <fact>with HTML3.2 it went worse</fact> :P

Regards,
Herenvardo

mattur




msg:3726702
 12:19 am on Aug 20, 2008 (gmt 0)

... keeping the part that says "Note that the latter role typically causes problems when rending to speech or to text only user agents."

The W3C was wrong, see WCAG1. Layout tables do not typically cause accessibility problems. I tested web accessibility with real screen reader users way back in the 1990s pre-WCAG1, layout tables were not an issue - as long as they linearised correctly, as most do [joeclark.org].

Look, there are clear advantages to CSS-based layouts, and there's also some clear disadvantages. For someone who can spare the time to learn CSS in depth, the advantages outweigh the disadvantages. We don't need to repeat the old inaccessibility myth, or rely on calls to (W3C) authority ;) to make a case for CSS-based layouts.

The advantages are: progressive rendering, lean markup, source ordering and keeping all your styling in one place. CSS-based layouts can also easily implement zoom layouts for better accessibility.

The disadvantages are: CSS has no way of laying out columns/grids. This is slated for CSS3. So we have to resort to arcane methods to do simple layouts, and test them/fix them for popular browsers. So the learning curve is steep. The other disadvantage is keeping all your styling in one place, so you take a performance hit for the first request.

The case for CSS layouts stands on its own practical benefits, no indepth philosophical discussions of what tables were originally meant for required. Floats weren't meant to be used for designing columnar layouts! Does anyone care? No. :)

XHTML2 is strictly superior in every comparable aspect

Number of browser makers who agree with you and plan to support XHTML2: 0

Number of browser makers supporting HTML5: all of them :)

mattur




msg:3726724
 12:47 am on Aug 20, 2008 (gmt 0)

Also, you are correct in stating that the W3C advised people to use CSS instead of layout tables in 1997. In retrospect, and even at the time, this was duff advice, bordering on utter lunacy, since IE4 and NN4 had only just been released. Thanks for reminding me :)

Herenvardo




msg:3726757
 2:06 am on Aug 20, 2008 (gmt 0)

The W3C was wrong, see WCAG1. Layout tables do not typically cause accessibility problems. I tested web accessibility with real screen reader users way back in the 1990s pre-WCAG1, layout tables were not an issue - as long as they linearised correctly, as most do.

There is an important issue with the "linearization is enough" approach: in a visual context, the observer's attention is, in most cases, firstly drawn to the bigger elements (these will often be the main content "blocks" or the banner/logo of the site), sometimes affected by color but nothing else. It doesn't matter what's up or down, or if something's on the left or the right: the bigger and most outstanding parts will always catch your eye before the others. This is intensively used by most table-based layouts, but is ignored by a lineraization process. Summarizing: the order in which the different parts of the layout will be reached by a visual user is not guaranteed to be kept (and, in most cases, is not kept) when lineraizing the table. I can put a couple of examples: check the source of this very site (bad idea, it's a horrible tag-soup) or even to section508, and see how much side-stuff you'll find before the actual content. In the case of 508's site, if you are going to tell me that having a blind person being read the list of options of the font selector before any of the content is not an issue, just because the table "linearises", then we'll need to contrast what do we understand as "issues".

CSS has no way of laying out columns/grids. This is slated for CSS3.

Did you ever check that before making such a statement? CSS 2 (and 2.1) has an entire chapter [w3.org] dedicated to laying out tables, which can perfectly represent columns or grids. And even without that, there are many tricks to achieve similar effects (just play with fixed's or float). It's true that IE up to 7.0 doesn't support these properties, but all other major browsers do, and MS has stated "The Internet Explorer 8 layout engine is built to be cascading style sheets 2.1 compliant" [microsoft.com], so we should expect IE to finally support these features of CSS. I'll try to download it and test it if I find a moment, but that's not among my priorities.

$Number of browser makers who agree with you and plan to support XHTML2: 0

What are you basing this statement in? Most major browsers already support XForms + XML Events; some are working on XFrames, and everything else in the spec can be perfectly rendered with just a default CSS sheet (and an example default sheet is included in an appendix of the spec).

Number of browser makers supporting HTML5: all of them :)

Of course: it is a spec made by browser makers! That they all support it doesn't define its quality, only its convenience. And, of course they have made it according to their convenience.
Quoting myself:
Have you seen the current HTML5 draft?

I want to insisit in the question, because I have only based my opinion on the contents of both specifications (I think it's a good criteria upon which to base an opinion about which specification is the best one, don't you think?).
Anyway, I don't want to go out of topic here. If you are interested, I encourage you to start a new threat about HTML5 vs XHTML2, and PM me; and be sure we can have a long and interesting discussion on that topic ;).

Regards,
Herenvardo

csuguy




msg:3726758
 2:06 am on Aug 20, 2008 (gmt 0)


It isn't about semantics.

Fact, HTML elements are meant to describe their content. If the content put in an element is not what is being described by the tag it is simply the wrong tag. This isn't really debatable, it is fact.

That's a semantic argument ;) - what something is MEANT to be used for. Lots of things are meant for specific purposes - but sometimes things can be used for other purposes as well or better than things that are meant to do those tasks. There are just too many problems with CSS and grid outlines for the time being (not to mention CSS designs typically increases the time for developing a site by 50%).

When the tools and support are there for CSS Div Grids - I'll be the first using 'em. But that'll take probably 20 years... so in the meantime I'll use tables where necessary.

Herenvardo




msg:3726762
 2:10 am on Aug 20, 2008 (gmt 0)

Also, you are correct in stating that the W3C advised people to use CSS instead of layout tables in 1997. In retrospect, and even at the time, this was duff advice, bordering on utter lunacy, since IE4 and NN4 had only just been released. Thanks for reminding me :)

I'd rather say it was brilliant cleverness: had content authors followed that advice, Microsoft wouldn't have taken 11 years to implement CSS '

(Sorry for double-posting, but I just saw your new post).

Regards,
Herenvardo

Stefan




msg:3726772
 2:35 am on Aug 20, 2008 (gmt 0)

I like tables. I use them. Arguments for CSS sometimes verge into what seems to me to be religion. But, each to their own.

csuguy




msg:3726792
 2:57 am on Aug 20, 2008 (gmt 0)


I'd rather say it was brilliant cleverness: had content authors followed that advice, Microsoft wouldn't have taken 11 years to implement CSS '

Had content authors followed that advice - they would have found themselves looking for a new line of work as no one would hire them.

csuguy




msg:3726793
 2:58 am on Aug 20, 2008 (gmt 0)


I like tables. I use them. Arguments for CSS sometimes verge into what seems to me to be religion. But, each to their own.

Maybe that's why I like debating the Tables VS CSS argument so much - I love to debate theology :D

csuguy




msg:3726804
 3:10 am on Aug 20, 2008 (gmt 0)


There is an important issue with the "linearization is enough" approach: in a visual context, the observer's attention is, in most cases, firstly drawn to the bigger elements (these will often be the main content "blocks" or the banner/logo of the site), sometimes affected by color but nothing else. It doesn't matter what's up or down, or if something's on the left or the right: the bigger and most outstanding parts will always catch your eye before the others. This is intensively used by most table-based layouts, but is ignored by a lineraization process. Summarizing: the order in which the different parts of the layout will be reached by a visual user is not guaranteed to be kept (and, in most cases, is not kept) when lineraizing the table. I can put a couple of examples: check the source of this very site (bad idea, it's a horrible tag-soup) or even to section508, and see how much side-stuff you'll find before the actual content. In the case of 508's site, if you are going to tell me that having a blind person being read the list of options of the font selector before any of the content is not an issue, just because the table "linearises", then we'll need to contrast what do we understand as "issues".

Screen Readers have been developed with this in mind. Hence they offer many shortcuts to their users - like being able to have all of the headers read to them and then going to whichever one they want. So this really isn't an issue for someone who is experienced with screen readers.

Ryan

seodreamer




msg:3727019
 11:30 am on Aug 20, 2008 (gmt 0)

Theres a couple of issues with using tables:

1. Excessive tags get sent to the clients browser - increases page size and of course download time.

2. Nesting - Nesting content is not good especially for accessbility (screen readers etc..). Also search engines dont like it too much either.

Its suprising how easy it is to design web pages using DIVs. With the aid of FireFox developer toolbar its also easier to visually see the div areas

csuguy




msg:3727141
 1:41 pm on Aug 20, 2008 (gmt 0)


Theres a couple of issues with using tables:

1. Excessive tags get sent to the clients browser - increases page size and of course download time.

1.Excessive tags aren't sent to the browser. Take the following table code vs the correct (though unsupported) div variant:


<table>7
<tr>4
<td>4
</td>5
</tr>5
</table>8

That's 33 characters
(the numbers are there to show how many characters were needed for the tag)

VS:

<div id="t">12
<div id="c">12
</div>6
</div>6

That is 36 characters - 3 more than a table. And that's assuming a 1 char ID - which isn't likely. Not to mention you then have to put all of the CSS code in somewhere to specify 'display:table' and 'display:table-cell' accordingly. So - in fact - the div alternative increases the HTML size, the CSS size, and isn't supported by older browsers. Hardly a better choice.

EDIT: Also note that the larger of a grid layout you have - the more and more using a table is going to save you in terms of the amount of markup (and css for that matter) that is going to be involved.


2. Nesting - Nesting content is not good especially for accessbility (screen readers etc..).

Most sites that nest table could be simplified with good coding methods so that you have no more than 2 deep. I've seen sites with tons of nested divs - its no better.

As for accessibility - sites can be made just as accessible with tables as with divs. Look at section508.gov or screenreader.net. It's about good (though unsemantical) coding.


Also search engines dont like it too much either.

Same as above - tables can be written to be just as accessible as divs (and really with very little effort). Furthermore - search engines have been dealing with table based sites for a LONG time. They are good at handling them and is not an issue so long as they are written well.


Its suprising how easy it is to design web pages using DIVs. With the aid of FireFox developer toolbar its also easier to visually see the div areas

Its surpising how easy it appears until you hit one of the many problem areas with divs - usually centering around trying to make a grid layout. Tables are better supported for that line of work. One day divs will have the support, but until then tables are king.

Herenvardo




msg:3727257
 3:32 pm on Aug 20, 2008 (gmt 0)

<table>7
<tr>4
<td>4
</td>5
</tr>5
</table>8

That's 33 characters


ROFL! Are you saying that someone using tables for layout won't use "nowrap", "border", "width" and similar attributes? For most layout tables you'd find, at least, a " border=0": that's 9 extra chars, even if skipping the quotes for the attributes: that's already 42. And the "width" attributes are also a common sight on this aspect.
About the CSS file size, in most cases it is downloaded only once per user for an entire site, and cached by the browser.
Taking figures from my own experience, swtching a layout between tables and CSS normally has a minimal impact on file-size, and it happens in a case-by-case basis: sometimes the CSS version gets heavier, sometimes gets lighter. I don't think filesizes is an argument for neither side.

So - in fact - the div alternative increases the HTML size, the CSS size, and isn't supported by older browsers.

There are many ways to achieve the same effect on CSS. Actually, while the display:table- series of properties are not supported by IE (note that most other browsers support it), there are CSS-based table layouts out there that render properly cross-browser.

Most sites that nest table could be simplified with good coding methods so that you have no more than 2 deep. I've seen sites with tons of nested divs - its no better.

Good point, and it's related to something I already tried to say: you can find everything:
There are CSS-based layouts that are highly accessible and render nicely in most browsers.
There are table-based layouts that are highly accessible and render nicely in most browsers.
There are CSS-based layouts that end up being a tag soup of div's and spans's, are completelly unaccessible, and some can only be rendered by one browser (probably the author's).
There are table-based layouts that end up being a tag soup of nested tables, are completelly unaccessible, and some can only be rendered by one browser (probably the author's).
And, of course, there is also a full range of grays in between.

Its suprising how easy it is to design web pages using DIVs. With the aid of FireFox developer toolbar its also easier to visually see the div areas

Its surpising how easy it appears until you hit one of the many problem areas with divs - usually centering around trying to make a grid layout. Tables are better supported for that line of work. One day divs will have the support, but until then tables are king.

I want to insist in the idea that well-designed layouts shouldn't need a "user manual". If you find yourself on a situation where you don't know anymore what your CSS rules are doing, or which tables is each part of the page in, then I'd suggest you to re-think your design: it can probably be simplified in a way that fulfills the same goals, and it's easier to author and browse. Most often, designing a navigable, intuitive layout (regardless of it is CSS- or table-based) is quite easy, and converting your layout in a maze that gets users dizzy and lost (which so many noob designers achieve) take a lot of effort.

Regards,
Herenvardo

Demaestro




msg:3727393
 5:08 pm on Aug 20, 2008 (gmt 0)

That's a semantic argument ;) - what something is MEANT to be used for. Lots of things are meant for specific purposes - but sometimes things can be used for other purposes as well or better than things that are meant to do those tasks.

Not when one is expected to adhere to a standard.

Can I use saran wrap as a window? Yes but building codes will say I am wrong to do that.

A window in a building has an unambitious definition from a standards compliance stand point. As does a table, so from that position I don't believe it is a matter of semantics.

Herenvardo




msg:3727482
 6:57 pm on Aug 20, 2008 (gmt 0)

Not when one is expected to adhere to a standard.

Can I use saran wrap as a window? Yes but building codes will say I am wrong to do that.

A window in a building has an unambitious definition from a standards compliance stand point. As does a table, so from that position I don't believe it is a matter of semantics.


It's worth mentioning that the standards we are speaking about (HTML 4 onwards, and XHTML) base many of their definitions (specially those about tables) on the content's semantics.
So, any argument based on the HTML standards is, implicitly, also based on semantics :P

Regards,
Herenvardo

Demaestro




msg:3727510
 7:25 pm on Aug 20, 2008 (gmt 0)

csuguy, how many chars there are have little bearing other then file size. The issue is how many nodes have to be traversed before reaching content. Not how many characters have to be read into memory.

**************
<div>Content Here</div>
This is 1 node traversed to get to content.
**************

**************
<table><tr><td>Content Here</td></tr></table>
This is 3 nodes to get to the content
**************

Think like a markup parser would and you will see what I mean.

csuguy




msg:3727566
 8:16 pm on Aug 20, 2008 (gmt 0)

@Herenvardo

ROFL! Are you saying that someone using tables for layout won't use "nowrap", "border", "width" and similar attributes? For most layout tables you'd find, at least, a " border=0": that's 9 extra chars, even if skipping the quotes for the attributes: that's already 42. And the "width" attributes are also a common sight on this aspect.
About the CSS file size, in most cases it is downloaded only once per user for an entire site, and cached by the browser.
Taking figures from my own experience, swtching a layout between tables and CSS normally has a minimal impact on file-size, and it happens in a case-by-case basis: sometimes the CSS version gets heavier, sometimes gets lighter. I don't think filesizes is an argument for neither side.

Actually - I use CSS to control those properties. So it would require an 'id="t"' which adds 6 chars - which puts it over by 3 from the divs. However, giving realistic names that would actually be used would easily put the table (1 id) back in the lead over divs (2 ids). Not to mention for every row and cell added to the table - tables gain a 1 char lead (not including the chars needed for the id and or class). So the larger the table the less and less file size it takes over its div equivalent. Not to mention you don't have all of the CSS code to deal with - which doesn't work.

In addition to this - while I used id for the table cell in the previous example, if you were really going to be making a table with divs you would use a class - and that would increase the benefit of tables further.

Now - it does depend upon what exactly your building, because there are some alternative techniques with CSS Divs - as you kind of mentioned. Basically - any grid based layout is going to save on file size for both the html and the css - and it is going to be much better supported.

And file size is important - because that's what has to be transfered every single time regardless of your CSS being cached. Then you add in the fact that you have to download the CSS as well (even if just once) and tables look even better!


There are many ways to achieve the same effect on CSS. Actually, while the display:table- series of properties are not supported by IE (note that most other browsers support it), there are CSS-based table layouts out there that render properly cross-browser.

For the most part, these alternatives require as much if not more markup - and a lot more in the CSS. So there is no benefit file-size wise. As for it just not being supported by IE - that's the same as not being supported. As much as developers hate IE, most people use it. If you can't make it work for IE - then your not going to use it. Well, unless its your own personal site - but not for a client.

The rest of your post I agree with :)

Ryan

csuguy




msg:3727577
 8:24 pm on Aug 20, 2008 (gmt 0)


Not when one is expected to adhere to a standard.

Can I use saran wrap as a window? Yes but building codes will say I am wrong to do that.

A window in a building has an unambitious definition from a standards compliance stand point. As does a table, so from that position I don't believe it is a matter of semantics.

I do follow a standard - Real World Standards, that which works and is efficient. That's what your clients expect you to follow - not some half baked philosophy that needlessly increases production time by 50% because you have to hack some aspect for every single browser. If W3C Standards were true standards - you wouldn't need to hack, because they would be supported. They are right to call their standards 'recommendations' - they should be treated as such.

Furthermore - if we were at the ground floor with HTML I might agree with you that everyone expects a table to display tabular data. However, you know as much as I that tables have long since evolved to encompass layout and so no one expects them to be used solely for tabular data anymore - not realistically at any rate. So, you really have no argument.

csuguy




msg:3727597
 8:32 pm on Aug 20, 2008 (gmt 0)


csuguy, how many chars there are have little bearing other then file size. The issue is how many nodes have to be traversed before reaching content. Not how many characters have to be read into memory.

**************
<div>Content Here</div>
This is 1 node traversed to get to content.
**************

**************
<table><tr><td>Content Here</td></tr></table>
This is 3 nodes to get to the content
**************

Think like a markup parser would and you will see what I mean.

First off - note what I was responding too:

increases page size and of course download time.

So - yes - I was explicitly referring to page size.

Second off - the number of nodes needed to reach content is irrelevant. Does it require more cycles - sure. Does a couple more cycles hurt ? No. They have had to deal with tables for a long time and more likely than not effectively treat "<table><tr><td>" as a single node.

Furthermore - do you have an official site that says the number of nodes used effects the results? Or are you just pulling things out of the air - guessing at how these very large search engines, who have had years to develop and optimize their algorithms, work?

In terms of ranking - it doesn't effect it. That's determined by how many link to your site and visit it. The only thing it might effect is the description used in the site listing. Again - they've been doing this for a long time and I highly doubt a couple of extra nodes is going to stop them.

Demaestro




msg:3727613
 8:42 pm on Aug 20, 2008 (gmt 0)

You were responding to excess tags so yes the amount of tags is relevant, I was merely pointing out it is more relevant to the nodes traversed then the few extra kb in file size.

Do I have an official site to show this is true? No which is why I said it was speculation on my part.

Does a couple more cycles hurt? No

Do you have a source on this or are you also guessing?

A couple more cycles imo does hurt. It puts more strain on the algo you even said so yourself.... multiply that small overhead on each site by the 1 billion unique URLs that Google has indexed, then times that by how many pages each URL has and you can see why it is likely that Google would favor sites that do things properly and in a more efficient manner.

Beyond all of this speculation though the fact is website builders can do what anything they want and most users won't know the difference so it really doesn't matter. My opinion to not use tables for layouts comes more from a desire for a standards compliant web then anything else.

[edited by: Demaestro at 8:48 pm (utc) on Aug. 20, 2008]

csuguy




msg:3727620
 8:53 pm on Aug 20, 2008 (gmt 0)


A couple more cycles imo does hurt. It puts more strain on the algo you even said so yourself.... multiply that small overhead on each site by the 1 billion unique URLs that Google has indexed, then times that by how many pages each URL and you can see why it is likely that Google would favor sites that do things properly and in a more efficient manner.

Did they say they favor divs? I've never seen anything official stating that - just CSS-Div only evangelist saying that its prefered. Say it enough and you'll start to believe too ;).

Anyways - what is a node? It's a little more memory used. But if it takes longer to parse the relevant data (memory) then its not saving any memory. Furthermore - css divs take longer to process because of all of the tricks that have been developed to try to trick search engines (like putting a div at the top of the body with visibility:hidden or display:none and then sticking all of your keywords in it for the bots). So - that single node really means nothing. And that's ALL it is - 1 node more regardless of the size of the table.

csuguy




msg:3727623
 9:00 pm on Aug 20, 2008 (gmt 0)


Beyond all of this speculation though the fact is website builders can do what anything they want and most users won't know the difference so it really doesn't matter. My opinion to not use tables for layouts comes more from a desire for a standards compliant web then anything else.

I'm all for standards. The problem is - as I've been saying in another thread - W3C standards are for the future. Like 10 to 20 years in the future once all of the non-compliant browsers have died off - and that's assuming IE suddenly becomes compliant. And that's just for pre-existing standards - not all of the new ones that are coming out. Their standards, most likely, will always be for the future. Which is necessary - as the standards need to come out before the support so that they can shape how to support each feature. The problem is most forget that - that standards come out before the support. Once you realize this you realize that you while ideal - you have to work with what is actually supported not what's ideal.

Herenvardo




msg:3727779
 1:49 am on Aug 21, 2008 (gmt 0)

If we're going to focus on search engines, then I don't think it really matters whether you use tables or CSS for layout: the people working for the major engines are not stupid, and they know both approaches are widely used, so they won't "punish" sites for choosing one or the other, as long as you do things right: do not write tag-soup or cryptic-CSS unless you really need it. And if you need, then you should probably re-think about your layout.

If you care about download & rendering times, in the age of multi-core GHz processors, DSL connections, and GB of RAM, the differences are hardly noticeable except for huge (1Mb or bigger) documents. If you are working with such huge files, you should consider even if html itself is for you.

From the theoric/semantic point of view, tables for layout are an aberration because the theory defines their semantics as something else (tabular data).

From the practical point of view, however, the question is not that simple, and there are two separate factors to keep in mind:

  • Cross-browser compatibility: the most used browser (MSIE) doesn't handle the table-related CSS properties; and the alternative approaches are not trivial. Making a CSS table layout work cross-browser can be quite painful.1 2
  • Authoring effort: given the current state of the topic, in most cases it will take significantly more effort to author documents using CSS than using tables (in the layout aspect; you should still use CSS for things like typefaces and font colors, and avoid the <font> tag). There is a exception, however, if you need to modify the contents (keeping the structure) of your html documents too often: in that case, the extra initial effort of using CSS might pay off in the mid-long term, since editing the contents will be easier thanks to the cleaner markup. Only you can find out what will better suit your needs.

In summary: the table approach has the main advantage of easier authoring, while the CSS approach gives you better semantics and maintability. Since both benefits are quite circumstantial, you need to ponder how they apply to your case before taking a choice.

I'm all for standards. The problem is - as I've been saying in another thread - W3C standards are for the future. Like 10 to 20 years in the future once all of the non-compliant browsers have died off - and that's assuming IE suddenly becomes compliant. And that's just for pre-existing standards - not all of the new ones that are coming out. Their standards, most likely, will always be for the future. Which is necessary - as the standards need to come out before the support so that they can shape how to support each feature.

There is a detail I want to share with you about this topic ;) I've read this very evening an interview with one of the CSS3 Working Group members at the W3C, who mentions how the W3C learned from the issue (lack of implementations) of CSS 2: since then, the "Candidate Recommendation" stage was added to the standarization process, which means that new specifications will at least count with two stable implementations before they have even a chance to become Recommendations. Also read my footnotes, it's quite related to your comment, 'cause it seems that IE is indeed sudenly becoming compliant. ;)

1Microsoft has stated that "The Internet Explorer 8 layout engine is built to be cascading style sheets 2.1 compliant, enabling web developers and designers to write their pages once and have them render properly across all cascading style sheets 2.1 compatible browsers." The new IE is still on beta stage, but that statement looks quite promising, and is worth keeping an eye on the topic for anyone soonly engaging in new projects.
2On the average case, I consider that trying to make a page render in older versions of each browser is not as good idea as it seems. Yes, on the first thought, they shouldn't simply "left out", but in most cases server-side content negotiation can be used to provide a fall-back (usable) page that allows them to access the content and encourages them to upgrade their browser; and in the meanwhile users who have upgraded will be able to enjoy sites taking the most of the newly implemented features. Keeping software up to date is always a good idea, and browsers are not an exception. While users might be unaware of this, we webmasters often have more than enough resources to raise awareness.

Regards,
Herenvardo

csuguy




msg:3727816
 4:07 am on Aug 21, 2008 (gmt 0)

If we're going to focus on search engines, then I don't think it really matters whether you use tables or CSS for layout: the people working for the major engines are not stupid, and they know both approaches are widely used, so they won't "punish" sites for choosing one or the other, as long as you do things right: do not write tag-soup or cryptic-CSS unless you really need it. And if you need, then you should probably re-think about your layout.

If you care about download & rendering times, in the age of multi-core GHz processors, DSL connections, and GB of RAM, the differences are hardly noticeable except for huge (1Mb or bigger) documents. If you are working with such huge files, you should consider even if html itself is for you.

From the theoric/semantic point of view, tables for layout are an aberration because the theory defines their semantics as something else (tabular data).

From the practical point of view, however, the question is not that simple, and there are two separate factors to keep in mind:

* Cross-browser compatibility: the most used browser (MSIE) doesn't handle the table-related CSS properties; and the alternative approaches are not trivial. Making a CSS table layout work cross-browser can be quite painful.1 2
* Authoring effort: given the current state of the topic, in most cases it will take significantly more effort to author documents using CSS than using tables (in the layout aspect; you should still use CSS for things like typefaces and font colors, and avoid the <font> tag). There is a exception, however, if you need to modify the contents (keeping the structure) of your html documents too often: in that case, the extra initial effort of using CSS might pay off in the mid-long term, since editing the contents will be easier thanks to the cleaner markup. Only you can find out what will better suit your needs.

In summary: the table approach has the main advantage of easier authoring, while the CSS approach gives you better semantics and maintability. Since both benefits are quite circumstantial, you need to ponder how they apply to your case before taking a choice.

I agree with all of the above. However, I would like to note - since the topic of server-side programming was brought up in the footnotes - that by using server-side includes to piece together pages (as I have described in a few other threads) a table layout can be made just as, if not more, maintainable than a CSS Div layout. I say more maintainable because as it currently stands CSS layouts are much harder to setup because of all the hacks involved - this will change with time of course. So - providing you have server-side programming - the only thing that CSS really has over tables is its correct semantics (which I never found to be a convincing argument by itself).


There is a detail I want to share with you about this topic ;) I've read this very evening an interview with one of the CSS3 Working Group members at the W3C, who mentions how the W3C learned from the issue (lack of implementations) of CSS 2: since then, the "Candidate Recommendation" stage was added to the standarization process, which means that new specifications will at least count with two stable implementations before they have even a chance to become Recommendations. Also read my footnotes, it's quite related to your comment, 'cause it seems that IE is indeed sudenly becoming compliant. ;)

Well I'm glad to hear it - that makes a lot of sense. Personally - I think they should make it 3 stable implementations which would completely ensure it would work on all browsers in use, but 2 is pretty stable.

But, again - even with IE 8 its going to take 10 to 20 years for IE 6 & 7 to die off. I also doubt that IE 8 will be completely compliant, but the fact that they are fixing the box model will go a long way towards fixing the most common problems. So - we have a lot to look forward to in terms of compatibility (at least as far as the current technologies are concerned) in the future. But, for the next 10 to 20 years tables will still remain a very efficient option.


2On the average case, I consider that trying to make a page render in older versions of each browser is not as good idea as it seems. Yes, on the first thought, they shouldn't simply "left out", but in most cases server-side content negotiation can be used to provide a fall-back (usable) page that allows them to access the content and encourages them to upgrade their browser; and in the meanwhile users who have upgraded will be able to enjoy sites taking the most of the newly implemented features. Keeping software up to date is always a good idea, and browsers are not an exception. While users might be unaware of this, we webmasters often have more than enough resources to raise awareness.

I disagree with this. It is the web master job to program according to the users - not make the users upgrade so they can see a prettier version of the site, especially when you can make it just as nice with a little more work. OR - better yet - program using slightly older methods so that it works for everyone with no extra work (tables :D). Furthermore, while some browsers can be run on just about any computer - IE6 is still recommended for XP. I have a 3 year old computer that runs XP - and I'm not going to replace it anytime soon. Nor are other people. IE 6 is going to be around for another 5 to 10 years. IE7 I don't think will last too long as IE8 is being made for current versions of Vista - but there will still be plenty of people who won't upgrade.

Personally - I avoid upgrades with a passion. I turn off automatic updates (except for FireFox - and even then it can get annoying). I know that FireFox 3 can be downloaded already - but I'm not going to upgrade until FF2 stops recieving support in December. Many people won't even upgrade then. And I'm not alone - MOST people avoid these upgrades, they like to stick with what they know and what works. If I had a choice, I would have gotten XP for my laptop instead of Vista.

I like the idea of raising awareness - but to do so at the expense of your clients isn't worth it.

Well I gtg eat :D
Ryan

Marshall




msg:3727870
 6:38 am on Aug 21, 2008 (gmt 0)

Many people won't even upgrade then. And I'm not alone - MOST people avoid these upgrades, they like to stick with what they know and what works.

As supported by analytics for most of my sites. 50% of IE users use IE6.

Marshall

Herenvardo




msg:3728012
 1:05 pm on Aug 21, 2008 (gmt 0)

So - providing you have server-side programming - the only thing that CSS really has over tables is its correct semantics

I can only agree with that as long as you only work with table layouts. I have made up some CSS layouts (which, by the way, work even in IE6) that wouldn't be possible throught tables nor, fot that matter, any other markup construct.

Many people won't even upgrade then. And I'm not alone - MOST people avoid these upgrades, they like to stick with what they know and what works.

I can understand that. The only issue is that people stick with what doesn't work. It may also depend on each site's topics and audience, and most often there is quite a paradox here: users don't expect online shops to give them security instructions, but visitors to these kind of sites should take more measures to protect their security, since they are most likely transferring sensitive data to the site (payment details).
Also, if you are working for somebody else, and they ask that you make a site "for IE6", then you have your hands tied. I used to work for a company that required me to make the sites work in IE4 (that was just 2 years ago), simply because the boss remembered it being the "main" browser in the market (our stats and logs, however, revealed that visits from IE5.x or earlier ammounted for less than 0.1% of our traffic).

even with IE 8 its going to take 10 to 20 years for IE 6 & 7 to die off

You seem quite sure about that, despite it doesn't match any real pattern: there hasn't been any browser version that lasted 10 years; but you are stating IE 6 will last at least 15 :o. Counting from the date when IE8 is finally released, I wouldn't expect more than one year for IE7 to extinguish, and maybe 2-3 years for IE6 to also die off. That still depends on how much should the usage % to drop to consider a browser to "die off": I know of some people who still run IE4, but I'm not targetting any of my web projects to support that.

Personally - I think they should make it 3 stable implementations which would completely ensure it would work on all browsers in use, but 2 is pretty stable.

2 implementations is required (but not guaranteed to be enough) for a Candidate Recommendation to advance to Proposed Recommendation. The PR then needs to be aproved by the W3C members (which include all the major browser makers) to become a Recommendation. This gives quite a good time-margin for a third vendor to trail up and implement the spec. And currently vendors are making good use of these margins... welcome to Browser Wars - Episode II! :)

It is the web master job to program according to the users

With a good design and structuration, it doesn't take too much extra effort to achieve a very smooth degradation: for example, IE6 users would see the best IE6 could render, while IE8, Opera9.5x or Firefox3 users would see the same contents, with some layout and formatting improvements here and there. After that, informing the users about the fact they are seeing a "limited" version of the site is up to each one, and it depends on your needs, target audience, and so on. My point is not to require users to upgrade (maybe I should have stated this more clearly), but to reward those who do.

Regards,
Herenvardo

Trace




msg:3728015
 1:12 pm on Aug 21, 2008 (gmt 0)

I agree with all of the above. However, I would like to note - since the topic of server-side programming was brought up in the footnotes - that by using server-side includes to piece together pages (as I have described in a few other threads) a table layout can be made just as, if not more, maintainable than a CSS Div layout. I say more maintainable because as it currently stands CSS layouts are much harder to setup because of all the hacks involved - this will change with time of course. So - providing you have server-side programming - the only thing that CSS really has over tables is its correct semantics (which I never found to be a convincing argument by itself).

I'm speaking only from my personal experience as I don't know the type of environment you work in, but that quote above would make my job, and others around me, a living hell. I'm starting to think that all of your comments are derived from working on small micro-sites, where as in my case, sometimes we're 20 or 25 people working on the same project.

Skipping past what the conception department comes up with and what the Architects have planned out, all the programmers are given either a module or a section of a page to develop. They have absolutely no interest in how it will look in the end, simply that it works as per the specs.

The integrators are then supplied with straight no nonsense markup to work with. If it weren't for the standards/semantics, their job would be impossible to do. They have no control over what the scripts are rendering. If they were expected to make anything other than tabular data work inside a table, the back and forth between the integrators and programmers would drive everyone mad.

It's only logical to have the data/content/information be laid out properly (read: correctly) and use the intended CSS to do what it's meant to do.

No one will ever convince me that using tables for structure is either acceptable nor profitable.

This 155 message thread spans 6 pages: < < 155 ( 1 [2] 3 4 5 6 > >
Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Code, Content, and Presentation / HTML
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved