CSS Meltdown
About half way through testing, I'd completed the editing and code checks and had worked my way through the link and accessibility checks. I switched CSS on for the first time during the formal testing procedure and everything looked great. Then I started testing resizing text. Problems. Then I checked zooming in and out. Problems. Then I tested resizing the browser window. Problems. I'm not sure exactly where, I suspect it was when I tried to play with different ways of constraining the design to show the optimal 60 characters per line. Anyway, at 1024 pixels wide, the screen can nicely accomodate the layout, however around 800 pixels wide it starts to stick out the side of the window creating a horizontal scrollbar.
#mainContent {
/*
position: relative;
width: 48.5em;
min-width: 61.73%;
margin-left: auto;
margin-right: auto;
*/
}
This code seemed to have a lot to do with it. Increasing the effective line length by narrowing the browser window or increasing the font size or zoom factor, caused the 48.5em width to stick out of the side of the browser. Since all the other properties are designed to properly control different related behaviors, I simply commented out everything. This still left a fundamentally two column layout which still created horizontal scroll bars in all three browsers. So I merged the Main Points boxout inside the same column, #mainBody, with the content; just like before I'd configured everything for 60 character wide layout. This seemed to be the best option.
However, that caused the text to run from the extreme left to the extreme right of the screen, obeying only the basic page padding I'd applied to the #innerContainer div. This looks OK but cramped. Therefore I readjusted the left and right padding on the #innerContainer div to give me some more space. The top (5em) and bottom (4em) padding are unchanged but I added about 40 more pixels to the left and right side. If you don't remember, I prefer to do everything in ems, however applying this whitespace to the page with ems caused massive gaps when the size of text is increased. Since this increases each line's effective length, and that's about the only thing that can cause my layout to breakdown, I've gone with the less flexible pixels instead.
#innerContainer {
padding: 5em 100px 4em 75px;
}
Adjusting the left and right margin broke the Topkapi stain margins, so I adjusted the margins of the background image so that it lines up again. I also caused the bottom navbar, #siteWideNavbarWrapper, to drop it's final button onto a second row. I'm not willing to accept that as the default behavior for a maximized browser at 1024 pixel wide resolutions. So I pushed the right margin on the navbar (it's an unordered list, ul), until the buttons all line up in one row.
#siteWideNavbarWrapper ul {
margin-right: -7em;
}
This is exactly why I have such an extensive testing procedure. If this had made it to the live website, it would have been a nightmare to try to correct; or worse, it might have stuck and waited until the next push to correct it. As it was, I simply modified the current batch of CSS files which are running the beta website and moved the in page navigation location in the primary master page for all sites. It took 15 minutes to change one batch of files and the revised CSS will go sitewide for Earth Chronicle when I push it up.
CSS Salvation
I've also run into problems with the image in the contact form; in this case CSS bailed me out. Because the image receives a funky master page determined id, it changes between the EC and the Beta site. That means I would have to write a second javascript routine in order to display the same contact form image. Even worse, because I have the new Roman Forum and home pages that don't have a nested master page, they're controls are yet again, different. Which means I need to write yet additional javascript routines. This is verging on the ridiculous, so I yanked the image and replaced it with the same div in both contact forms. Note that they aren't processed by the server so their IDs won't change, halving my work.
<div id="contactImage" title="Contact Us!"></div>
The img element was floated left, so the div needs to be too. I simply swapped their IDs in the AllSites stylesheet. Since this is a div, I'm not setting height and width in the tag so I included the 150px square dimensions in the same place. And since my img elements receive padding in the stylesheet I had to apply a right margin of 1em to keep the headings from smashing up against the div. Now I can control the image that goes in it from each of the site specific stylesheets. Here's the new Earth Chronicle CSS based rollover.
/* Rollover Images */
#contactImage {
background: url(../../../EC/AllSites/Images/EcDesignImages/ContactUsBox5.jpg) top left no-repeat;
}
#contactImage:hover {
background: url(../../../EC/AllSites/Images/EcDesignImages/ContactUsBoxHighlight5.jpg) top left no-repeat;
}
It's a simple use of a hover to achieve the rollover and I specify the location of the images. The Beta site stylesheet is updated identically except for the images referenced. And I can even apply this to any new contact form components I create without adding or touching the CSS. I can even use the form components across both sites simultaneously, and because the image and its rollover are applied in CSS, the stylesheet for each site will correctly identify the div by its ID, #contactImage, and apply the proper CSS. :D Can't beat that.
During testing, it's become obvious that using a CSS pseudo-class, :hover, is a much better implementation to trigger the drop down menus than using Javascript. The drop down behavior should be active when the CSS is on and the menu is in it's proper form. When the page is rendered without CSS, the functionality makes no sense and is distracting; ie, it's bad when CSS is off but Javascript is on. And if the drop down menus are driven by Javascript when it is not available, the menus are hidden and cannot be activated when CSS is on. Both of these issues have vanished by triggering the behavior with CSS.
Technically by code separation, this is a bad thing as it mixes the semantic purposes of the technology, and there's no question that this is unfortunate. However, in order to achieve the correct functionality it was a necessary change. And while this violates code separation, we are still able to implement the principle one-feature / one-location. There is only one place that this behavior exists and it's functionality can be easily controlled and maintained from this point, which is one of the most important reasons for code separation.
[chroniclemaster1, 2009/11/05]