Why do people wish for tableless with CSS?

Dan's is a good answer and implies the core reason. You do it for the same reason you live in a house, not a box; you drive a car, not a box; you have cereal for breakfast not a box. Things have names by which each of us is able to recognize what another is talking about. The html tags name the element for what it is. All UAs (browsers of any type) recognize the tags—because that's what UAs do—and each has a default way of rendering the content according to what it is and according to which attributes that element has.

cheers,

gary

 

Dan:

Thank you very much for that explanation. Greater accessibility is something I can always get behind.

However, since I have never used a PDA/Cell phone to view the web, I'm afraid I don't quite understand -how- this makes the page more accessible to them by using a list, rather than the <br> tag after the text, for example.

I'm also afraid I'm not to familiar with text readers.

If you can help me understand why a list is more usable for people using one of these technologies, I may be better able to avoid similar, but different errors in building in the future.

 

KK5st:

While I find the first part of your example rather condescending, I do get a bit of info from the last sentance.

To make sure I understand you right, the reason one should use a UL is because by doing so, you make it easier for the UA to render the information in a manner which the UA builder and the user (with UA settings) decided that would be most usable and functional for the user.

 

Sorry, the intent was not to be condescending, but rather to illustrate that html tags are names for the things they mark. Thus, a menu is marked up as a list rather than a box (div), because a menu is a list by definition.

Yes, but it goes further. With semantic markup, you could, for example, machine parse the page, pulling out particular information. That doesn't apply a whole lot to html, but, if, for example, you properly tagged all abbreviations and acronyms, a javascript could parse the page, create a glossary and append it to the document. You wouldn't have to worry about making changes, because the script can read your markup.

It is the power of xhtml and xml. Consider a simple catalog of CDs. It's a list and each list item has a CD title, and a sublist of cut titles and performers. Create an element for each, and the machine can parse it and select from it, and reorder it. You have an instant, addressable database. Without the semantic tagging, it's not doable.

You may see no need for it now, but call it future proofing. You or your client may need it someday, and it would be a Good Thing® not to need a rewrite of the pages due to neglecting semantic markup now.

cheers,

gary

 

The machine parsing is definitely interesting, I've got to agree.

But I don't see how I can justify using a block level element when a particular style of layout I have been ordered to use requires inline code only.

I dislike the list code because it arbitrarily defines how I get to lay it out. People keep talking about keeping layout and semantic separate... but unless I've missed some code that gets rid of the automatic newline, it seems like the industry missed this when they defined the behavior of list tags.

A list does not need to be one item on a line.

I want to get bread, milk, sugar, and eggs when I go to the store.

There. A grocery list all on one line.

By the same token, the copy of the menu at the bottom of the page is all on one line, and I don't think I should have to change that.

A menu is as much a navigational tool that should be oriented for the convenience of your intended audience as it is a 'list'. If you cannot create the tool as necessary using one set of html, it necessitates using a different set.

 

The point is, that you do use a single html markup. It is the style rules that determine the presentation. If you mark up the content to reflect how you want it displayed, you're missing the point. As to your examples,

ul {
    display: inline;
    padding: 0;
    margin: 0; /*for IE*/
    }
     
li {
    display: inline;
    }
=============== 
   <div>Please bring home 
     <ul>
       <li>milk, </li>
       <li>bread and </li>
       <li>eggs</li>
     </ul>.
   </div>

Code (markup):

and

ul {
    margin: 0;
    padding: 0;
    text-align: center;
    }

li {
    display: inline;
    }
============
<ul>
  <li>item 1 </li>
  <li>item 2 </li>
  <li>item 3 </li>
</ul>

Code (markup):

A div was required in ex.1 because p is not allowed to contain a block level element such as ul, and since the closing tag for p is optional in html, it is auto-closed when the parser gets to the ul.

For more on lists, see Listamatic.

Right now, Josh, you haven't enough experience with semantic and structural markup to grok all the benefits. Cutting corners has a certain appeal to the tyro, but doing so will mark you as a beginner or else a sloppy worker. It will at some time jump up and bite you on the butt, and you won't understand why.

cheers,

gary

 

Thank you VERY much for your examples, I shall treasure and use this code often.

As a note, well I asked several times if there was a way to change the display of a list to be inline, and no one said if there was or wasn't until I started assuming that there wasn't and used it as a 'point'.

The thing is, I -want- to improve my code. I -want- to do things the way they are supposed to be done. But sometimes the way things are supposed to be done and the way I am ordered to do them do not mesh, or don't seem to mesh. I ask if there is a way to get them too, and people don't seem to support the idea that -both- avoiding getting fired -and- doing things according to standard are -both- valid concerns that need to be balanced... and start telling me I shouldn't worry about presiontation until after the markup is finished. While that's all fine and good for those who know how to get whatever markup they use to look anyway they want using styles... I don't, yet. If I can do both at once I will always leap on that opportunity with joy.

I realize that part of my frustration comes with inexperience with the new code that is available to me since I started making pages again. I'm working on it. I will also agree that I am unexperienced and can't intuitively understand the benefits of doing things certain ways sometimes...

that's why if I don't get the benifits/reasons I ask again. And again. And again. Until I do understand, or figure it out for myself. I'll never Grok it unless I keep asking questions to expand my knowledge and experience by using different pieces of code, and also keep asking why that code is superior to other code that could also have accomplished somewhat similar results.

 

Anyone steeped in table layout has forgot or never learned to use semantic, well structured html. That makes the hardest part of converting to sane markup + css the (re)learning of html. Make that your first priority.

Also, see http://www.csszengarden.com/

cheers,

gary

 

Sorry I haven't been able to reply lately. My computer's been having some real serious issues.

Gary, thanks for covering my six for me .

 

Hope you got it sorted. That can be a real PITA.

No charge.

cheers,

gary

 

always try and use tableless... otherwise you'll be stuck in the 20th century

 

That's technically not even true. The earliest HTML documents did not use tables for layout.

 

but most sites built in the late 1990's were table heavy - just goto wayback and view the source of the 1999 Yahoo site!

 

using css is a professional way nowadays.
I am still using table, but I am considering switching to css, anyone can give my a stylish css tutorial site? so I can learn from scratch. Thanks

 

I've recently switched from tables to tableless, and it's so much better imo. Much more fun working with.

 

Finished a mini write-up of how CSS makes your content more accessible to search engines while you can still have a top, left and right navigations. Hope it makes sense on why CSS is good for SEO.

http://www.fatinfo.com/blog/2007/css-content-before-navigation/

Enjoy.

 

Okay... you give an example for the how, but I don't really see any reason for the why of having the content before the navigation.

 

Because it allows the search engines to see the content before the menu, which sacrifices usability for those who do not have CSS enabled in their browser (and I don't just mean traditional desktop browsers either, but also PDAs and Web-enabled cell phones).

Frankly I think the "content-first" model is just a bunch of hog-wash, but that's just me. But then again, I don't trust anything that relies on absolute positioning for layout, or uses the word "Levitra" as a captcha.

 

Hi Dan,

I'm mostly with you on the aspects of content first, though it depends on what else and how much comes before the content.

Take a look at the way I dealt with the issue in my home page (see sig). View in Lynx or Fx with styles off. I've tried to make the page easy to read and use. Well, not so easy with IE. I purposely didn't cater to IE's shortcomings, partly to demonstrate how much we're held back by that pig.

cheers,

gary

 

Not quite, the traffic from PDAs is neglijable.