Here.

I’ve been up for a while now wrestling with a seemingly simple problem–how do you vertically center a fixed-size DIV without allowing it to crawl off the top of the page? And it turns out that the solution was much simpler than I expected, so I initially looked right past it. It includes some JavaScript though, so it’s not right for everyone.

Here’s the setup: I have a fixed-size div containing a flash movie. I want this flash movie to appear perfectly centered most of the time (easily done using some simple CSS), but I also want it to respect the top of the page, so if a client’s window is shrunk below the height of the movie, the top doesn’t appear “cut off”.

The first step was to do the centering. Let’s say my div, called “content_container”, is 900px by 675px. This CSS will center it both horizontally and vertically:

#content_container {
position:absolute;
width:900px;
left:50%;
top:50%;
margin:-337px 0 0 -450px;
}

Works! Unless, of course, the browser window is less than 675px high, in which case the div (while technically still centered) shifts off the top of the page. This is the issue.

My first instinct was to use Javascript to grab the coordinates of the div and make sure the top was at least zero. If it wasn’t, I’d set it to zero. And while that worked well for keeping the top from sliding off the page, it introduced a logic issue: once I set the top to zero, a test for “less than or equal to zero” is useless, and the div is stuck in one position. In other words, even if the user resizes their browser to an acceptable size, once the script fires the div will be stuck at the top.

After tinkering with it for like an hour, I realized that I’ve been taking the wrong approach. I don’t need to know the div’s position at all. All I need to know is whether or not the window is at least 675px high. If it’s not, I set the top to 337px (which, counting the negative margin, puts it at zero). If it is, I reset the top to 50%, and we have our centering back.

So first, I figure out the height of the window (adapted from this handy bit of code, which is pretty browser-friendly all the way back to IE4):

function getWinHeight() {
var myHeight = 0;
if( typeof( window.innerWidth ) == ‘number’ ) {
myHeight = window.innerHeight;
} else if( document.documentElement && ( document.documentElement.clientWidth || document.documentElement.clientHeight ) ) {
myHeight = document.documentElement.clientHeight;
} else if( document.body && ( document.body.clientWidth || document.body.clientHeight ) ) {
myHeight = document.body.clientHeight;
}
return (myHeight);
}

Now I check this height against our div’s height, which is 675px. If it’s less than that, I reset the top to zero. Otherwise, I make sure the top is 50%:

function fixPos() {
var thisTime = getWinHeight();
myDiv=document.getElementById(‘content_container’);
if (thisTime < 675) { myDiv.style.top = "337px"; } else { myDiv.style.top = "50%"; } }

I call this fixPos() function from both the onLoad and onResize events. And while using the onResize event can make things a bit twitchy (especially in Firefox), it totally works. Of course, folks with JavaScript turned off will have to settle for the non-corrected position.

If anybody has another, cleaner way to vertically center a fixed-size div, gimme an email. I’d be totally interested to see it.

So just as I was buying champagne for my validation party, Albert Banks’s Netflix plugin for WordPress broke my website. Well, not really–it just introduced a small, annoying error that I’ll have to fix somehow: any “&” symbols that are rendered through the plugin (for example, the one in Romance & Cigarettes, which I have at home right now) don’t get converted to the correct character entity.

XHTML 1.0 assumes that every instance of the “&” symbol is the beginning of a charcter entity, and it gets cranky when it’s not followed by a valid reference and a semicolon (like this: &amp;) . Even in alt tags and URL strings.

Not a big deal, really. And it’s something I might not have even noticed if I hadn’t had that particular movie at home right now. Some quick PHP changes should fix ‘er up.

According to this New York Times article, AT&T will be offering free wireless internet at most Starbucks stores beginning this spring. I’ve long hated T-Mobile (Starbucks’ longtime, money-gouging internet partner), and I’ve wondered why anyone would hang out at a Starbucks when so many mom and pop cafes offer free internet access. This must have been frustrating for Starbucks as well–especially in a city like Austin, where virtually every type of business, including movie theatres and bookstores, offer free wifi.

There is a small catch though–only customers who use a Starbucks purchase card will get free time. The rest will have to pay $4 for every two hours of use, or $20 per month (which will also grant access to the nationwide network of non-Starbucks AT&T hotspots). But compared to T-Mobile’s pricing, that’s not bad at all. They charged as much as $40 per month, $10 per day, or $6 per hour for internet use.

In emergencies, I’ve sometimes grudgingly paid for the $10 day pass, but I’ve rarely spent more than an hour online at Starbucks. So a cheaper, two-hour plan seems much more reasonable to me.

Today I finally ran this new site through the W3C validator, and found that I had all kinds of red exclamation points. Some of the errors were simple oversights on my part, but most of them revolved around my header, which is an embedded flash movie.

Ever since IE7 sent web developers into a panic by breaking the object and embed tags (then fixing them again), I’ve been using Macromedia’s AC_RunActiveContent.js to render flash movies. The problem is, the script writes unnecessarily ugly code that doesn’t validate as XHTML 1.0 Transitional, so it kind of makes me look like a chump.

While searching for a solution today, I found Drew Mclellan’s brilliantly simple, five-year-old Flash Satay method, which works really well for my purposes (a small flash movie that doesn’t need to stream). To accommodate IE7 users who haven’t updated their browsers yet, I wrote my own very simple JS function that doc.writes the necessary object tag. It looks like this:

function make_flash(swfPath, swfWidth, swfHeight)
{
var str = ‘<object type=”application/x-shockwave-flash”‘;
str += ‘data=”‘ + swfPath + ‘”‘;
str += ‘width=”‘ + swfWidth + ‘” height=”‘ + swfHeight + ‘”>’;
str += ‘<param name=”movie” value=”‘ + swfPath + ‘” />’;
str += ‘<param name=”allowScriptAccess” value=”always” />’;
str += ‘</object>’;

document.write(str);
}

Much, much simpler (but, admittedly, less flexible) than the Macromedia code. In the spirit of thoroughness, I also created a straight HTML version of the header for users with Javascript turned off.

I also learned another strange lesson while trying to get this seemingly simple flash header to work: if the user visits you at, say, http://angryrobots.com, but the link in your flash movie points literally to http://www.angryrobots.com, flash will see this as a cross-domain transaction, and won’t execute the getURL command. It doesn’t throw an error either–it simply doesn’t work. This is an issue for me, because I have two domains pointing at this site, and I can’t control whether or not users will type in the "www". So to combat this weird behavior, I had to throw in the "allowScriptAccess" parameter with a value set to "always". Lesson learned for next time, I guess.

Anyway… if you have another simple, flexible, standards-compliant method of embedding flash movies, please shoot me an email. I’d love to hear it.