Kimler Sidebar Menu
Search Journal
Local Weather
Site Tools
Randsco Worldwide Visitors: Count, Country, Time & What they're reading
There are 52 visitors. Click to see their country & what they're reading.
Randsco Site Map
Site MapAgain, this is something that I've been wanting to do for some time and I believe that a site map is necessary to help those people out that have a hard time figuring out what is what on our site. I'd like to think that our menu system is easy and will work, but some people just require a site map to figure it out. So ... here you go ... a site map. (It currently sucks, which is why it's shown as display:none!)
About the Kimlers
about usThis is where visitors can find out about Randsco and the Kimler family. Who are we? How did we come to be? What motivates us on our adventures. It's kinda like the old "meet scott and rachel" section on our PCT WebPage, but this "about us" section will be a stand-alone page.
Random Photo (linked to blog entry)
Kimler Login Page
Journal Archives
Journal Categories
Thank You
FEATURED DONOR: Ellis Design Associates is a small, independent civil and structural engineering consulting company, based on the south coast of England. Most of their work is in the U.K., but they've also had projects in Singapore, Malaysia, Hong Kong, the Middle East and North America. Their new website was deployed on Jan 12, 2009 and uses Photo-Caption Zoom.
The Ellis Design Associates website was recently revamped by Nick Bowles, of Webcraft U.K., Ltd.
"[They] already had a lot of content on their website, but it was difficult to navigate and not very search engine friendly. We are confident that having a new, modern-looking online portfolio, showing their wide range of expertise and experience will pay dividends for the company in the coming months and years," Nick said, when the new site was launched, on January 12th, 2009.
Nick employed Photo-caption Zoom on several of the engineering design portfolio pages, maximizing page real-estate, adding relevant and search-engine friendly caption text and allowing web visitors to see project photos in greater detail, without having to leave the the portfolio page.
Kimler Adventure Pages: Journal Entries
Die Tables Die
Don't web designers now know NOT TO USE TABLES FOR PAGE LAYOUT? I thought so, but an email, received from the President of a web media company, says otherwise
Tables for tabular data ONLY ... NOT for LAYOUT!!
Last night, I had an interesting e-mail exchange, in which someone was using an ASP.net datalist to display three PZ3 images in a row. They were having problems with IE. (No surprise there). 
First, I know very little about ASP.net, but I asked the fellow for a copy of the page (X)HTML and CSS and said I'd look into the problem.
It was a basic page, nothing too odd (though I did notice a bunch of ASP.net-specific bloat). I quickly found the problem: the fellow was using a table to contain the single row of three PZ3 images, each in their own cell (browsers often fail to correctly interpret CSS directives inside table cells).
I haven't used tables for layout in years and assumed that (by now) the message to do so, would've gotten out. Obviously not.
I wrote back and said, "Using a table to hold the three images is semantically incorrect (because no tabular data are being displayed) and the root of your problem. To fix it, just take the three images out of the table." I even provided some XHTML-valid code that would accomplish what he wanted (semantically correct and more succinct).
The response I got back, floored me.
Huh?
Maybe what he's trying to say is that "he can't get rid of the table", but if so, it's because of a limitation in the ASP.net language he's using and not because it's semantically incorrect to do so. At the end of the day, it doesn't matter how ASP.net stores/retrieves/interprets the image data, what does matter is:
Displaying three images in a row, is NOT a display of "tabular data".
To top it off, this fellow isn't just anyone, he's the President of a web media company. He should KNOW BETTER!
The exchange bothered me enough that I thought I'd write my own version of "What I think should be tacitly understood anyone writing HTML code".
To find out why tables are bad (should be used for displaying tabular data, NOT FOR LAYOUT) and what is "tabular data" anyway? .... read on.
Why Tables are BAD-BAd-Bad-bad
Never use tables for layout.
Truth is, they're not bad, they're just badly abused. Tables are fine for displaying tabular data, but should never be used for page layout. The problem with tables has arisen, because they have been abused and used for page layout, by many designers.
The whole goal of using tables is to "arrange data -- text, preformatted text, images, links, forms, form fields, other tables, etc. -- into rows and columns of cells" (Source - W3C HTML Recommendation).
Furthermore, the W3C also recommends against using tables for layout. Here's what they have to say on the matter (same document):
Tables should not be used purely as a means to layout document content as this may present problems when rendering to non-visual media. Additionally, when used with graphics, these tables may force users to scroll horizontally to view a table designed on a system with a larger display. To minimize these problems, authors should use style sheets to control layout rather than tables.
Besides simply being a W3C recommendation, not using tables for layout just makes plain sense.
Why Tables for Layout Suck
- Tables require more code.
- Tables take longer to load.
- Tables prevent incremental page display.
- Tables may require image slicing.
- Tables break text copying on some browsers.
- Tables prevents some CSS from working within them.
- Tables layouts are convoluted and confusing.
- Tables are semantically incorrect for layout.
- Tables break for screen readers.
- Tables make redesigns/modifications difficult.
The Solution & the Backlash
The solution, of course, is to use CSS and DIVs (along with other, semantically correct, elements) to design and lay out a web-page. The benefits for designing this way are readily apparent to anyone who is doing it - flexibility, accessibility and future-proofing (among others).
Web developers are beginning to design to web standards, making semantically-correct pages. That's a good thing. The backlash, is that using tables has gotten a bad rap. Many people have interpreted "Don't use tables for layout" into "tables are bad".
Many forget that tables still have a useful and semantically correct place on a web page - for displaying tabular data.
So What ARE Tabular Data?
Tabular data are the kind of data one would expect to see in table-form, or information that has a two-dimensional relationship. Consider the following table (LOL - oh crap, now I have to make up a table, which I don't often have need to do ... and style it! 
):
| Popularity | Dog Names | Votes |
| 1 | Rover | 34,566 |
| 2 | Spot | 28,502 |
| 3 | Fido | 10,275 |
The above example table, which could be titled "The Three Most Popular Dog Names", has relationships in both the horizontal direction (Popularity, Dog Name & Vote) and the vertical direction (Popularity, Dog Name or Vote lists). In other words, it has two-dimensional relationships. Though it's possible to present the data some other way, it just makes sense to arrange it in columns and rows.
That's a good way of determining IF your data should be presented in a table or not, (i.e., is it tabular data?) - does it have 2-D relationships and does it make sense to display it in rows and columns?. (Could your table cells fit into Excel, or some other spreadsheet program, having a descriptive row and column titles)? If the answer is 'yes', then you're likely dealing with tabular data and should use tables. If 'no' (as in the case with three images in a row), then it's NOT tabular data and shouldn't be inside a table.
Conclusions
Tables are not inherently "bad", but they've been abused. Use them for displaying tabular data ... not for page layout.
I didn't think I needed to write this, but I sincerely hope it helps others. (Hopefully, the President of a certain web media company, for one.) 
Thanks for the kind words.
I had a quick look at your site and enjoyed the article - about ColorZilla. I'll have to look into that.
Right now, I use a free utility called Pixel Probe, which (basically) does the same thing ... minus the selector bit.
Cheers,
-stk
Anyway I totally agree with you. I *like* being table-free in my own domain. What's that domain you might ask? Why it's http://wonderwinds.com (not that I'm sucking link-love off you with that shameless self-promotion
Yeah, I use them still for displaying MySQl data. Easier to populate and repeat :-)
So I have to redesign the whole thing in tables. AAAAAAARRRGHHH!!!
So there are times when tables still have to be used.
'Die Tables Die' indeed!
Ed
Not using tables for layout is a WEB standards movement and because email clients are not "the web", they're way behind in standards support. I don't envy your task of making an HTML newsletter for email client, knowing that some people have text-only email support, use a non-HTML mode or don't allow graphics ... so any HTML-based presentation (tables or otherwise) and perhaps the message itself, may not get even get through.
Anyone making such email newsletters might find this article interesting, as it talks about the present difficulties in creating an HTML document for email clients.
At the end of the article, is a good reading list of resources on CSS support in a variety of mail clients. One I found intriguing, was this one.
Hopefully, web standards will universally supported by email clients, both local and web-based, in the future.
~J-Duff
In your zeal to slam the guy with long buzzwords, you gloss over what he was actually trying to do. Hence, you totally miss the point and fail to provide a viable solution to the real-world problem he's trying to solve with tables. Furthermore, you incorrectly assume he's spelling XHTML wrong, as evidenced by your insertion of "[sic]" into the quote of his response to your self-righteous suggestion.
In my opinion, this person is using a table in a legitimate manner - the images are the data and an XML file is the source. Many situations call for an XML file to hold filenames so a portion of a web page becomes easily customizable. This method is especially useful when combined with Flash; for instance, a slideshow that a third party can alter simply by uploading new image files and updating the XML data source.
Whether you believe it or not, a single row of data is still data. And as such, if a person wants to display that data in a tabular fashion, they are perfectly within their rights to use a table. You could have tried to help the guy with his markup instead of telling him unspecifically to change how he's doing something. Your aptitude to behave zealously shouldn't get in the way of answering a simple question.
I meant the previous post for you. Address what it says instead of the address.
1) "you incorrectly assume he's spelling XHTML wrong, as evidenced by your insertion of "[sic]" into the quote of his response to your self-righteous suggestion." - Wrong. The [sic] follows the 'a' because it should be 'an XML', rather than 'a XML'. You'll note the acronym is "eXtensible Mark-up Language", not "eXtensible Hyper-Text Mark-up Language".
2) "you gloss over what he was actually trying to do" - Nope, I only glossed over how he got there. That he is using an XML file to store image filenames is of little consequence when the end result is an XHTML file.
3) "In my opinion, this person is using a table in a legitimate manner - the images are the data and an XML file is the source." - It may be your opinion that he's using tables in a legit manner, but using tables for layout is not recommended by the W3C for the reasons I outlined. (Putting three images into a table row is using tables to layout the images on the page).
4) "Whether you believe it or not, a single row of data is still data" - I do believe "single row of data is still data". However, it's not necessarily tabular data, and that's really the test that should be applied. (Characters are data, should each be placed in a table-cell?)
5) "You could have tried to help the guy with his markup instead of telling him unspecifically to change how he's doing something. Your aptitude to behave zealously shouldn't get in the way of answering a simple question." - I don't blindly answer questions without thinking about them first. If someone asked me, "How do I put cement down my toilet?" I'm going to ask first, "Why do you want to put cement down your toilet?" Same applies here. "How do I get PZ3 working inside a table?" is going to beg the question, "Why are you using a table?"
The fact is, there are lots of people that use tables for layout and other things they shouldn't. I'm simply spreading the word that it's not ideal and pointing folks to solutions: using tables for tabular data; using DIVs, CSS and other semantically correct tags for layout.
Do a DIV-three-column Layout, middle column always centered, with a sticky(!) footer and non-clipping backgroundtiles, displays the same on FireFox, IE, Safari, Opera, etc. ... it is IMPOSSIBLE if what you want is clean and fast code. You would need a thousand CSS hacks and probably Javascript fixes. Yet with a table all you need are three TD's and that is it.
Comes to my mind my old programming teacher in school who would rather have four nested loops to avoid ONE "goto" - and why? Because someone told him it's "bad-bad-bad." My philosophy is: use what makes most sense.
Non-Standard Browser checks in so-called "standard-code," this is the real evil - but nonethelss a sad reality, worse than ANY table could ever be.
As a web-developer, if I had to choose between a table or bag of ugly tricks - it would for sure take the lesser evil.
At the end of the day, you have only to account to yourself. If you find that a more practical solution for layout can be achieved through the non-recommended use of table tags, by all means, go that route.
The fact is, however, that table tags were designed to display tabular data and not as a tool for "breaking the page into pieces". Unfortunately, many people (and WYSIWYG web-authoring programs) default to using tables for that purpose, without even considering using div tags instead.
Regarding browser support and the use of IE conditional comments. Yes, I agree it's a travesty that browser companies (notably Microsoft) don't do a better job of supporting web standards. I wouldn't characterize any of this as "evil", just unfortunate.
My preference, as a web-developer, is to write semantically correct mark-up and clean, standards-based code. Unfortunately, this conflicts with my - more important - goal of providing a good visitor experience, so I use IE conditionals. (There are other other ways of browser sniffing - i.e., it could be done server-side and would keep such "ugly tricks" from showing in the code. Would this be any different really? Not to my way of thinking).
BTW ... I happen to think conditionals are one of the things Microsoft did correctly, since IE isn't alone in their failure to fully support web standards.)
But recommendations do not necessarily reflect the real world and they are just that: recommendations. The W3C writes its recommendations out of a futuristic (some might say utopic) viewpoint in which brosers actually respect standards, which currently they do not.
There is a very old truth: "Rules are meant to be broken"
Another one says "Rules protect the small man but are a burden to him who wants to grow"