Why do people wish for tableless with CSS?

I've always wondered why, I found an answer in bandwidth economy, but other than that, how do they expect us to do it? With padding?

 

using divs will work I can do both with a nice little css styling all goes good. there can be a number of reasons for it one is for SEO

 

I'm trying to switch to css as much as I possibly can. So far, I haven't see much that css cannot do that is done with tables. It really is pretty cool stuff.

 

It also makes pages load faster because of less code as well as other reasons.

 

So basically instead using <table> you use position:absolute; and you declare left/right whatever? What happens to resolution then? :|

 

Tables are like IE. Outdated.

 

You can also set the size

 

It's much more accessible for search engines and users themselves. One of the main reasons is less markup, and loading speeds. Tables are read twice actually, once for structure, and another for the content, making them much slower.

Also, tables are for tabular data and were not originally meant for layouts.

 

As Andrew touched upon, tables are for tabular data; using them for laying out your Web site goes against their meaning and purpose.

As for using position: absolute; to lay out a Web site, that's really not the best way to go about it. Using a a combination of floats and margins (sometimes negative margins) is the best way to go about it.

Also, do not fall into the trap of replacing tables for DIV containers. Each element in HTML has a purpose, and should be used as such. For example, a menu is a list of links, therefore it should be marked up as a list. A section header is nothing more than a heading. Use a heading tag (H1-H6, accordingly) instead. Also, in the case of headings, you should only have one H1 tag in your page. This tag is to be used for describing what the page is about (though I often use the site title instead, since I use it to act as a hook for the site's logo/branding). The other heading tags should be used to describe the various sections of each page.

Paragraphs are blocks of text that deal with a particular topic or subject matter, therefore they should be marked up as such. Using a paragraph element to lay out your form is unacceptable, since the form is not a paragraph (again, getting into semantics).

When using CSS based Web design techniques, it is best to use the bare minimum of HTML code to get the job done; don't go overboard on DIVs, SPANs, classes and IDs. If you do, you're going to run into problems when it comes time to style your document.

 

Okay, a couple of things here.

First of all, thanks for the information on the h1/h2 ect thing. I was under the impression up until today that they were just different styles of headers that could be used at the person's preference.

If a page title and multiple H1 are used on the page, is preference given title for the subject of the page, or are they all given equal preference, thus making it harder to determine the main subject matter?

As for lists, in my experience it seems that lists are not represented well cross-browser. Or, at least, I haven't found enough of the elements with different defaults cross browser, to make sure I get good cross-browser display. So I've shied away from using lists when I need a particular display, and instead just tend to use a wrapper div, and then a br to break the line after each link.

I'm sure this isn't the best method, but at least I'm confident it's a touch better than a full on table replacement with divs.
If you knew of a way to get rid of the bullets in a UL, and what all the defaults I'd need to specify that might be helpful... but then wouldn't that be a lot of extra code to load?

 

So basically, for the image layout, which tag should I use, the <div> with background-image: attribute, or other?

 

Header levels imply semantically the depth within the structure of the document. It's analogous to a document outline.

• h1 level
  • h2 level
  • another h2 level
    • h3 level
      • h4 level
        • h5 level
          • h6 level
          • another h6
        • h5 again
    • h3 again

At the top level is h1. Below that is h2, etc.. You should never have a higher level as a descendant of a lower level.

Lists are actually very dependable cross browser. You must keep in mind the Opera and IE use left margin on the list to set the indention. Firefox and Safari/Konqueror use left padding. If you want an indention other than the default 40px, set either the left margin or padding to the desired value, and zero the other.

To lose the list markers, set {list-style: none;} on ul. See previous answer for defaults.

cheers,

gary

 

Thanks Gary!

Now to me this brings up the question of if there is any particular reason to introduce all of the extra code for a UL when one can format the text into a list just fine without it.

 

Because the purpose of the tag is to describe the content. Nothing but a ul, ol or dl says this is a list. Nothing but a li says this is an item within a list, and nothing but a dt says this is a term and the dd is the definition of that term.

You could use totally non-semantic markup, but, why would you? By the time you allow for DOM scripting and css, you will have had to create as many tags and and even more presentation rules and classes and ids.

For people moving from table layouts to css-p, the most difficult hump to get over is (re)learning well structured and semantic html. Nontrivial table layouts can be neither well structured nor semantic, so you've forgot whatever you once knew about it.

cheers,

gary

 

The very first thing I do when I create a CSS based layout (after coding the HTML markup), is to remove the margins and padding from nearly every element in the page. I know I'll have to go back and manually add margins and padding afterwords, but this does give me (literally) near pixel-perfect control over everything on the page.

I put this little bit of code at the very top of my stylesheet:

* {
    margin: 0;
    padding: 0;
}

Code (markup):

 

Actually, in a page I've been working on, I only had 2 styles that created the menu and they were ones I would have had to have created anyway. The link and link hover. I just used a background image to the left of the links, inside the padding, and the added benefit was that I could change the bullet image on hover, and with less style and in-page html code total than when I tried a UL.

Again, I may be missing it, but what is the purpose of having the semantic markup of a list for a menu? I understand having a list in the content as a list, for the purpose of making the page easier to crawl and index, now that you explained that, but what is the benefit (or lack of drawback) to having the menu as an actual -list-?

And out of curiosity, is there a way to change the button of a li on hover when one hovers over the contents of the li?

 

As for the margin code, I've got to say I'm disapointed in myself that I didn't think of putting it in my own CSS without being told. It seems like a simple, but incredibly useful little tool that I am definitely going to include the next time around (perhaps even when I do some editing on pages I've already worked with).

 

Think of it as best practice. You don't have to be semantic, but I can't see your point at all. If you want to appear unprofessional, ignore structure and semantic markup that is html. Else, mark up the content for its structure and meaning, without regard for presentation. Then add the presentation layer.

If you've been using tables for layout purposes, the proper use of html to define structure and semantics was not possible; you'll have to relearn the proper function of html to create professional grade documents with html+css+javascript.

cheers,

gary

 

I am trying to figure out why using a list for a menu is 'good' and using any other kind of code is 'bad' in your opinion. I do not understand the reasons, or benefits of 'semantic mark up' and am asking that you explain this. You said that using UL and LI would result in less code. I showed that in some circumstances it does not, and have asked for an explanation of why "semantic" markup is better than "non-semantic" markup for tool that are not a part of the actual content of a site.

 

Because not everyone is using a regular Web browser to view Web pages. Some people will use a screen reader, others are on Web-enabled cell phones and PDAs that do not have complete CSS support. Having the markup as a list for these people greatly improves the usability of the Web page .