Just to clear up a common misconception, one that seems to be at the root of every newcomer's approach to coding for standards, you do not use divs instead of tables. That's important enough to repeat, "you do not use divs instead of tables".

What do you use? You use well structured, semantic and well formed html instead of table layouts. A non-trivial table layout cannot be well structured nor semantic, though it can contain well formed (valid) html.

The div element is a non-semantic structural container that lets you form groupings of other, semantic, elements. Notice, I said elements. A div should never contain bare nekkid content, only elements.

These groupings provide independent styling contexts. Think of the div as a drawer in a chest. You can arrange and re-arrange the socks, handkerchiefs and underwear in one drawer (div) without affecting the contents of other drawers. Further, you can arrange and re-arrange the positioning of the drawers in the chest without affecting the contents of the drawers.

Keep in mind that the div is semantically neutral. It says nothing about what its %flow element contents are. Use the div only for its proper structural purposes. Replacing tables is not it.

cheers,

gary

Quote:A div should never

Quote:
A div should never contain bare nekkid content, only elements.

There are exceptions to this rule. As you say a div is semantically neutral and there are some who argue (like Tommy Olsson) that it should be used for certain types of content in the absence of another more appropriate tag. As discussed in this post on my site, the site's title could be considered a candidate for this.

Site titles spell confusion

How to mark up the site's title on an interior page does pose a dilemma or three. The site title/logo is obviously not the page's prime heading and should not be an h1. But what is it? The trouble with a div is that it doesn't impart any meaning at all. It is a good container, though. It could very well hold those tidbits that are included on every page but are not of the page, eg. links to sitemaps, style switchers, sign-in forms and the site title.

All these items belong in some kind of semantic and structural container. Including the site title. I've taken to using the p element[1] to contain either the text or the image of the title. Too, it is usually a link to the home page, which says to me "paragraph". I can't see removing the p, leaving "bare nekkid" content in the div.

There is one other element that has nagged at me as possibly appropriate, and that's the address. I'll not do more than throw that one out there. Smile

cheers,

gary

[1]

<div id="pageheader">
      <p><a href="../index.html" rel="nofollow">Gary <span class="kern">T</span>urner’s<br />
      <span class="light">html and css playpen</span></a></p>

      
    </div>
==============
#pageheader {
    border: 0 none;
    display: table;
    width: 60%;
    }

#pageheader p {
    color: #a00;
    float: left;
    font-family: georgia, serif;
    font-size: 2em;
    font-weight: bold;
    line-height: 1.2;
    margin: 0.67em 0 0;
    }

#pageheader p span.light {
    color: #669;
    float: right;
    font-size: .75em;
    font-weight: normal;
    }

#pageheader a {
    display: block;
    color: #a00;
    text-decoration: none;
    }

#pageheader hr {
    clear: both;
    height: 1px;
    color: #999;
    background-color: #999;
    margin: 0 0 0 2em;
    }

Divitis

Possibly a good time to point you to the divitis article?

http://www.csscreator.com/divitis

Gimme a min, gotta go un-encode all the carets Tongue

So you feel that the site's

So you feel that the site's title should carry the same semantic weight as any other paragraph of text on the site?

If you're on an interior

If you're on an interior page, the site title is informational. Consider a book, where at the top or bottom of the left-hand page there's the book's title. This is not the actual title, but a decorative informational datum.

Likewise, the h1 on a page is the title of the page, while the site logo/title at the top is informational and utile as a link back to the home page (usually).

Consider my home page. The title/logo is marked up as an h1. It is the title of the site and page.

Now go to one of the interior pages. That same title/logo is simply there as a decorative link back to the home page, and is marked up as a p. The primary header for that page has the h1 header.

cheers,

gary

Surely if it's simply

Surely if it's simply decorative, as you've stated, it should have no semantic weight at all, and therefore should be marked up as such, as a div.

I'd contest that the site's title is *either* part of the flow of the document or it isn't, depending upon you viewpoint. I don't think there's a right answer to this, as it's a matter of perception; whether you're looking at the site as a whole or as a collection of unrelated documents.

