One problem I've run into many times now when setting up templates via css is the seemingly simple "sticky footer". Put simply, a sticky footer is designed to "stick" at the bottom of the browser even if your site does not fill the browser lengthwise. This required almost no thought with old school tables using height="100%" but with CSS we obviously try to avoid tables at all cost. And even if you still insist on peppering your markup with those dreaded tables, the table height attribute is no longer supported by newer browsers so you, my friend, are also out of luck.  Enter The Man in Blue, Cameron Adams. Using his sticky footer solution you can set up the web page to span the entire height of the browser by setting the html, body and site container's (excluding the footer) height to 100%. Then using relative positioning and negative margins the footer container is positioned to show at the bottom of the browser. You can view code examples in the original post. Hat's off to Cameron for a great solution!

With the ringing in of 2007, one of my work-related resolutions is to be more involved in the CSS community. Still being relatively new to the CSS world, there is a lot of information floating around out there that I have yet to discover, as well as information I have found which I now consider common knowledge, but had to figure out the hard way due to lack of documentation. Of course W3C has documentation for CSS properties but where do you go to learn about browser inconsistencies and hacks (I am a big proponent of CSS hacks and have found them necessary to make real world web sites display properly across all browsers)? I have attempted to release some of the things I have learned back to the community via Digital Positions' blog , but have always struggled trying to find a great place to gain information from the community whenever I need some help. This is why I was happy to discover that Adobe just released the CSS Advisor Beta. Whether you're in search of information or want to release your newest discovery back to world, this is the place to go. I have already learned some new things and there have only been a few weeks of collaboration (over the holidays, no less). I am looking forward to learning more from the community and hopefully giving something back using this tool. With the new year I also challenge you to become more involved in the community. In addition to contributing to Adobe's CSS Advisor Beta, feel free to comment on this blog and post your favorite CSS resource.

Even with all the 'warm fuzzies' that designers and developers alike get by keeping our markup separate from design, conforming to web standards, and getting cross-browser compatible CSS driven layouts out the door, there are still some days when we want to curse the CSS gods and go back to the comfort and predictability of tables. And of course it's always raining on those days. Just like yesterday. Even so, I found two viable solutions to the vertical alignment problem that has been plaguing us CSS geeks from the beginning.

As my experience with JavaScript, the Document Object Model, and CSS has widened over the past year, my complete and utter dislike of the cryptic JavaScript code had been replaced with awe of what can be accomplished with just a little bit of knowledge. However, with JS as a new found friend and the excitement of what can be accomplished, it is easy to forget about all those users who disable JavaScript. True, they may be the minority (only 10% in Jan 06 according to W3C) but they're still out there. In order to ensure these users are not left in the dust, it is important to make sure your site works both with and without the use of JavaScript whenever possible. Enter “unobtrusive JavaScript”.

Unobtrusive Javascript is the separation of your JS and your markup. You can accomplish physical separation of your code simply by using either the <script> tags or putting your JS in an external file. But unobtrusive JavaScript does not stop here. Aside from the physical separation of script and markup, there also needs to be a functional separation. This means that your site should still function as expected if a user has disabled JavaScript. True, it may not have all the bells and whistles that you can provide using scripting, but nonetheless, it should work.

I recently utilized the power of JavaScript to enhance our users’ experience on Morgan Howard’s location page. This page displays a flash map highlighting each location. Below the map is a list of hyperlinked locations with the first location’s detail displayed in a container off to the right. Upon the selection of a new location, by either clicking the location name within the flash map or the list below, the selected location's information replaces the current detail display.

Using JavaScript I was able to enhance the user’s experience by making all this happen sans page refresh. Basically, I listed each location’s information in a hidden div (display:none) and upon clicking a location name, a JavaScript function is called which hides the currently displayed detail div and shows the div we want to display (display:block). After setting this up, I sat back and admired my beautiful refresh-less interface. However, I couldn’t bask in self-praise for too long. I still had some work to do.

Disabling JavaScript had a crippling effect on the page. Our flash map only displays if Javascript is turned on and the hyperlinked location list was simply calling my JS function. With JavaScript turned off, the location link did absolutely nothing. Nil, nada, squat. The location information is now completely inaccessible. In order to fix the problem, I needed to offer an alternative action aside from the JS function call. I did this by setting up my location link as follows:

By adding “return false; after my function call, JS prevents the actual href from being used. However, if JavaScript is turned off, return false means nothing and the href tag functions normally. Then I added some Coldfusion code to check for the existence of my querystring variable “officelocationid” and to show the appropriate location information. True, this requires a page refresh but a page refresh is much preferred to not having the page work at all. Now all our users will be able to access the information they need.

Today marks my year anniversary at Digital Positions. How I survived David, Beth, and Ben’s ‘yellow’¹ approach, not to mention Eric’s phone voice, I’ll never know. But here I am, still going strong.

Has it really been a year? It feels as if I just walked through the door yesterday. But looking back I can’t believe how much has happened in the past year and how much I have grown as a developer. I have gone from being a strictly ColdFusion programmer to a much more well-rounded developer. Of course ColdFusion is still a huge part of my skill set and I have ramped up my knowledge by delving deep into i3SiteTools, DP’s own site management system, utilizing the power of CFCs, and getting my ColdFusion MX 7 Developer certification.

However, at Digital Positions I have had the chance to get involved in much more than the ColdFusion world alone. I have had the opportunity to be a part of the RIA movement by helping develop an AJAX based online application and assisting in developing a soon to launch Flex shopping cart application. I have also had the delight of becoming the lead here for all things CSS. Prior to my time here at DP, my experience with CSS was simply stylizing font and now I am creating cross-browser compliant table-less layouts left and right, and loving it.

Looking back, the past year has been a good one. And looking forward I am excited about things to come. In addition to more RIA apps coming our way, we are busy preparing for i3SiteTools going open source. There is a lot going on here at DP and I am grateful to be a part of it. Yes, it’s even worth putting up with Eric’s phone voice.

1. All DP employees have their own Herrmann Brain Dominance profile. Being a detail oriented ‘green’ planner, I’m not always on the same wavelength as those ‘yellow’ holistic conceptualizers.

Print stylesheets can be an important tool to modify the existing layout for print without having to create an entirely new template.  I recently utilized the power of print stylesheets to solve an Internet Explorer print rendering issue for one of our clients.

Have you ever wondered what the <!DOCTYPE> tag is used for? Have you even given it any thought or just simply used whatever version of the tag is included in your usual html template? Although in the past this tag has been something which could be easily overlooked with little to no adverse side affects, with W3C standards compliance on the rise, the DOCTYPE tag is no longer something to be ignored.