PDA

View Full Version : Moving from Tables -> CSS

Fatman
05-16-2003, 10:36 AM
I have the following table row which im using


<TR>
<TD><a href="/Code/">Blah</a></TD>
<TD><a href="/Code/find.php">Blah</a></TD>
<TD><a href="/Code/forumindex.php">Blah</a></TD>
<TD><a href="/Code/rembann.php">Blah</a></TD>
<TD><a href="/Code/links.php">Links</a></TD>
<TD><a href="/Code/contact.php">Contact</a></TD>
</TR>


now im trying to use Div layouts instead.....

erm how?


Ervyrthing i try doesnt work :)

fatman
ronaldb66
05-16-2003, 12:20 PM
How do you want your links to look, and how should they line up? If you want a horizontal nav bar, simply place all your links in a container element (could be a div) and align the container and its contents as desired. If you want to space out your links over the width of your page, make the width of the container 100%, and give the links a set percentage width (do account for margins, etc.), roughly 100% / no. of links.
In any case CSS can be used to style the links themselves.
pardicity3
05-16-2003, 01:01 PM
Or you could use a list (http://www.alistapart.com/stories/taminglists/) to line up your links.
ronaldb66
05-19-2003, 11:55 AM
Even better! Shame they've been "on holiday" for so long already... I myself have been tinkering with lists for navigation and it's definitely a viable option, provided you slap some CSS in.
Fatman
05-19-2003, 04:34 PM
i have discovered a viable option using lists :)

thanks for all your help

