Tag: Code

A useful tip if you love both YouTube and markup validation

Not valid!YouTube is worlds apart from the likes of MySpace (*shudder*) when it comes to good code, but like most massively influential sites, they don’t really seem to care that much if their code validates, and even less if the code they provide webmasters for embedding content in their own sites does.

Frankly, I usually don’t care that much about validation either. I worked in this field for too many years when no validators even existed, and I’ve always taken the pragmatic approach: make it look and work the same, more or less, in all reasonably recent versions of Internet Explorer and Netscape (with Firefox and Safari having replaced Netscape over the past few years), and be done with it.

But I still have to admit that it’s a bit embarrassing that the “Valid XHTML” link (which appears in the Meta sidebar by default in WordPress) proves just how not valid my XHTML really is. I checked it today and was shocked to find 76 errors. I was relieved, however, when I dug in and discovered that only three of those errors had been my own. I had nested a <ul> inside a <span> (which I honestly didn’t even realize was a mistake, although I understand why it’s wrong, and it was easy enough to change from <span> to the valid <div> without any visible difference), and I had omitted alt attributes from a pair of images that don’t need to be identified by page readers anyway (and would probably be better off being worked into the CSS somehow).

These were pretty minor errors, if I do say so myself. 67 of the remaining 73 errors originated in cut-and-paste code blocks I got from PayPal and LinkShare (the latter of which I deal with only very reluctantly because they provide the mechanism for Apple’s iTunes affiliate program). What a surprise that the code from these sources looks like it was written by a tech support grunt in 1996 (in other words, by me in 1996)!

These were easy enough to fix, as well. I’ll just need to remember to fix them again if I ever change the code in those ad blocks, which I’m sure I will. The final 6 errors were the result of a YouTube video embedded in one of my blog posts. Ah yes, the age-old <object> vs. <embed> conundrum. I’ve always hated <object> because it seems unnecessarily complicated, with a slew of nested <param> tags that could just as easily have been attributes of the tag itself (although I suppose the point was to allow new parameters to be added without having to add support for new attributes in the DTD); plus it reeks of Microsoft’s platform-dependent ActiveX crapfest. I especially loathe the presence of, and need to hunt down, a ridiculously long, completely arbitrary clsid string representing the file format of the embedded file. (What’s wrong with a freakin’ MIME type?)

Unfortunately, the cleaner and more straightforward <embed> has never been part of any HTML specification, so it doesn’t validate.

Now it appears that there’s a solution to embedding YouTube videos in an XHTML-compliant way. Huzzah! But that means I’ll have to go back through all of my posts that have YouTube videos in them (which is a surprisingly large number) and fix them. It should be easy enough to hit them all at once with a well-constructed SQL query; I just need to study the pattern and do it. In fact, if I’d spent the last 15 minutes studying the problem instead of just complaining about it, I’d probably be done already.

But sometimes, complaining’s just more fun.

A configuration-based solution to the translucent menu bar in Leopard

I had forgotten I’d even found and tried this until I looked up at my menu bar today after changing my desktop image and noticed it was opaque. I can’t find the site where I originally got the code, but I’ve found another blog that mentions it. The code to execute at the command line is:

sudo defaults write /System/Library/LaunchDaemons/com.apple.WindowServer 'EnvironmentVariables' -dict 'CI_NO_BACKGROUND_IMAGE' 0.63

(The code all needs to be entered on one line, of course; I need to work on my CSS for displaying code, probably employing Google’s Syntax Highlighter. So add that to my gigantic and ever-growing — at an increasing rate — to-do list. At my present trajectory, I will get this done approximately 10 million years after never.)

As the poster notes, the number 0.63 at the end can be any decimal value from 0 to 1. It represents the lightness of the opaque menu bar: 0 is black, 1 is white, and anything in between is shades of gray (surprise!); all non-white values have a subtle gradient as well.

This works great, which is not surprising, since this is the way Apple designed it to be managed. (In other words, they didn’t intend for the end user to be able to adjust it at all… but they built a way into the code to allow their programmers to adjust it.)

Of course, in the meantime since I first complained about it, I have actually come to tolerate (if not like) the translucent menu bar. But for now I’ll leave it as it is. If I do decide to change it back, I’ll run this:

sudo defaults delete /System/Library/LaunchDaemons/com.apple.WindowServer 'EnvironmentVariables'

And of course, because these are system-level changes, you need to reboot for them to take effect (which is probably why I had forgotten I’d done it in the first place; I didn’t restart immediately and surely got distracted by whatever it is in my life that’s constantly distracting me… two kids, perhaps).

Yes, Virginia, there really is a difference between null and false

Fairly often, it’s necessary in PHP programming to write your code around the fact that, most of the time, PHP does not distinguish between null, false and 0, although there is, nonetheless, a distinction between all three.

Today I ran into one of the few instances where I was expecting PHP to treat them as equivalent, but it did not.

Often I am working with arrays, and I write conditionals that should only execute if there are elements in the array. Technically the proper check for the status of an array-type variable is the is_array() function, but most of the time I don’t use that. I may have initialized the array variable or not, but that’s irrelevant to me; what I care about is whether there’s anything in the array, so I just use count() instead.

These days I’m working on some object-oriented code, and I’ve been writing several “get” methods that return either an array of data or, as I had originally written them, a false value if no matching data exists.

Fine. But then I applied some of this new OO code to an existing page, and found that one of my count()-based conditionals was evaluating incorrectly. I checked the variable, whose value was set by one of the object methods, and as anticipated, its value was false. But strangely, the count() function was returning 1 rather than 0 when applied to the variable.

I resisted my initial temptation to switch from count() to is_array() because I don’t want to have to change every place where I use it. Then I tried changing the “failed” return value of the method from false to null and, what do you know, it worked!

So now I’ve gone through all of my various “get” methods and, on failure, they’re returning null instead of false.

Wow, I’m a reference in an O’Reilly code sample!

That’s not Bill O’Reilly, thank you very much, but O’Reilly, the much-lauded publisher of technology reference books.

Doing a bit of narcissistic “googling,” I discovered that my site appears in the sample code in an article O’Reilly published on their xml.com website on the topic of hacking iTunes. Cool!

On a less random (and ultimately more satisfying note), I also discovered that my Coltrane thesis was cited in an academic book called Cognitive Science, Literature, and the Arts: A Guide for Humanists. Wow!

The Case of the Missing Nav Bar

I will admit, sometimes the problems I encounter in Internet Explorer are simply due to slight differences in browsers’ implementation of HTML or CSS or whatever, and I’m just not properly accounting for the way IE does certain things. Other times, it’s true, they’re due to a flat-out bug in my code that Safari and/or Firefox (usually “and”) will just graciously accept, whereas IE will not. (The cases where IE catches errors that Safari and Firefox permit, however, are rare compared to the vast, cluttered landscape of bad code that IE welcomes with open arms but that Safari and Firefox rightly reject.)

And then there are the cases such as the one I encountered today. There’s no way around it. I can’t find a nicer way to put it, IE is just plain fucked up.

Yesterday I was going along innocently enough, demonstrating to a coworker the site I had been working on for him. As usual I had worked with Safari and Firefox as my test browsers, firing up IE through a remote connection to my PC as needed to make sure things weren’t completely off track. (In a perfect world, I would never have to do this, of course. But, well…) And then, wham! Of course this kind of problem only rears its head when you’re showing your work to someone who has the authority to reject it. I was convinced it was a fluke on his computer, but sure enough when I went back to my desk, I observed the same thing happening in IE on my own PC. Time to hit the brakes once again and go into IE debugging mode.

I tested all of the obvious things. No luck. So I dug a little deeper and started testing the more obscure, but at least logical things. Still nothing. And like so many times before, I was reduced to just randomly trying anything to see if I could get a different result, no matter how seemingly absurd.

Fortunately it only took about an hour to track down the problem this time. But as usual there was no satisfying resolution, no “Aha!” moment as I suddenly recognized a stupid mistake I had made. Oh no. The problem was that the CSS definition for the <div> tag containing the entire body of the page specified a background color. Of course! (No, not of course, as this should not have any impact whatsoever!)

*SIGH* Seeing as how that background color specification wasn’t technically necessary, I removed it. Problem solved. Frustration with Microsoft, higher than ever.

