Archive for May, 2008
Equal Column Height using JavaScript
Thursday, May 29th, 2008I’m currently working on a project that requires that I use either some very tricky CSS or else JavaScript to make a left column div expand automatically to fit its parent container. The parent container and left hand nav appear on multiple pages, and there is different content, including that which is dynamically generated, so I cannot just add a height to both elements in the CSS.
CSS Solutions available
I looked over some CSS possibilities for this, but since I was already quite far along in the development, I thought it would be best to use JavaScript to accomplish this task. This problem should be quite simple to solve, but because of current CSS limitations, it’s a little tricky, and in fact, would be easier with a table-based layout.
Enter Javascript – with caution
The first thing a developer should consider before using JavaScript to solve a problem is whether or not the page will degrade gracefully. That is, if JavaScript is not available on the client side, will the site or page be unusable? In this case, the answer was no. The page would be perfectly usable, just not as aesthetically pleasing. And in this particular design, some users may not even notice that something is missing (namely, the bottom of a light-colored gradient background image that needs to fill the column in question).
A simple calculation through the DOM
As mentioned, I need my navigation column on the left side of the page to stretch to fit its parent container. Here is the code I’m using:
var myContainerDivHeight = myContainerDiv.offsetHeight + “px”;
var myLeftNavDiv = document.getElementById(”leftNavDiv”);
myLeftNavDiv.style.height = myContainerDivHeight;
Here’s a rundown of the code (which obviously is stripped of its event handlers and any code that needs to trigger it like a function call): On line 1, I’m putting the container DIV into a variable via the DOM getElementById method. I then use the non-standard, but cross-browser friendly, offsetHeight property to get the height of the container. That’s done on line two, which sets another variable with the value of the height of that element, and appending ”px”, to prepare it for insertion as a CSS height value. For example, if my container is 400px high, then the variable myContainerDivHeight would equal the string “400px”. It’s important to note that this value is a string and not a number that we can manipulate mathematically, due to the trailing “px”. And finally, line 3 is almost identical to line 1, only this time I’m putting the left hand div into a variable to set it up for the “400px” value that I’ve already obtained. Thus, on line 4 (I hope you’re still with me!) I set the style.height property of the left hand div to be equal to the height of the child.
Further development on this technique
This solution assumes that the left hand DIV (whose size we are adjusting) will start at the top of the parent container (whose size we are obtaining). There could be a situation where the left hand div appears below an image, or below another DIV. In this case, your code would have to take this into consideration, and you could easily subtract the height of that DIV or image from the total height, to ensure that your left hand DIV doesn’t extend too long.
Use it the right way!
I hope my readers find this code useful. I think a CSS solution to this problem would be nice, but from the research I’ve done, it does not seem that there is an easy one. In virtually every CSS solution there will be nonsemantic markup included, so I really feel that a JavaScript solution is cleaner, and much easier, provided it’s done unobtrusively.
Do You Comment Your DIVs?
Sunday, May 25th, 2008
A little background
Since I started working for my current employer, I’ve built a number of sites from scratch using CSS layouts. I’ve also had to work on older web sites built using older HTML methods. The good thing is, many of these sites have CSS-based layouts. The annoying part is that some of them suffer from divitis (i.e. too many nested <DIV> tags, in the same style as table layouts). In my view, if developers are going to use this style of layout, then they might as well use tables.
The problem is…
But getting to the purpose of this post – what I find tedious at times is when I need to wade through dozens of nested DIV tags, and there are no comments to guide me along. I might have to delete or alter one particular DIV. Or I might even have to add another DIV to the already existing mess, as it may not be in the budget to rework the whole section. But I can’t tell just from glancing at the code which DIV is the one I need to edit.
Dreamweaver offers some help
Fortunately, there’s a simple feature in Dreamweaver that allows you to right-click on any opening tag and choose “edit tag”. This highlights the entire tag, including closing tag, so you can see where it ends. But that method is not always easy, since the opening and closing tags may be in different files (because of server-side includes), and the closing tag may even be well off the screen, and so the whole section is not completely visible. Thus, you still have to do a little poking around just to ensure you’re deleting/editing the correct tag.
My recommended solution
My solution to this problem is to put a comment at the end of every single DIV in my HTML. Here is an example:
I know, it adds to the file size, and it can be pointless at times (for example when the closing DIV tag is on the next line with nothing nested). But commenting ensures that anyone who needs to look at the code will be able to read it easily, and most importantly, be able to discern almost immediately which section of code he will have to edit.
I think this is a good, clean, and universal solution to many code reading issues, and I find that it should be considered a “best practice” — especially in complex CSS layouts.
One caution about using this method: Including multiple comments in a CSS layout can trigger the IE6 ghost text bug. But the simple solution is to put the comment just inside the closing div tag. It’s not as clean looking, but it’s an acceptable workaround.