fatman
zoobie
05-20-2003, 09:53 AM
No need to bloat your code with css...I made the same menu made with css featured @ a list apart (http://www.alistapart.com/stories/taminglists/) 33% smaller using a table.

CSS = 1250 bytes
Mine = 844 bytes

As I always suspected, css is just another way to display...not necessarily better. For example, you must know each and every browsers particulars. You just can't sit down and get it right. Many hours of research and workarounds must be made. I've always wondered why they said css was more compact...since the code always looked bloated. Turns out, it is. :D

<html>
<head>
<style>
a {
padding: 5px 5px 5px 5px;
border-left: 10px solid #1958b7;
border-right: 10px solid #508fc4;
border-bottom: 1px solid #90bade;
background-color: #2175bc;
color: #fff;
text-decoration: none;
width: 100%;
font:bold 16 tahoma;
}
a:hover {
border-left: 10px solid #1c64d1;
border-right: 10px solid #5ba3e0;
background-color: #2586d7;
color: #fff;
}
</style>
</head>
<body>
<table cellspacing=0 cellpadding=0>
<tr><td>
<a href="#">Home</a><br>
<a href="#">Hidden Cameras</a><br>
<a href="#">CCTV</a><br>
<a href="#">Employee Theft</a><br>
<a href="#">Helpful Hints</a><br>
<a href="#">F.A.Q</a><br>
<a href="#">About Us</a><br>
<a href="#">Contact</a></td>
</tr>
<tr><td height="20" bgcolor="#90bade"></td>
</tr>
</table>
</body>
</html>

You shouldn't believe everything you read, guys. "Dewey defeats Truman" comes to mind...:cool:
ronaldb66
05-20-2003, 10:41 AM
This just shows that you don't get the point of seperating presentation from content, let alone using sematically correct elements for structuring that content.
Non-compliant browsers are a pain in the b... neck, and should be considered, but they in no way justify misusing tables for layout, and saving a skimpy 406 bytes certainly doesn't.
zoobie
05-20-2003, 06:49 PM
Well, there's nothing "wrong" with my table...or else it wouldn't display properly in all browsers. This is just another example of geeky trends in coding...right up there with bulletin boards and databases of a year ago...just something else to learn. Remember, you have to use this and that css for this and that browser.
Even by making my table "semantically correct" (geek talk for using <tr>'s and <td>'s), it's still 25% smaller than the css. So, if you have a slow-loading page 2 or 3 screens high and expect css to quickly load it for you, you'll probably achieve the exact opposite. :p
bradyj
05-20-2003, 07:09 PM
I wouldn't think it's an arguement for file size or not -- but if you pop that CSS to an external file, and I had 30 pages with the exact same layout, it would be easier to change on the fly then, yes? No opening up pages, changing table layouts + dimensions, yadda, yadda.

More than file size, that seems to be the true reason why I'm seperating coding now -- keeping my pretty stuff away from my structured stuff lets me change things faster and with less complaint on my part and easier tweaking.
brothercake
05-20-2003, 07:44 PM
Originally posted by zoobie
Well, there's nothing "wrong" with my table...or else it wouldn't display properly in all browsers. This is just another example of geeky trends in coding...right up there with bulletin boards and databases of a year ago...just something else to learn. Remember, you have to use this and that css for this and that browser.
Even by making my table "semantically correct" (geek talk for using <tr>'s and <td>'s), it's still 25% smaller than the css. So, if you have a slow-loading page 2 or 3 screens high and expect css to quickly load it for you, you'll probably achieve the exact opposite. :p
zoobie ... man ... step back and listen to yourself. If you don't understand what semantics is then that's cool - there's no shame in not knowing something - but please don't muddy the waters and confuse those less experienced than yourself, by trying to pretend we bandy the word about just to sound cool and geeky. You're in the wrong forum if that's the kind of air-guitar debate you're after.

But I know it isn't ... so indulge me:


Semantics is the study of meaning in symbolism. Language is symbolism - the symbols (words) represent broader concepts (thoughts, feelings etc). But the meaning in symbols is not just in the concepts they represent - it's also in the symbols themselves.

This is tricky to explain ... it's tricky to understand ;) So I'll turn to the case in hand:


<table> is an HTML tag; a tag is a symbol.

The symbol has semantic meaning - it indicates what kind of data it contains, in order to facilitate your comprehension of that data. In the case of HTML the audience is not just people, it's machines as well. Machines have no intelligence, and so semantics are doubly important if we want the machine to know what we mean.

So what does <table> mean? It means "I contain tabular data". If the table contains something which is not tabular data then you're introducing confusion - you're contradicting the semantics of the tag.

The end result is that your data is more difficult to comprehend.

Now when you look at a webpage you may not immediately see what difference this makes; indeed it may not make any difference to you - perhaps the data is perfectly clear.

But you are not the only reader. And your modality is not the only modality. You cannot assume that just because you understand something, it is understandable - a book is not "readable" by virtue of having read it.

I'm thinking now about access technologies - screenreaders which rely on semantics to know what they're looking at and hence what kind of reading or navigation mode they should be in.

I'm also thinking about SE robots and data-gathering processes, which rely on semantics to extract meaningful information from a document.


Here's a more flippant example - who says you can't judge a book by it's cover? On the contrary - the first time you see a book the cover is your only means of judging it - that judgment is how you decide whether to open it. A book about gardening would not say "a tourist's guide to bangkok" on the cover, would it?

There you go :)
zoobie
05-20-2003, 08:54 PM
Oh...ok. Syntax then? :D

The thing is cognitive-dissonance. You've already invested several hundred hours in something...and here I come along not having invested any time saying something you don't wanna hear. Of course you're going to be defensive...It's to be expected.

The table(s) can styled with an external stylesheet, too. Probably the only way to see which is actually smaller is to make the page(s) both ways...and look at the file size.

I've been playing a real guitar for 20+ years...tyvm. ;)
mordred
05-20-2003, 10:09 PM
Originally posted by brothercake
[...explanation of semantic web and it's benefits...]
I'm thinking now about access technologies - screenreaders which rely on semantics to know what they're looking at and hence what kind of reading or navigation mode they should be in.

I'm also thinking about SE robots and data-gathering processes, which rely on semantics to extract meaningful information from a document.


Reading this statement I began to wonder: Is this a real problem? I mean, how did screenreaders deal with the web before table-less CSS designs were introduced and doable in browsers, and is Google really so bad in extracting meaningful information at all? I have almost no experience with screenreaders, but I doubt that manufacturer would build them in a strict standard-complying way, given what the web currently consists of. On the other hand, I think search engines are becoming better and better, Google finds as much info in PDFs and RTFs and on table-intensive sites, so I wonder if this problem really exist.

I do appreciate the idea of the semantic web though. But I have the notion that it's more about data and documents than about presentation and user interfaces. Yet, many web sites are not particularly focused on the data-centric aspect of a (X)HTML page than on it's looks and behaviour as a user interface.
And given that a lot of todays content-driven sites are powered with some kind of DB or XML backend, which is transformed/styled to look as "designed" page, what value does the semantic web really offer? You could output an RDF file instead of your HTML page anyway if you need a more data-centric format.
brothercake
05-20-2003, 10:38 PM
All these things are true - if you're sourcing from a database, CMS or XML then you can provide rich semantic feeds; screenreaders and robots have become much more adept at interpreting tag soup and extracting its meaningful content.

But we can make it better. Much, much better.

:)
mordred
05-20-2003, 11:56 PM
Indeed we can. And probably should. :)

