CSS

The problem recently presented itself to me when writing some new functionality for revealCMS: I needed to set some variables to load in the page head, but could only be set after a portion of the body had completed rendering. I wrote a plugin that essentially loads a different stylesheet depending on the input of the Smarty template function. The hard part wasn’t assigning the variable – it was figuring out the best way to get that assigned data to appear in a part of a page that had already been rendered – the head.

It makes sense why Smarty would work this way – that you can’t go back and re-assign variables. It would be too messy. So somehow you need to assign the variable first in the body, then go back and render the head. It’s simple… really. Believe it.

But why bother? Why not put <style> tags directly into the page body where the plugin is located? The reason is simple: <style> tags (and <script> tags, for that matter) MUST be in the page header. It’s a web standards thing.

First, break-up your page templates into two sections: the header (containing everything before the <body> section of your template), and the body, which contains the <body> section. First render the body using$body = $smarty->fetch('body.tpl');
At this point, I’ll just assume that your page functions have loaded and you’ve either placed an {assign} tag somewhere in the template, or you’ve used a $smarty->assign() inside the template function. If you’re not familiar with $smarty->fetch(), it’s just like $smarty->display(), except it outputs the contents to a variable rather than the screen. And just like display() it can also take $compile_id and $cache_id as optional parameters.

Now render the head:

$head = $smarty->fetch('header.tpl');
By this point everything should work-out as we expect it. Our dynamically loaded css file is loaded in the head and our standards friends are happy. The beauty about this example is that you can now render a number of items in any order you need them then display properly, so long as it makes logical sense.

Here’s a tip: You can use this method to dynamically load javascript files and frameworks if your fancy web 2.0 page functions/plugins need it at some times, but not at others.

I found an interesting “bug” in Apple’s Safari today while updating a page on Flood’s deprecating website (new version coming up in September). First of all, for the record, nobody on the team designed the template currently in-use (Aug, 2006).

I just needed to put an anchor near the end of the page… pretty standard stuff. The problem is that Safari wasn’t jumping down the page – only a couple lines. Odd because IE and FireFox jumped just fine. I’d never had that problem before, but I traced it down to something pretty simple (and maybe even conceivably reasonable). Safari jumps to the beginning of the paragraph or div that the named anchor resides in. The problem with the Flood page is that the original designers didn’t really use p tags, or divs, for that matter (in fact, simply adding a p tag will disrupt the page design… go figure). So Safari would simply jump down to just below the heading tag.

First off, I don’t want people to think I’m some kind of web genius or something. I’ve been doing web design in my spare time (save my college years when I really didn’t have the time), since 1995, and it hasn’t been until recently that I’ve put much more effort into developing my skills. Designs are getting better and I’m very pleased with my self-taught PHP skills.

That said, I haven’t really had much chance to dabble with CSS until this past fall. I’ve used it many times for simple styling, but never serious layout. After struggling with some layouts ImageReady prepared from a mockup, I decided it was time to leave the table behind (except for the exact sliced image layout). I must say that given the same amount of time trying to get both methods to work, I was considerably farther along using CSS than I was with using tables. Even better, the code is so much cleaner – expected for a CSS project. I love CSS!