However, if it *is* part of the flow, then it's obviously going to be the highest level of heading.

If it *isn't* part of the flow then it needs to be marked up as such, in an element with no semantic weight at all.

Divs are more powerful

You know, just because you're used to using tables for layout practices, it has been stated by w3c that divs were meant to be used for webpage layout and tables never were meant for this. That said, div tags also hold to CSS standards better, and they take on CSS attributes in a more standardized way in most browsers. Now one can use either divs or tables to lay out their website, but you should not preach that one way is right and one way is wrong, however I will repeat what is true - divs are a much more powerful way to layout a website - after all their z-index feature makes it possible to put an element literally anywhere, without having to nest tables with varying alignment properties of diced graphics to get the "perfect" look. So you better get your facts straight before you start teaching false doctrine here. Also divs have flow properties. Also, this is a css website and tables don't fit anyway.

thanks,

Happy coding. I hope no newbies were tainted by this misconception that divs are the enemy - it really boils down to user choice, and once more - divs are much much much more powerful than tables. That's one reason why they were created, namely for webpage layout.

Nathan

Nathan as a first time

Nathan as a first time poster I think that you have come on a little strong in your comments, actually far too strongly you are trying to argue with people who have a very strong grasp of standards based coding and I'm afraid many of your remarks are very ill informed; divs do not hold to css standards better than tables this is a meaningless statement both adhere to standards, depending on browser implementation.

I suggest that perhaps you re-read the entries in this blog post, as I think that you may have got the wrong end of the stick, as it is not a debate about Tables VS. Divs, I don't see any mention of tables other than in the original post at all, to whom are you talking when you state "just because you're used to using tables for layout practice" or "So you better get your facts straight before you start teaching false doctrine here." who had better get their facts straight?? if you are referring to KK5st then be assured he does know his tables from his divs , the point of his post was to attempt to explain the misconception that Divs replace Tables which is a common error when people transition from tables to full CSS-P this is because what they haven't grasped is how to code HTML correctly and are not really used to semantic elements and still believe that they must wrap everything in divs much in the way a TD wraps content.

Sorry but you have misunderstood the nature of the post entirely and your comments for a first time poster are far too vitriolic and emotive!

Yes this is a CSS forum most of us are well aware of that Smile and we preach a standards based approach to all web coding practises and there are few that understand these issues better than this long standing forum member Smile I would suggest that best practise in forum activity should be observed , namely to lurk and read as many posts as possible in order that one understands the nature and quality of posts in that forum and to get a feel of which members have a good grasp of the subject that they hold fourth on.

Please read posts carefully before jumping in with comments, but regardless welcome to the forum if you hang around you will learn a lot about standards based coding and how z-index works and why not to use absolute positioning!

Hugo

natelane wrote:So you better

natelane wrote:
So you better get your facts straight before you start teaching false doctrine here.

It always helps when you tell people to get their facts straight that isn't you who comes off looking like the one who doesn't know what they're talking about. :/

This may be a bit

This may be a bit disjointed, as your points have some overlap.

jetboy wrote:
Surely if it's simply decorative, as you've stated, it should have no semantic weight at all, and therefore should be marked up as such, as a div.

