Quote:
tables for layout are frowned upon by the css crowd, since they should only be used for tabular data. However, it's sometimes a real pain to do things like a column layout that's flexible with what's available. I'm still working on the sidebar issue, so hopefully I'll figure out something by the end of the week.
As I noted, it's frowned upon, only where CSS *can* do it. In cases where CSS simply can't, it's accepted in the spirt vs letter. There is hope for this in CSS 3.0, but ... they don't have 2.0 right yet :)
There really is no good way to create columns in CSS. CSS *has* to incorporate the concepts of tables, and screen areas, and relative positions as used in standard HTML layouts. There are things that are simply not possible in CSS, but which can be done with HTML, and that is not supposed to be the case.
The table is only used to divide the screen, and prevent the content areas from colliding, which seems to be happening. A table cell is a reference/grid area that is not able to be specified any other way in CSS. This is the biggest problem, and there really is no fix for it, since the "position" tags in CSS 2.0 are sorely lacking in flexibility. You can't specify a location in relation to a specific content area, or content block, only to the screen, the current named block, or an absolute reference. What is needed is a way to reference another named content area.
So, the spirit vs letter issues allow tables for placement, but frown against using nested tables for borders, and such, that can be specified in CSS. The feeling seems to be a planned, progressive migration, as CSS matures, and standards-compliant browsers actually comply with the standards.
And, while you may fix the side-bar issue, how will you deal with the fact most Links sites are using a 3-column format, with a 2-3 column main content area? I need 3 columns, and sometimes 4 on a page. CSS just can't do that without tables.
Without tables, or relative-to-named-content-areas positioning, CSS is simply "stream of conciousness". "float" is a poor implemenation, and seems to be an "after thought" to give some ability in this evolving but not-ready-for-prime-time standard.
There are a few good sites with examples, but none of them work really well, since they need to anchor the left and right columns to the left and right of the screen and use a sliding-width center content area -- otherwise, an errant text element such as a long word -- can break the whole thing. You can't simply get an 80% centering, or an 800 pixel centered format, and multiple columns like you can with tables and HTML.
Quote:
things like bgcolor have been removed from the xhtml 1.0 strict (we're using transitional, where it's still valid) since they belong in the style sheet.
This was a quick fix, and I was so excited to get it working, that I didn't take the time to put the table formatting tags into the CSS. But, the "bgcolor" tag is only an after thought. It actually looks good without the grey going down, but I tried to imitate the existing layout a little. I was going to play with the style sheet tomorrow, and see if I could clean it up.
The fact that tables fix/solve the problems in getting the layout I need now, from the 2.x format, means I can start to migrate my sites.
But, without the ability to accurately position multiple elements in columns, formatting is severely limited.
No matter how great CSS may be, if it can't make efficient use of the page, it has to yeild to HTML in those areas.
Quote:
all attribute values need to be quoted in xhtml.
all elements/tags are lower cased. I'm still doing all this by hand, in a text editor. I haven't found a CSS editor I like, or can get the hang of. Since these templates still have to be run though the CGI, it makes it hard to really just work on the pages. Some of the issues are from the generated content. But, those issues are able to be fixed up in an automated fashion in a pass through a checker/validator.
Quote:
instead of changing things like #contentarea to #contentarea_toprate, you can instead use a #idofpage #contentarea {} style instead
I realize there are ways of overriding styles, but I'm still getting the hang of this stuff. Actually, there is no real difference in the styles (_toprate, _search, etc), except I didn't want to break the rest of the site. I could call them #contentarea_tables to differentiate them from the content area without tables. Since the tables are coded into the file, changing the name of the content area to reflect that is probably a good idea. That way there are table-containing and table-less files. When the CSS standards improve, that can be backcoded.
Those are not styles that would be needed in a pure-css layout, *if* css ever gets to this point.
Huge amounts of time/effort seem to be wasted to work around implementation and/or specification bugs, when simple alternatives in the HTML are available. When the implementation and specifications improve, over time, so can the CSS implementation of a site.
But for now, CSS seems to be LIMITING than freeing for most sites. Governement, or purely informative sites can benefit from it, if they have lots of pages formatted similarly, and need to be accessed via different browsers or such. But, most of the links sites, and sites users of these forums are developing are cutting edge in most ways, and need to have tight control over the layout. It's not an either/or scenario. You can use the best/improved parts of CSS, but still frame your pages in HTML until CSS catches up.
The economy is tough, money is tight, time is at a premium. CSS is supposed to _save_ time, but it seems to be wasting huge amounts of it for many projects.
HTML is a "mature" standard, and implementation (most browsers get it 99% or 98% correct). CSS is still maturing, and browsers are all over the place in support/implemenation.
If a couple of lines of HTML fixes hours of aggrevation, and thousands of dollars of design/graphics time, I say go with it.
It's not going to break the CSS or HTML. Just pick the appropriate doctype... which is probably transitional. *that* can do more damage now adays than bad coding <sigh>
Despite what many people pushing CSS say or think, *most* web publishers want their pages to display THEIR WAY, like a magazine, not distorted or reassembled by improper or alternative formatting. CSS is not up to that. HTML browsers are barely up to it! :) That was the promise CSS was supposed to bring to the HTML which was a _markup_language_ (eg: a description of how a page should display, not an actual specific display). CSS has failed to do that. It may be getting closer, but it has not delivered on the promise made when it was being planned. Tables, on the other hand, while maybe a nightmare in complexity at times, *do* deliver on the promise, in a reproducable manner at this stage of the game.
And, the last thought... The purpose of all this is to make sure pages display as you intend on various hardware and software. Since the software can't get the INTERPRETATION/IMPLEMENTATION correct, it really doesn't matter how good your CSS or stylesheets are :) The browsers can't deal with it. KISS. Where appropriate.
Use tables to grid out your screen. Use CSS to position and style the elements within those grid spaces. The CSS can't get out of them, without using "absolute", and you know pretty much exactly where each relative position is on the page (screen).
Tables *are* supported, and will always be supported, because they serve a purpose. As CSS improves/matures, their purpose will keep shrinking as other more useful methods appear. But, until then, and beyond, tables for data will *always* be needed.
PUGDOG� Enterprises, Inc. The best way to contact me is to
NOT use Email.
Please leave a PM here.
