Tables Vs CSS Layouts

I’m in the midst of customizing the themes for my blogs. Now, if I had oodles of time, I would build my own theme from the ground up. I don’t have a nano-oodle, let alone multiple oodles, so I’m just hacking up the default theme.

No matter how well designed a web application is, it is always hard to step into someone else’s work and make changes that perfectly dovetail the original source. Not impossible, just hard. So, to keep a long story from getting way too long (it is impossible to make a long story short, because it is always too late by the time the thought occurs), I found myself using tables to modify the layouts (gasp!).

Using tables for something other than tabular data is something I avoid, but I do it anyways sometimes. In the case of the theme on this blog, it was a matter of the fastest way to modify an existing layout that I did not design. If I had more time, I’m sure I could have gotten past the bugs that cropped up when I tried modifying the CSS instead. If I had built it myself from the ground up, I could definitly have avoided the table approach because I am careful to avoid redundant classes and I document the things that aren’t glaringly obvious because I know I will forget later if I don’t. But, since neither of these were the case, I used the table. The momentary twinge of guilt passed as soon as I moved on to something else that caught my over-burdened attention. Until I ran across a job posting that stated something to the effect of “If you use tables for layout, do not apply”. Which got the question stuck in my mind “what is the truth about using tables or CSS for layout”?

I’ve been reading about the topic for six or seven years now, so it didn’t surprise me that a search on “tables vs divs” in Google returnedĀ  “about 15,400,000” results in 0.41 seconds. What did surprise me was that the first six results were 100% relevant, and that the general consensus of the first ten results agreed with my thoughts on the topic, which are:

  • The approach that is the least complicated is preferred over the one that is the most complicated
  • The semantic web is yet to come, hopefully will come, and it is better to use CSS for layout than tables when it does get here
  • If the layout is overly complex, the semantics will be lost regardless which approach is used
  • There is no value in re-writing your code simply to eliminate tables in layouts, while it is valuable to update to CSS if you need to re-write anyway
  • The best choice depends on the goal of the page

If this sparks folks to register and comment, I will be happy to elaborate further.

If you found this interesting, please share.

GIS

For those smarter or more up on acronyms than I, ignore this post.

As posted at my parent blog, I was reading this SF story last night in Analog. There was a reference to GIS, which I’ve seen around alot lately on the job boards but haven’t bothered to look up.Ā  For the curious, it stands for Geographic information system.

If you found this interesting, please share.

Consider This When Planning Web Services

As soon as Web Services started getting buzz I was both excited and concerned. Interoperability and reuse are great things. Shorter time to market is a huge benefit. Bandwidth is limited. That last was never brought up by the sales people taking clients to $1000 dinners while pitching $30,000 web service platforms with $1,000,000 support contracts.

Web services are still a great way to expose legacy systems to myriad clients across the enterprise. Where they become expensive is when they are built with only one or two expected clients to support a (myopic) SOA vision. Especially when many of the new services being built are only aggregations of other services that will generally be a specialized interface to business logic required by a limited number of clients.

If an architecture includes web services, a list of clients must be part of support case or the design is simply buzz word bingo.

This technical rant was prompted by a developer.com article that has way to much code to share with the folks who will often make the final decision, but may get their advisers excited enough to explain it to them.

If you found this interesting, please share.

Good Article on WebLogic Deployment Plans

In WLS, deployment plans let you change the values in deployment descriptors at deployment time. This is really handy when you want to move your deployment archives from one environment to the next (i.e., from Staging to Production) and need different settings based on the environment. Maxence Button blogged an excellent how-to at http://m-button.blogspot.com/2008/08/how-to-use-deployment-plan.html

If you found this interesting, please share.
The IT Solutionist Icon

Favicon Generator

I remember what a pain this was the first time, and the next to last time, where I hadn’t done it in years. Today I found a site that will generate one for free and tells you how to use it. Must have bookmark: DeGraeve.com Favicon Generator.

03/16/2022: An alert reader sent this yesterday:

Hello there ,
I was using the favicon generator tool you mentioned on your page here: theitsolutionist.com/2009/05/25/favicon-generator/
While degraeve.com does a good job, it only allows you to create favicons from pictures that are up to 2 MB in size.
After some exploring I found this other tool and I wanted to suggest you show it along that one.
https://www.websiteplanet.com/webtools/favicon-generator/
this tool allows you to create favicons from pictures that are up to 5 MB from either JPG, PNG or GIF or even from a gallery!
In hope I helped back,
Nina

When I asked her to post it in the comments, her reply was:

Thank you, for being so receptive and for emailing me back But I rather not add my message with a link on comments as not many people think they are trustworthy( I got a virus after I followed a link on a comment) and I know that in some cases it is also used for spam. I think it will be more useful to your users as a link.

Please let me know if you share it, I would love to check it out?
KeepĀ the great work on your page!

Best,

Nina

Thanks, Nina!

If you found this interesting, please share.