You're ignoring the structural aspect of html, and I'll try to remember to get to the semantic aspect. Let me quote from Webster's dictionary,
Quote:
  1. A distinct part of a discourse or writing; any section or subdivision of a writing or chapter which relates to a particular point, whether consisting of one or many sentences. The division is sometimes noted by the mark[¶], but usually, by beginning the first sentence of the paragraph on a new line and at more than the usual distance from the margin, also called indenting the line.

  • A brief composition complete in one typographical section or paragraph; an item, remark, or quotation comprised in a few lines forming one paragraph; as, a column of news paragraphs; an editorial paragraph.
  • Definition (0.) dealt with the ¶ character.

    Note that there are both a structural aspect, "… a composition complete in one typographical section" and a semantic aspect, "A distinct part of a discourse or writing; any section or subdivision of a writing or chapter which relates to a particular point, whether consisting of one or many sentences." Either or both would apply to the examples I cited.

    Quote:
    I'd contest that the site's title is *either* part of the flow of the document or it isn't, depending upon you viewpoint. I don't think there's a right answer to this, as it's a matter of perception; whether you're looking at the site as a whole or as a collection of unrelated documents.

    However, if it *is* part of the flow, then it's obviously going to be the highest level of heading.

    If it *isn't* part of the flow then it needs to be marked up as such, in an element with no semantic weight at all.

    Don't confuse document flow and narrative flow. These asides, if you will, are part of the document, but not necessarily a part of the narrative. That is, they do not fit within the structure of the narrative, but they do fit the structure of the document. Even something as terse as a page number fits the definition of a paragraph, but is not a part of the narrative and is not a heading for the page narrative.

    Using the book metaphor again, imprinting the book's title atop the page does not make it a meaningless bit of ink. It is, by definition, a paragraph, and in no way does it qualify as a header. Now back to my web pages. The site name is not a title on the interior pages. They have their own. It is a paragraph and link back to the title page, index.html, where the same name and layout is used as the page title, because it is.

    Look at those pages with styles turned off. The semantic and structural differences will become more obvious.

    cheers,

    gary

    kk5st wrote:Using the book

    kk5st wrote:
    Using the book metaphor again, imprinting the book's title atop the page does not make it a meaningless bit of ink. It is, by definition, a paragraph, and in no way does it qualify as a header.

    I think the dictionary definitions of what constitutes a paragraph are a bit open to interpretation, particularly the part about what constitutes a single idea or point. For example, you say the page number can be a paragraph; I wouldn't. What is it? I'm not quite sure, but the range of written content must be able to be defined as more than just headings or paragraphs.
    If you take the definition that a paragraph must include at least one sentence then page numbers and book/site titles are not paragraphs because they're only fragments of sentences.
    A title, to me, is a title. In some cases, it's a heading (front of site/book), but when it's not, I don't see it being a paragraph which is why when faced with which tag to use and find there's not really an appropriate one, you maybe have to fall back on the one that makes no suppositions about the type of content at all.
    I'm probably making a rod for my back with this sort of approach though cos if I were to follow it through, I'd mark up lines containing dates or author's names with something other than <p> too because I don't really view them as being paragraphs either.

    Huh?

    @ natelane:

    I have no clue what you can be talking about. If it is my blog post, I suggest you re-read it. You have completely missed the boat.

    And one more point, tables were introduced in html 3.2:

    Quote:
    HTML 3.2 includes a widely deployed subset of the specification given in RFC 1942 and can be used to markup tabular material or for layout purposes. Note that the latter role typically causes problems when rending to speech or to text only user agents.
    (emphasis added)

    That table layouts are a bad idea does not negate the fact that use for layout was clearly an enate intent.

    I look forward to your revised comments once you've found enlightenment.

    gary

    Hi Tyssen, I thought the

    Hi Tyssen,

    I thought the definition cleared up a lot of ambiguities. See #2 in particular. There is no mention of sentences, but there is mention of an item. Combine that with the bit about a typographical section, and the page number clearly (to me, at least) fits.

    If it's not a semantic fit for you, it should at least be a structural fit.

    cheers,

    gary

    kk5st wrote:I thought the

    kk5st wrote:
    I thought the definition cleared up a lot of ambiguities.

    I actually think it creates ambiguities with regards the point you're trying to make about whether sentence fragments constitute paragraphs:

    Quote:

    A distinct part of a discourse or writing; any section or subdivision of a writing or chapter which relates to a particular point, whether consisting of one or many sentences.

    A brief composition complete in one typographical section or paragraph; an item, remark, or quotation comprised in a few lines forming one paragraph; as, a column of news paragraphs; an editorial paragraph.

    I have to agree with Tyssen:

    I have to agree with Tyssen: Your dictionary definition doesn't seem to back up your argument at all. If anything, it undermines it.

    You seem to be saying that if any document text doesn't have an appropriate HTML tag, then it must be a paragraph, regardless of its actual purpose. Surely you can see that this argument is flawed? A paragraph element is not a 'default' container.

    I love these discussions I

    I love these discussions Wink

    I think it safe to say this in one area where there isn't a definitive answer. Depending on your outlook, you may lean more one way or more another. The inherent flaw is the lack of elements in HTML.

    Both <p>www.mysite.com</p> and <div>www.mysite.com</div> by themselves convey very little meaning. It is only by associating the content with other cues and common practices that we know it is meant to be indicative of the current website.

    Personally, I'd go with the <div> and reserve <p> for use as part of the narative content. If you were to be truly pedantic (anal?) about this why not ...

    .label dt { /* your favourite content hiding styles */ }

    this site
    www.mysite.com

    Smile

    Let me preface this, and I

    Let me preface this, and I should have given it more emphasis early on, by saying the article is aimed at the newcomers to modern html+css layouts. The more experienced coder may have a rationale for divs holding nekkid content.

    In the main, I see no reason to do so.

    jetboy wrote:
    I have to agree with Tyssen: Your dictionary definition doesn't seem to back up your argument at all. If anything, it undermines it.

    You seem to be saying that if any document text doesn't have an appropriate HTML tag, then it must be a paragraph, regardless of its actual purpose. Surely you can see that this argument is flawed? A paragraph element is not a 'default' container.
    Look again at the cited def:

    Quote:
    A brief composition complete in one typographical section or paragraph;
    Would you feel better if one wrote "this is page 3"? Doesn't "page3" as a sentence fragment represent a complete composition in one typographical section? Again from my website, isn't "Gary Turner's html & css playpen" a complete composition in a typographical section?

    Further, the W3 implies (or do I make an unjustified inference?) the div is a structural container having no semantic value.

    Is the p the default container for any content not otherwise better defined? Hell, I don't know. It will likely do for all that I've come across[1]. To me, a bit of text requiring a typographical context is crying out for <p> and </p> to snuggle up to either side.

    @ Chris: Possibly. I threw out the idea of using <address> as a container, too. I still feel the p is the more semantic and structural. So much of communication, especially in English, is implied on the one hand or inferred on the other and understood on the third hand (see Niven and Pournelle). As you say, a very moot point.

    cheers,

    gary

    [1] A likely exception would be an image of no consequence and having no alt text, that is, purely decorative. But then, I'd have to wonder why it's there at all.

    In the case of decorative

    In the case of decorative elements, which I use in my site, I merely use two empty divs. No excessive markup, they're not seen at all when styles are disabled, they simply serve as a place to put decorative images for the site.

    Gary, I have thought about

    Gary,

    I have thought about this a whole lot more seriously after I made the above comment (I had a long walk to lunch Smile) and I have changed my mind and now agree with you.

    Tags in themselves don't give any meaning to content. They can simply describe it. By that reasoning textual content shouldn't really be placed nekkid in a <div> as it should be a something or other and <p> is the basic element when text can't be better described as something else.

    That leaves <div> to be purely structural or used in the odd case, as mentioned by TPH, when there is no meaningful content.

    Chris..S wrote:<p> is the

    Chris..S wrote:
    <p> is the basic element when text can't be better described as something else.

    Is that something that's stated by the W3C or based on personal opinion?

    Definitely an opinion. As I

    Definitely an opinion.

    As I said in my earlier post, I don't believe there is any right or wrong (at this time), just some people leaning more one way or another. And that after thinking about it after my first post, I have jumped ship from using a <div> to use a <p>

    I started off using

    I started off using Hx elements, but when I progressed onto source-ordered layouts, with the header below the content, it really didn't make any sense semantically to have an H1 at the bottom of the document.

    I then started using Ps instead, utilizing image replacement to embed anchor text, with the site logo as a background. However, if I wasn't using image replacement, I'd have just used an IMG element with an A around it.

    For both of the above, I was changing the semantics of the page because of the way I'd chosen to implement it, which certainly isn't best practice.

    Now I view the pages in isolation, with the first heading of the page copy as the H1, and treat template items like the phone number and the site title as meta data. This allows me to build pages in a number of different ways without altering the semantic structure of the document.

    The W3C states states that DIVs "... offer a generic mechanism for adding structure to documents. These elements define content to be inline (SPAN) or block-level (DIV) but impose no other presentational idioms on the content.", whereas "The P element represents a paragraph."

    As such, if the site title etc. are not considered to be part of the semantic document, the choice of a DIV seems obvious.

    It works for me. It's not the only way, but I feel it's a logical and defendable viewpoint. It may seem like I've given kk5st a hard time, but I was really interested to see whether their methodology was based on anything concrete; firstly because it was being cited as best practice, and secondly because I'd been down that route myself and was wondering whether my decision to move away from using Ps was incorrect.

    You make some good points;

    You make some good points; some representing a path we all take to one degree or another. There are a couple of things I'd like to expand on or just plain reiterate.

    jetboy wrote:

    … and treat template items like the phone number and the site title as meta data.
    A good expression.

    Quote:
    … The W3C states states that DIVs "... offer a generic mechanism for adding structure to documents. These elements define content to be inline (SPAN) or block-level (DIV) but impose no other presentational idioms on the content.", whereas "The P element represents a paragraph."

    Which is exactly why unmarked up content does not belong in the div; spans are different animals. The div is structural only and does not describe its content.

    Quote:
    As such, if the site title etc. are not considered to be part of the semantic document, the choice of a DIV seems obvious.

    The site title, if not used as a title, but as meta data, i.e., the name of the site, still has a substance that the html markup should describe. As Chris said, the markup does not determine what the element is, it describes what it already is. The div does not provide any descriptive meaning for its content. It is a structural device only.

    This is where the dictionary definition of the paragraph comes into play. Using the part of the definition that seems to best apply, "… a composition complete in one typographical section", we can now describe the meta data as a complete composition, or thought or informational bit in a single typographical section, a block structure. And, that's what the paragraph tag is about. If it does nothing else, the p says "this is a block of text or text substitute".

    Quote:
    It works for me. It's not the only way, but I feel it's a logical and defendable viewpoint. It may seem like I've given kk5st a hard time, but I was really interested to see whether their methodology was based on anything concrete; firstly because it was being cited as best practice, and secondly because I'd been down that route myself and was wondering whether my decision to move away from using Ps was incorrect.

    Your view is certainly defensible, and you have allies such as Tyssen, who agree with you. I'm not familiar with your skills, but I know Tyssen to be a thoughtful and experienced html coder whose opinion should be respected, so you keep good company.

    I am convinced my own views represent Truth, Justice and the American Way and will prevail throughout the lan… um, never mind.Smile

    cheers,

    gary

    kk5st wrote:Your view is

    kk5st wrote:
    Your view is certainly defensible, and you have allies such as Tyssen, who agree with you.

    I'm still not totally decided to be honest about what is best. It seems to me a case of picking the least worst rather than the best option. The notion of using divs actually arose out of a discussion on Sitepoint about this issue and the advocate there was Tommy Olsson of Autistic Cuckoo.

    To jump back aways to the

    To jump back aways to the title of a page holding weight. From the view of accessibility, if your page is some article, the H1 should be contributed to the actual title of the article and not the website title. This is because at these inner sections, what's more important, the website or the article...the article. You can contest this and say accessibility says that the first text on a page is an h1 tag, and that's the website title. But if you are needing a screenreader, you find the h1, and next you get all the nav stuff...not too useful. Hardcore accessibility people say there should have an [hidden] skip to content anchor so that the article title gets the h1.

    The only omni-applicable

    The only omni-applicable argument "for" and "against" the use of tables is browser compliance - do they treat them well? If the answer is yes, then there is no real reason that we should not use tables - that choice is a question of a) use and b) taste.

    Myself I've gone the rounds in the quest for the holy "three column div layout" grail and found it, and even improved on it (liquid layout), but I'm increasingly tempted to go back to tables for some uses, namely basic page structuring. If your page is going to consist of three columns, then, in my experience, there is nothing simpler then setting up a three-column table and filling that with

    's and "lower-structure" content. Frankly the acrobatics one has to go through to get a working three-column layout that works in all browsers is a bit outrageous for anyone less than a
    perfectionist - Frankly, for setting basic page-wide structure, I don't think the (
    css) technology is the best yet.

    Your experience and mine are

    Your experience and mine are at odds. That simple three column table doesn't allow for source order without some ugly hacks that do, indeed, give the table its bad name as a layout tool.

    Further, table layouts cause the DOM to improperly reflect the structure of the document. Scripting against that DOM causes non-intuitive references.

    It's not the table structure that's advantageous, it's table-cell rendered behavior[1] that you're going for. The disadvantages of tables for layout do not outweigh the neat things that table-cell displays allow. We'll just have to wait for IE8, or IE9 or, um, 10? 11?

    cheers,

    gary

    [1] See the "modern" layouts on my playpen site.

    I do agree...

    I do agree with your "main content first" point about "wrapped" <div>'s instead of tables - nothing thus far can beat that in that respect - but one cannot say that such a layout is easy to create/maintain/modify as a table is. A table is treated more consistently across browsers - <div>-rendering behaviour is only beginning to become standardised by all. Tables are still part of the XHTML DOM, even strict as far as I know.

    For the time being, since I have already done the work to create/develop a working 3-column <div> layout, I'm pretty divided. The "content-first" argument is a strong one though.

    more powerful indeed?

    natelane wrote:

    Happy coding. I hope no newbies were tainted by this misconception that divs are the enemy - it really boils down to user choice, and once more - divs are much much much more powerful than tables. That's one reason why they were created, namely for webpage layout.

    The power of divs is what gets many people in trouble. And what you still cannot do (to my less-than-perfect knowledge) is put 4 (or many more) divs in a ('scuse me for saying this, and please tell me a better word) "tabular" layout, place a twisty tie on two or four corners, and say "OK, you guys are to stick together no matter what" - and have it obey. No need to specify negative margins, no need to hack browsers, no need to specify similar widths and heights in multiple places - a developer's NO-NO. To my understanding, that's powerful - and to my knowledge impossible or clumsily implemented with divs. And, in many cases the point is that that is the power that I might want.

    As I've developed more in CSS I KNOW the things you can do with divs - but that one simple thing in the paragraph above is usually what I need to do in certain layouts and it behaves 100% consistently, no extra coding. What has always disheartened me is people who judge a perfectly valid use of code and would even refuse to give assistance if the word table is mentioned.

    samf wrote:place a twisty

    samf wrote:
    place a twisty tie on two or four corners

    What's a twisty tie?

    A twistie is..

    Forgot most of you are Aussies Smile A twisty tie is that thing that keeps the bread wrapper closed (the old metal wire coated with paper). Basically, the corners are wired together. Here in this example:


    cell 1

    cell 2



    cell 3

    cell 4

    the adjoining corners of cells 1-4 are tied together - I don't have to specify a width or height but for one cell. And it's robust. When CSS can do that without hours of debugging, I will gladly abandon tables for all but semantic data. Cheers, mates!

    samf wrote:Forgot most of

    samf wrote:
    Forgot most of you are Aussies Smile

    I am but I don't think there's actually that many of us on this board. Wink

    I have no clue why you want

    I have no clue why you want that construct, but this is a bit less markup;

    <div id="wrapper">
      <div><!-- cell 1 --></div>
      <div><!-- cell 2 --></div>
      <div><!-- cell 3 --></div>
      <div><!-- cell 4 --></div>
    </div>

    Now, without touching the content or markup, I can lay it out as
    1 2
    3 4
    or
    1 3
    2 4
    or
    2 1
    4 3
    or
    3 1
    4 2
    or … 

    Well, you get the idea.

    The problem isn't with the use of css and well structured, semantic markup, it's that you haven't reached a comfort level with it that you have (after much work) with tables and their idiosyncrasies and some of the most gawd-awful hacks ever devised this side of the Spanish Inquisition.

    CSS is very powerful, and like powerful languages, there is a learning curve. The sheer number of choices you must make can be daunting. But give it at least the effort you put into mastering tables, and the reward will be there. I'll say straight out that on any non-trivial page, it takes only half the time to code with css as it takes with table markup.

    cheers,

    gary

    el pesado

    yo soy nelson el pesado

    Well, yes, the <div> setup

    Well, yes, the <div> setup has two tags less code, but you're of course forgetting all the CSS needed to make them stick in place where and how you want them.

    FWIW, I've stuck with the 3-column <div> layout, but only for its "content first" attributes. If it were only a question of a solid cross-browser layout skeleton, a three <td> table would win hands down. In fact it would win (as a structure skeleton) in every aspect than that I've mentioned above. CSS - led <div> layout is not "there" yet, and it is still a developing technology.

    Lots of CSS? You're kidding

    Lots of CSS? You're kidding right?

    For simplicity assume each div has a class of "cell" and an id of "cellx" where x is the cell number (increasing left-right & top-bottom).

    #wrapper .cell { float: left; width: 50%; }

    #cell3 {
    clear: left;
    }

    That's a lot? Wink

    Now now let's not be oversimplistic.

    Now now let's not be oversimplistic. If you expect a 3-column <div> layout to behave like a three-<td> table, as in the whole stretching vertically with the longest column with everything "floating" properly into place no matter what browser you're using, you're going to need a lot more code than that.

    Sorry, that CSS is for the

    Sorry, that CSS is for the twisty-tie problem. Smile

    Still 3 column CSS isn't exactly complex either. I'll grant you tables cells do make setting columnar backgrounds easier. But setting up HTML/CSS for a 3 column page once and reusing it isn't that difficult either.

    I'm sorry, but...

    ...there is no arguing that a properly-behaving three-columned <div> & css'd layout behaving as a three <td>'d table needs much more code than the latter and is more difficult to manage/transpose than the same.

    I still think you're not

    I still think you're not trying hard enough. A few bytes more or less code is immaterial in the long term. The advantage of a properly configured div layout is it might be a three column layout, but it could just as easily be a two column or a one column layout. Try that with a table!

    Fine then: If it's possible...

    Create a 3-column <div> / CSS layout that behaves exactly the same way as a 3-column <td> table - in all browsers - and present it here alongside the code for that 3-<td> table. Then you'll have a solid argument, and we can see the evidence for ourselves.

    Um, who made the way tables

    Um, who made the way tables happen to behave the be-all and end-all? Why should a CSS three column layout have to emulate a 3 column table layout exactly in every respect?

    Anyway the original point to this thread was that simply replacing tables with divs is a pointless exercise in the first place. What counts, IM(NS)HO, is the content. Designing to a certain layout irrespecitive of the actual content seems rather silly to me.

    Don't people go to websites for content? If so shouldn't the layout be the one that most effectively exposes the content for easy use by the visitors? How often is a rigid three column layout the best way to do that?

    How about we give this "you can never do that with DIVs" "Yes I can" tit for tat a rest, eh?

    Ed Seedhouse wrote:... How

    Ed Seedhouse wrote:
    ... How about we give this "you can never do that with DIVs" "Yes I can" tit for tat a rest, eh?
    I second the motion.

    To return to the point,

    ...it was to say "tables are good for some things, <div>'s are good for others". To be most effective, one must rely on reason and experience in choosing which to use - stubborn puratinism is not this. I was a "<div> purist" myself until only recently.

    Separation of structure, presentation and behavior

    The real issue with css is implementing the principal of separation of structure and presentation. HTML is the structural layer and css is the presentational. Add javascript into the mix as the behavioral layer.

    The idea is that no presentational code should be mixed with the structure. Using html markup in the form of a table for layout, no matter how simple, breaks the paradigm. In a pragmatic sense, I have no large issue with a simple flat table to lay out the major columns. The approach works right up until someone decides the left column is better on the right and vice versa.

    As Ed mentioned, the original intent of the article was to point out a css-newcomer's tendency to try to make a div for cell or div for table replacement, and to try to show the way to true enlightenment—it is not a search and replace operation. Proper structural markup is the key, and presentation is added later. Judging from the directions the comments have gone, I was not all that effective. The comments have been much more interesting than my original post.

    cheers,

    gary

    Just lurking

    I have enjoyed reading this thread. Smile Welcome to Hugo et al. Smile

    Hi Root, very long time no

    Hi Root, very long time no see! still dabbling with WP