Forum Moderators: not2easy
When you work the web for a living, the time available to keep up with the technology decreases at a rate that is an exponential quotient of the speed at which it outdistances you. In plain English - your primary concern is cutting the house payment, not keeping up with the latest technological trends. But I've done my best. Alistapart, ZenGarden, W3C, the Camel Book, these are my theological texts. My wife thinks I'm insane.
Time and time again, faithful older customers dig me up like Victorian sleuths on the trail of the latest werewolf and ask me to revisit a site from years gone past, a site that has most often been spaghetti-ground by the "webmasters" that followed, operators at the helms of the ruthless gears of Front Page or Dreamweaver. I have to look hard, but often my old mistakes are still there . . . . font tags, broken code, animated gifs . . . but am always thankful for the opportunity to exorcise my own demons, ferret out the garbage, and bring the site up to date.
Which brings me to my point (at long last, I'm sure you are saying.) I've been a follower of CSS for years; I think my last font tag was (thankfully) given a full-body slam several years ago and I've never looked back. Not even fondly.
There is, however, the issue of tables for layout, and I must wonder if the sites I've built - HUNDREDS of them - will come back to haunt me, or be the point of another young hungry designer's crusade to Steal My Job. :-) It just seems to me, particularly in my position as a perl programmer, where the output is very seldom known or predictable, that there are many instances where tables are the ONLY solution.
The crux of my question is this: Why is there such a purist movement to eliminate tables as a layout tool when clearly the tools are not yet inadequate to replace it? This very site is laid out in tables. Worse yet, it begins it's page by the <CENTER> tag which has been depricated for years. :D
I'm not ignorant of the W3C specs, and by no means am knocking CSS, as I said, I read the W3C as regularly as possible and try to implement their recommendations where reasonable, but sometimes it seems we are trading one "workaround" for another. The posts here where CSS hacks are required just to get all the browsers to cooperate is evidence enough.
For example:
TD.topbg { background-color: F4F4F4; background-image: url(images/top_bg.gif); background-repeat: repeat-x; }
TD.botbg { background-color: F4F4F4; background-image: url(images/bot_bg.gif); background-repeat: repeat-x; }
TD.vertbg { background-color: F4F4F4; background-image: url(images/vert_bg.gif); background-repeat: repeat-y; }
<table cellpadding="0" cellspacing="0" border="0">
<tr>
<td><img src="images/top_left_corner.gif" width="6" height="6" border="0" /></td>
<td class="topbg"><img src="images/top_bg.gif" width="1" height="6" border="0" /></td>
<td><img src="images/top_right_corner.gif" width="6" height="6" border="0" /></td>
</tr>
<tr>
<td class="vertbg"><img src="images/vert_bg.gif" width="6" height="1" border="0" /></td>
<td> content of the box </td>
<td class="vertbg"><img src="images/vert_bg.gif" width="6" height="1" border="0" /></td>
</tr>
<tr>
<td><img src="images/bottom_left_corner.gif" width="6" height="6" border="0" /></td>
<td class="botbg"><img src="images/bot_bg.gif" width="1" height="6" border="0" /></td>
<td><img src="images/bottom_right_corner.gif" width="6" height="6" border="0" /></td>
</tr>
</table>
Simple enough.
I've spend this afternoon trying to implement this simple table as a tabless layout using CSS, without using absolute positioning and found it impossible, especially when nesting this little monster inside other box constructs. The top row will lay out fine, but the center row will not cooperate at all in any combination of div's or other elements. The divs reflow, or one attribute that fixes a problem opens a door for another.
And the situation gets more complex: this is a small node of a much more complex scheme, the overall layout will consist of several cells (sorry, table-junkie reference) with image-based borders passing throughout as division lines.
If left as a table, or made a sub-cell of a larger table? Drop it in, cocked, locked, and ready to rock. 100% predictability (and yes, there are those other issues with tables . . . understood.)
Thanks for your patience with my rant, any replies appreciated, if I'm missing something important here, fire away. :-D
Some people who build wooden furniture carve their own wooden pegs to hold their delicate creations together. But sometimes, you know you just need to add a quick splurge of superglue and it'll all hold together much more solidly, and in a tenth of the time. The peg-carvers will scream that it's not how you should do it, of course.
Does your table destroy accessibility? Does it ruin the generating perl script? Does it expand your page size or disatrously reduce your content-to-markup ratio? No? Then use it and it will let you get on dealing with more important stuff. Sometimes, superglue is your friend. ;)
Mostly here at WebmasterWorld, we love CSS, but we've got businesses to run and deadlines to meet: so, a pragmatic approach to standards is greatly favoured here!
I guess what it gets down to is how many hours do you spend "trying to make it work" when a clear and sure solution is at hand. More importantly - how many hours is the customer willing to pay for (and forbid, do they really even care what you go through for them! :D )
HTML pages are made of basic elements like lists, tables, paragraphs and headings.
If you're going to make a page out of tables, why not make a page out of lists?
...because the default style the browser gives to tables is more convenient than the default style it gives to lists?
Forget the browser.
Your markup is for the sake of your document, not for the sake of the browser.
No, I've never considered making wooden furniture >;->
Can you do a grid layout easier in <table>? Of course.
Is that what we are used to seeing? Yes.
Is it best because it is better or because it is "normal"? Pavlov would be pleased with our conditioning.
Most of the WWW is still a <table> world: because no one has looked at them since they went up years ago, because of how some WYSIWYG programs generate HTML, because the designer doesn't know different, for maximum cross-browser compatability, etc.
My approach is to determine the clients requirements and build the best I can to meet those. Sometimes that means a <table> layout. I prefer not to but it is an available tool.
There is no excuse to still be using <font> attributes in HTML - CSS1 showed up in 1996 or so. Even in a <table> design layout as many elements/attributes as possible (including those for positioning) should be moved into CSS, preferably an external CSS file. The code becomes easier to debug, the bandwidth savings can be substantial, the load time for dialup visitors is minimised, and it is "best practice".
So leave the <table> layout but strip the styles into a CSS file unless the page design is simple. If desired go back later and as time allows replace each page design with <div>s. This is often a good excuse to do a "new look" for freshness which might allow you to use a more <div> friendly layout.
Eventually browsers will all catch up with the recommendations and eventually WYSIWYG editors will generate clean lean code, eventually website designers will all be skilled in current "best practice". In the meantime be like the rest of us and do the best you can with what we have. It is still much better than 10-years ago!
The other site I'm doing from scratch and I'm doing it with CSS so that I can get the design I want and future updates will be a breeze.
The other problem that I have had is trying to explain what CSS is to clients. Because, for me, a CSS design will take a bit longer to achieve and not have the same options as a table based design. When I'm dealing with clients that are used to table based designs they will say "just do this" and I'll say "that will take a little while because of the way CSS works" and sometimes they think you are just making excuses to clock up the hours. In the end they realise that they are better off and will save money in the long run with updates and maintenance.
To continue the woodworking analogy: You use timber to build a desk, you use concrete and steel to build the empire state building.
why not make a page out of lists?
I like where you're going with this ... ;)
why not make a page out of lists? ...
Funny you would mention this. (well not **really** funny . . . ) I'm currently on a project by this inssane doctor that is 753 MS Word document pages (seven-hundered and fifty-three, correct) of lists. All medical terms. It's insane. But it's a job.
Why is there such a purist movement to eliminate tables as a layout tool when clearly the tools are not yet inadequate to replace it?
I assume you meant 'adequate,' that CSS is not yet adequate to replace tables, which isn't quite true.
This seems to be a common theme in these css VS tables discussions, but its important to remember that there is nothing wrong with CSS. CSS is just fine. It's capable of doing damn near anything you want to do, and in it's 'pure' form simply blows the doors off of tables in simplicity. It's properties allow you to say, "I want this here" and then you put it there. No figuring out how many empty cells you need in how many empty rows in order to place an image slice in such and such location.
The problem isn't CSS, it's browsers. Most notably, it's IE, but even such compliance leaders as Opera have their issues. If it weren't for the different browser makers implementing the standards in wonky, counterintuitive ways, I doubt there would be much to discuss. CSS would be a breeze to implement, and since when it works well its already a breeze to design with...well, there you go.
Point being that the criticism of CSS is usually misplaced criticism of browsers.
cEM
[edited by: createErrorMsg at 9:54 pm (utc) on Dec. 1, 2004]
Point being that the criticism of CSS is usually misplaced criticism of browsers.
Again, I'm not criticizing CSS, I've been using it since before it was really even supported (remember Superfly? :D ) The reason I bring up the outdated issue of tables is as I originally posted, do I **really** have to unravel all those beautiful tables to sleep well at night? :-) And what does one do for fluid layouts with image-based borders?
