Work is the Curse of the Web Technologist

While it is very good to be busy in economic times such as these, it becomes easy to fall behind when keeping ahead. One obvious example is the fall off of my postings on this blog. The other is when a new spec right at the heart of my day-to-day livlihood is under construction for four months before it pops up on my radar.

In this case, I’m talking about HTML 5.

OTOH, web specifications seem to be totally outside of the whole “Internet speed” thing, because I’m still waiting for there to be more HTML 4 compliant pages on the web đŸ™‚

Facebooktwitterredditlinkedinmail
© Scott S. Nelson

Good Thread on White Space in JSPs

While it is tempting to quickly skim an blog entry for the information I’m seeking at the time, a recent find on dealing with white space with JSPs reminded me that there is a darn good reason most blogs have a comment feature.

The thread I’m talking about is Trim Spaces in Your JSP at Raible Designs. Fortunately, my paranoia paid off, and I did not try this setting blindly on the project where I was looking for such an answer (and have since rolled off). I almost did, but decided not to because I knew I would not be around to support the change, and that whoever I told about it may forget it. As it is a performance enhancement and the application had some peformance issues (too many cooks in the presentation layer kitchen IMHO), it was not as easy of a call as it may seem.

The con that comes up in the comments on that post is that it wipes all white space between tags. If I were the only person developing on the project, or if was a small team where I knew for certain that only experience JSP developers were working on the JSPs, I’d still feel safe. This is because if a space has to be in a page between two dynamic parameters, the experienced JSP developer will use an entity code rather than just a blank space.

There is also a comment in the thread about how to cut down white space in a build file. That was actually the type of solution I was seeking at the time (and missed at the time).  I would have to experiment with the solution before I suggested it, but it looks like what I wanted.

Facebooktwitterredditlinkedinmail
© Scott S. Nelson

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.

Facebooktwitterredditlinkedinmail
© Scott S. Nelson