Web 2.0 — opening up a whole new world of Internet Explorer quirks!

Just when I needed it least, Internet Explorer has thrown me another curveball.

I’m hard at work trying to seem like less of a 20th Century web dinosaur by acquiring new skills with these techniques that are loosely lumped together into what some call “Web 2.0.” Key among these is an approach called AJAX (Asynchronous JavaScript and XML). Fun stuff. I’ve been working for the past several days on an interactive registration form for a site at work, using AJAX. Of course, as usual, I’m plugging away in Safari and Firefox, but eventually I decided to check out how things are looking in Internet Explorer.

[When I figure out an emoticon that represents my head exploding, I'll insert it here.]

IE is consistently barfing on what it claims is a syntax error that I eventually tracked down to the evalScripts function in prototype.js. Well, at least it’s not my own code that’s making it crap out this time. Or is it? With IE you never can tell. Maybe evalScripts is buggy (even though I can find no evidence to that effect) or maybe it’s just the code in my script that’s being thrown at it. Whatever the case, once again all forward progress has come to a grinding halt while I scour the Internet fruitlessly for a solution.

Although this turned out not to be a solution to my problem, I just have to refer you to this developer’s blog entry on a typical IE workaround. Yes, I tried this, even though I was almost positive his problem was completely unrelated to my own (which was the case). Nevertheless, when a problem does arise in IE, the most likely eventual result of one or more days’ worth of sleuthing is the resigned acceptance of such hokey code bloat, rather than anything even remotely satisfying (or even logical).

There you have it. As for my own problem using prototype.js with IE, I did find a solution. Yes, it was my code, and it was something I had seen previously that was pretty much staring me in the face, if I had just bothered to heed Thomas Fuchs’s sage advice.

It all comes down to standard practice for wrapping <script> tags in HTML. I still have the habit of doing it this way:

<!–
//–>

The funny thing about that is that I know it’s completely pointless these days. It’s done so that browsers that don’t support JavaScript don’t inadvertently display the JavaScript code in the web page. But every browser has supported JavaScript since about 1997, so it’s pretty ridiculous to keep doing that. Especially given that, the way the sites I’m working on are so utterly dependent upon JavaScript, you’d never even get to the page in question without it.

However, with XMLHttpRequest (which is at the heart of AJAX), and just the increasing complexity of JavaScript in general, it’s become necessary to wrap script code in a new tag to ensure that browsers handle the code properly. To wit:

// <![CDATA[
// ]]>

Just as Thomas Fuchs said. And just as has been lingering in the back of my mind for the past several weeks, since I first discovered his wonderful tool based on prototype.js, Scriptaculous. I’ve learned my lesson.

‐.‐‐‐.‐‐‐‐..

Wow. For all my many years of waxing and waning Rush fandom, including having played several of their songs on the bass myself in a band a few years back, I never knew this about one of their oddest songs, the instrumental track “YYZ.”

Yes, of course I know YYZ is the code for the Toronto airport. But what I never realized, even as I was playing that rhythm, is that the opening of the song spells “YYZ” in Morse Code!

(I must admit I have some misgivings about saying I never realized it. I vaguely recall that as my bandmates and I were working the song out — from memory, not a recording — I was convinced that the last part of long beats was 5 and not 4, but the other guys might have used the Morse Code argument to prove me wrong. In fact, even tonight as I read about this and played the song in my head, I was still thinking it was 5, and, in my usual cocksure way, thinking “these websites have it wrong!” or “the band messed up the ‘Z’!” But then I actually listened to the song and realized it’s 4. Then I assumed the band I was in must have played it wrong, since I was so sure it was 5. So I listened to our recording of it and sure enough it was 4 there too! I guess the only thing that proves is that once again, it’s a bad idea for me to stay up too late on a Saturday night surfing the web.)

Here’s some more on the matter…

While I’m on the subject of Rush, I quickly googled (yes, it’s officially lowercase now, much to Google‘s chagrin) and was surprised to discover that, apparently, my high school friends and I are the only ones in the entire wired world who ever thought the band’s self-titled debut album cover looks more like it says RLISH than RUSH.