I'm just a little wary of all these standards-buzz currently in the air. As long as HTML4 seems easier than XML it won't go away... same with table-layout vs. CSS-layout. In my opinion, the crux is pointing out the benefits of CSS that actually make webauthoring easier in the long term so people get into it and don't feel like they have to serve an anonymous body like the w3c and it's incomprehensible, yet machine-processing-friendly manpages ;).
brothercake
05-21-2003, 12:06 AM
Yeah I know what you mean; I'm sometimes guilty of disappearing up my own evangelism :D

I guess that the biggest buzz is in doing it and trying to make it work - there's a real pleasure in trying to provide all the same rich environments that people are used to interacting with on the web, but doing so in a semantic non tag-soup kinda way.

And it is so much easier to maintain, and easier for end users to customise to suit themselves. Accessibility is a big part of that - it's easier to make accesssible pages with semantic markup.

But don't talk to me about XHTML 2 ... you'll find my pro-w3c flag starts waning rapidly :rolleyes:
barnettgs
05-21-2003, 12:24 AM
Making CSS sheet for webpage layout can be done only by hand-coding?

I have a Dreamweaver and I'm wondering about that! :confused:

I'm being curious that would it take a long time to code the CSS, just to make a basic page layout?

I can see the point of using CSS for layout but I'm using dreamweaver's template features which meant I can create new page within seconds using template with images in it. Template can be edited too.

But I also use CSS for nag, table layout, links etc as well.

By the way, I found using layout by CSS is very confusing as I was trying to set the div to 100% width and other things etc! No point in trying to work it out around for hours when I can create a table in minutes!
bradyj
05-21-2003, 12:45 AM
I use Dreamweaver as well, and can create tableless designs much faster than with tables. You just need to learn how to use it's CSS editor. If you would like, PV me (this is a new discussion and not following what this post is about) and I can teach you how. Doing so makes it must faster to change all your pages in Dreamweaver but just changing one page of CSS.
brothercake
05-21-2003, 11:50 AM
FYI there is a flip side as well; a flip side which says the semantic web is a pipe-dream, unable to take account of how people and businesses actually behave in a marketplace.

I don't agree with the spirit of this, although I appreciate the realities; interesting reading at http://www.well.com/~doctorow/metacrap.htm
Spook
05-21-2003, 12:12 PM
Tables still have a place in "modern" web design. Certain content should rightly be placed in tables - lists of results for example. But tables should no longer be used for page layout.

Don't forget too that most browsers will cache the style sheet, saving on load times on the subsequent pages, which will also be smaller in size, having no "structural" tables.

The search engine question is an interesting one. Has anyone converted from a tables layout to pure CSS but still used the same content and seen an improvement in page rank?

Spook
ronaldb66
05-21-2003, 12:19 PM
The thing is cognitive-dissonance. You've already invested several hundred hours in something...and here I come along not having invested any time saying something you don't wanna hear. Of course you're going to be defensive...It's to be expected.
Eh? Everybody knows it's a cinch to slap together a layout using a table... for one or two pages. And for screen. And not having to redesign it ever again (yeah, right).
And, yeah, initially it takes a lot longer to get the hang of CSS layouts, but once you've built a couple and start getting the hang of it, the eledged time savings of using table layouts over CSS layouts dwindle, not to mention the time you lose when you've just built a 20 page table layout site and decide you want to move from horizontal to vertical navigation...
Changing a CSS layout means changing one or a few style sheets (provided you got your document structure right!); changing a table layout means changing each and every document.

