Site Elements
How this site "works".
As you might have noticed by looking at the page names in your browser address window, the site is built using PHP rather than straight HTML. There was one very simple reason for this: it completely seperates layout from content. This makes both design changes of the various layouts much simpler as well as allows for the easy integration of additional layout options.
Every page uses the same basic template:<?php require("top_php.inc");?>
-- body for this page --
<?php require("bottom_php.inc");?>
top_php.inc and bottom_php.inc are both files that include nothing but PHP code to determine which layout the user has selected and then select the files and set a cookie for that layout. The psuedocode for those files looks something like:
if layout=tables then require top.inc and bottom.inc
if layout=css then require top_css.inc and bottom_css.inc
if layout=pro then require top_pro.inc and bottom_pro.inc
It is the files top.inc, top_css.inc, top_pro.inc and their matching bottom_*.inc files that actually create the layout. This means if I want to tweak one of the existing layouts, I just change those two files and ALL of the pages will reflect the change. Contrast this with having to change every single page any time I wanted to change a layout, and the advantage of PHP becomes obvious. Now, when I add an entirely new page, I end up changing all the layouts with a menu section (currently top.inc, bottom_css.inc, and bottom_pro.inc), but that is still quicker and easier than changing every single page.
Finally, adding new layouts simply requires adding an additional selection to the top_php.inc and bottom_php.inc files. Again, I only have to change two files rather than every single page.
Tables vs CSS vs Professional
When I first put this site together, I went with a table design. Tables have been used for HTML layouts for a long, long time. While a far from perfect solution, the simple fact they've been used for so long means that virtually all browsers read them correctly, and they behave in ways users have become familiar with.
Of course, even my table layout still used some CSS. I wanted links that "popped" so that users could tell very easily when their mouse was hovering over a link. I also wanted to simplify the coding needed for the various text styles. A linked stylesheet accomplishes that.
The purple links, white text on black background, thick borders, etc. were all chosen because I liked them. I really didn't have any better reason than that when I chose how the page was going to look.
The CSS layout came next. The entire goal of this layout was to use CSS to make a page that was as close to identical to tables as could be. This is not as easy at it sounds. In fact, it proved to be a significant challenge.
CSS divisions do not function like table cells. They do not automatically match the height of neighboring cells. Unless you specify a height, they are only as big as they need to be. If you do specify a height, that's how big they are (except in Internet Explorer which I'll talk about in the Broswer Issues section of this page). On any site that uses a left-side or right-side menu that has obvious borders, this can make things look "wrong". On my site, it meant that the purple box around the left menu was always the same size, and it never matched the content box which changed sizes depending on how much stuff was on the page
CSS does have table elements, and I could have simply created a CSS table to solve the problem. However, I felt like that would have been cheating. Moreover, it wouldn't let me put the menu after the content. For visually impaired users with screen readers, this means they are required to hear the entire menu on every single page before getting to the content. Putting the menu code after the content fixes that. So, I needed another solution.
The solution was to embed the menu and content divisions inside another division, and then use a background-image property of the container division with repeat-y set to draw the vertical bars that were in the table version (The Repeated Background). This means that the menu division is still only as big as it needs to be fit the menu items in it, but it looks like it is the same size as the content section because there is a border around it that matches the content division. Of course, the content division doesn't actually have a border either. The background of the container draws them all.
The professional layout came last. This layout had a definite audience in mind when I created it: professional users, businesses, and prospective employers. I wanted a layout that users would feel comfortable with and that created a sense of trust in its creator (me). I also wanted a page that would validate on the W3C Validator.
(side note: The entire site does not yet validate. The index, site elements page, and a few others do as does the template for the pro layout. Getting the entire site to validate requires tweaking the content pages that were not originally put together with validation in mind, and hence, uses tags like <BR> instead of <br /> amongst others).
For starters, I went back to black text on white background. Virtually every web usability study done shows this to be the easiest for users to read. Next, the menu colors are a dark blue on a lighter blue background. Blue implies trustworthiness, a highly sought-after quality in potential employees. Last, the links still change color and add the underline element with users hover over them to make it easy to identify links.
As for the layout, it's fairly standard. There is a top bar with a logo (my picture), the site title (BretMcBride.com), and a catch phrase (My communication skills showcase). There are millions of other business pages that have this exact same section.
The next section is the menu. For this layout, I decided I wanted something more than just having links that changed colors. I wanted the entire box containing the link to change colors, and I wanted a tab-like look to the menu. Getting the boxes to change color was actually fair simple. I justed added the display: block property to the nav class that I used for the menu items, and then used DHTML to change the background color on the divisions. This allowed me to have my color-chaning boxes. I also did it without using javascript which makes it more 'browser-safe' and works even for users who turn javascript off in their browser options.
The tab appearance took a bit more work. This can be done client side using javascript which is how quite a few sites pull it off. But, I didn't want javascript on my pages. Plus, since I was using PHP to build the pages server-side anyway, I decided I might as well use it to build the menu with an active tab. The code for the menu section identifies the current page, and then uses the currentnav ID instead of the nav class for creating that division in the menu. The currentnav is slightly wider which allows it to cover up the space between the menu and content giving it that tab-like appearance, and it is also white both matching the color of the content division and making it obviously different than the rest of the menu links.
Browser Issues
I came very close to calling the section of the page, "Why Internet Explorer Sucks". All of the problems I had with my CSS layouts (the table layout works great across browsers) were in IE. And, since I've also been playing with IE 7 beta, I'm fairly confident that the problems I had with IE aren't going to be fixed when that program goes public.
There is an entire web design holy war around whether or not to use hacks. On one side, you have the purists who believe that the only way to force browser programs into compliance is to quit coding around them. This side is also adamantly opposed to hacks - using bugs to hide other bugs. On the other side are the realists who want users actually using their site no matter what browser they choose. If that means hacks, so be it. Personally, I'm a little of both. I want users to be using my site now rather than waiting (possibly forever) for browsers to all be CSS compliant, but at the same time, I'm also fairly opposed to hacks since there is the very strong possibility that eventually, whatever bug you use to create the hack will be corrected which in turn will break your site.
The first major issue with IE is that it doesn't support the min-height property. For my pro layout, this made it possible for me to have pages where the content box was smaller then the navigation menu. This just looks wrong. In fact, IE treats the 'height' property the same way W3 compliant browsers treat 'min-height'. In most browsers, if you set a height to a division, any content that doesn't fit inside the division is simply cut off. This is how it's supposed to work. If you want to have a minimum height but allow the division to expand if needed, you use min-height.
In IE, if you set a height, and the content doesn't fit, IE makes the division taller. However, as stated above, you cannot do that on any other browser as it will cut off content. At the same time, IE doesn't support min-height at all, so you end up needing two different properties to accomplish the same task depending on which broswers the user is viewing the site on. This leads to the majority of the CSS hacks that are out on the net. Of course, while IE7 doesn't fix all the CSS issues, it does fix a lot of the bugs web designers used to create their hacks. So, IE7 is not only not going to make IE CSS work right, it's actually going to break quite a few of the methods other web designers have come up with to get around IE's problems.
So, I had to come up with a solution which didn't exploit an IE bug to 'fix' the IE min-height bug. Ironically, my solution seems much, much simpler than any of the hacks out there. I simply stuck a 495 pixel high division inside the content division on every page and floated it to the right. This works like a pry bar forcing IE to keep the division at least 495 pixels high, and by floating it, all browsers simply wrap the text around the prybar. Given that the prybar is only 1 pixel wide, it is almost impossible to notice. It also is not a bug exploit hack, and I know it works in the current build of IE7. So, it should be fine for the forseeable future.
The only other display issue I had on the pro layout was also IE related. My copyright bar was missing in IE when I first put the layout together. Actually, it wasn't missing, it was just buried underneath the content section. There is no hack to fix this without putting the divisions in the code in the same order they appear on the screen. Since I wanted my content section to always be the first thing in the code (for accessibility), this was not an option. IE simply doesn't do CSS positioning correctly. So, PHP to the rescue again. If you load the pro layout in IE, you get different code at the bottom of the page. It puts in enough blank space to get the copyright division out from underneath the content division. I've also tested both versions in IE7, and sadly, IE CSS positioning is still broken in the new version.
The last browser related issue has to do with IE's poor PNG image support. PNG images have transparency. The transparency layer works in every browser with PNG support except IE. Now, most of the graphics on this site are square, and hence, have no real use for transparency. However, the montage of old pictures of myself that appears on the homepage is not. So, I created it with black to fill in the outside areas because my original layouts both had black backgrounds. When I created the pro layout, though, this became a problem. The huge black splotches in the corner were a distraction and simply looked amateurish. The easy fix would have been to use a PNG for the image and set the corners transparent. Only, IE wouldn't have displayed them properly. So, like all the other IE specific problems, I fixed it with PHP. For the table and CSS layout, the home page uses the black bordered montage. For the professional layout, it uses one with white borders. As a side note, this is the one problem I found that is actually solved in IE7. Of course, since it will likely be many years before a majority of IE users make the switch, it doesn't actually mean that much to my site.