The table(s) can styled with an external stylesheet, too. Probably the only way to see which is actually smaller is to make the page(s) both ways...and look at the file size.
Styling tables is not the point; neither is file size. As was mentioned earlier: a style sheet only needs to be loaded into cache once, and if several pages share the same style sheet (and they regularly do) its contribution to the total amount of data downloaded gets divided up by the number of pages that use it; a layout table needs to be loaded for every single document.

Don't do your calculations for a single document; do them for a, say, 20 page static publishing site: nice and easy, one layout, one style sheet. I'm very curious.
brothercake
05-21-2003, 12:26 PM
Don't get lost in page rank. Anything you do to your page which is purely to improve SE results is a misuse of meta-information.

Tables do have a place - their place is for providing tabular data. Arguably, search results are not tabular data and should not be presented with a table. I think definition-lists are the closest semantic to search results.

I also think that concerns about page size are irrelevant. XHTML/CSS sites are smaller and faster loading, almost always, but that's not the point, it's just an added advantage, imo.
barnettgs
05-21-2003, 12:54 PM
Originally posted by bradyj
I use Dreamweaver as well, and can create tableless designs much faster than with tables. You just need to learn how to use it's CSS editor. If you would like, PV me (this is a new discussion and not following what this post is about) and I can teach you how. Doing so makes it must faster to change all your pages in Dreamweaver but just changing one page of CSS.

Ok, where will I find to click 'DIV' button? There's a layer button but using it will creat a DIV with a JavaScript code in the head section! I know how to use CSS editor basically but the problem is making a DIV layout within HMTL page in Dreamweaver.

Also what code would I use for CSS to position the layout in center positon regardless of monitor size?
Spook
05-21-2003, 01:11 PM
brothercake, I agree, lists of results were not a good example but could not think of a more correct one in the time available.

IMO there are two sides to website design. Almost anyone can build an aesthetically pleasing website, and if it's an on-line brochure you are designing, or a hobby type site, then that is great. However, most people actually want their website to be found by others, via search engines. Therefore you MUST design your pages to be search engine friendly. I'm not talking about using dirty tricks to improve your rankings - merely producing good content in a way that the search engines can find and subsequently will rank well. The two go hand-in-hand; good visual design and SEO. Now - an advantage of using CSS is that content can be delivered first to the SE, but still placed correctly for visual effect - don't you agree? I am not sure how you could interpret this as "misuse of meta-information".

The question really is; do search engine spiders prefer "tag soup" or not?

And how many websites have you aborted because they took too long to load - baring in mind tht the vast majority of internet users around the world are still on dial-up?


;) Spook
brothercake
05-21-2003, 01:31 PM
I partly agree - your clarification of the difference between "optimisation" and "dirty tricks" is an important one; thanks for making that point.

But 99% of what is called optimisation is just common sense document structure - using descriptive keywords, using real headings and paragraphs, using descriptive text for links rather than "click here" ... that kind of thing.

I don't believe that this should be done explicitly with SE robots in mind, because robots are post-rationale - they adapt to the kind of documents they encounter. If you try to adapt your document to the robot you end up with a vicious circle - exactly the vicious circle we have, where SEs constantly change their algorithm to prevent it from being exploited unfairly.

So overall I stick to my point - don't optimise for search engines specifically. Optimise for semantics, and SE optimisation happens naturally.
Spook
05-21-2003, 03:43 PM
Maybe this is a whole new thread starting here and it's a little unfair to hi-jack this thread. However, I only partly agree too!

I do not advocate optimising for SE's specifically, neither do I agree totally that optimising for semantics will automatically give you SE optimisation, but it will of course go a long way towards it.

SE robots are effectively blind and artificially inteligent, working to a strict set of rules - the algo.

When you hand code a web page, you do it in accordance with a set of rules, otherwise it will not display correctly, sometimes not at all. If you had reverse engineered the robots algo and could write the perfect web page which would go immediately to the number one position in the search results, would you do it?

All the best...

Spook

:)
zoobie
05-21-2003, 07:35 PM
Try: <meta search position="#1"> :D

By the time you think you've got the SE's algo down, they change it. This concept isn't clear at optimization forums where you'll find thousands of frustrated webmasters. Someone beat the SE's optimization site's SERP in Google by using absolutely no meta tags...title only.

Such hell...for nothing...:p