What’s that close paren doing after my video embed in WordPress?

Working on a new client site that has a lot of YouTube video embeds, I was alarmed this morning to find a stray close paren ) character in all of the posts right after the videos.

Knowing I had recently been tampering with the embed_handler_html and embed_oembed_html filters in the site theme, I figured it was something I had created. So I set about debugging my code but couldn’t get anywhere.

I decided to see if it was in fact a new problem in WordPress itself, by setting up a test post on this site with a YouTube video embed (this, of course). Sure enough, even on my unadulterated theme, the stray close paren appears.

Look at it!!!I mean, just look at it!!!

Anyway, I hope/assume this will get fixed in the WordPress core soon, but in the meantime if you are running into this problem and want a quick fix, and you’re not afraid of editing the functions.php file in your theme, have a go at this little addition that will strip out the offending punctuation:

function embed_fix_stray_parens($content) {
    return str_replace('</iframe>)','</iframe>',$content);

Update #1: I went to submit a bug report to the WordPress development team and found my report was a duplicate of this one. If I understand correctly, the close paren is actually being delivered by YouTube itself, not WordPress, via the oEmbed request. Isn’t the Internet fun?

Update #2: This really is YouTube’s problem… it even shows up in the embed code you get on their own site:

Screen Shot 2014-03-12 at 11.00.12 AM

This issue is also showing up on StackOverflow now, including a more efficient temporary workaround for WordPress sites than my own hasty solution.

My (just-discovered) workaround to the WebKit letter-spacing bug

Update (5/29/2012): Upon working further with the project that formed the basis of this post, I discovered that my solution did not work, or at least, no longer worked. It’s not uncommon as I get deeper into a project with a large CSS file that there are subtle, inadvertent effects of the various CSS properties that get added along the way. Looking back now, I can’t determine for sure whether my solution did once work with the simpler version of the site, and something else I added later counteracted it, or if I was just too eager about a solution to realize it never quite worked in the first place. As a result, I had considered deleting this post entirely, but I have decided to leave it live, to further the discussion of the topic, or at the very least to serve as a monument to my challenges.

WebKit, the rendering engine “under the hood” in both Safari and Chrome, has a known issue handling the CSS letter-spacing property at certain small increments, and at certain font sizes.

Specifically, if defining letter-spacing in increments smaller than 1px or 0.1em, it seems to just ignore the property altogether… except at larger-than-default sizes.

I typically use em or % these days to define text sizes in CSS. So in my situation, I’ve found that my letter-spacing: 0.05em works if I also specify font-size: 125% (or larger), but if I have font-size set to 100% or less, the letter-spacing gets ignored.

Typically, after loading reset.css, I set a baseline font size for the document with body { font-size: 100%; } (or some size… actually it’s usually 80% but these days I’ve been leaning towards larger type).

I decided to play around with this a bit to see if I could resolve the letter-spacing issue, and I found a nice, easy solution that works at least for the particular site I’m currently testing it on. Your experience may vary, depending on how your HTML is structured and how complex your design is.

Here’s the solution:

body {
  font-size: 125%;
  letter-spacing: 0.05em;
  line-height: 1.3em;

body>* {
  font-size: 85%;
  line-height: 1.3em;

You may want to adjust the exact values of font-size to suit your needs. (And, yes, I’m aware that mathematically 125% and 85% don’t cancel each other out, but they’re close enough for my purposes.) It’s important to include the line-height property in body>* to define your target line height; otherwise your lines will be too far apart. Set it to whatever your ideal value is. (I usually prefer line-height: 1.5em personally, but for larger type, as on the site I’m currently working on, it gets too spaced-out.)

So what’s going on here? Well, strangely, it seems WebKit can actually render smaller type with line-spacing less than 1px or 0.1em just fine, but it won’t unless somewhere in the “cascade” the type has been defined as being a certain amount larger than 100%. I don’t get it, but until the bug (which it seems clearly to be after all of this) gets fixed, at least this seems to be a reasonably clean workaround.

It’s very important that you use body>* and not just body *. If you don’t know why, well… try it out and see. (The upshot: we’re applying a uniform scaling-down across the board on all elements directly under body, which is practically the same as just defining our target font size directly on body itself, but with the benefit of working around the letter-spacing bug.)

Note: I have only tested this using em as the unit of measure for letter-spacing. I’m aware of the issue with px as well, but I’m not sure this solution will work for that. But… really… just use em instead!

Why does Safari 4 Beta take SOOOOO LOOOONG to start up? Am I the only one having this problem?

Hurry up and wait!I downloaded and began using the new Safari 4 Beta the day Apple released it. I’ve complained (mostly on Twitter) about various aspects of it, things that I’ve now (more or less) gotten used to: most significantly the still-awkward title bar tabs.

But one thing I haven’t gotten used to is the ridiculous amount of time Safari 4 Beta takes to get up and running, at least for me. The window appears promptly after clicking on the icon, but then I’m visited by the dreaded spinning beach ball of death. This situation endures for at least a minute or two (if anything, I am exaggerating that time down), and then things proceed as normal.

At first I thought maybe it was something peculiar about my own site (even though it loads just fine in other browsers, including Safari 3), which I have set to load as the home page. But I just waited out Safari’s ridiculous start-up time, then went into the preferences and set it to load with a blank page. And it still took just as long, not even loading anything from the Internet. So clearly it’s just something in the internal workings of the app itself.

I have not seen anything anywhere about this issue. Everyone seems to love Safari to death, and says nothing about its speed other than how blazing fast it is. I guess it’s pretty snappy once it gets going, but for me all I can think about is this ridiculous load time at the beginning.

And so, this humble blog post shall serve as a beacon in the darkness, calling out to all those who suffer as I do (oh, such suffering) from an inexcusable lag at the start-up of Safari 4 Beta.

For what it’s worth, I’m running a stock black MacBook purchased just last August (right before Apple retired them, of course), 2 GB of RAM, Mac OS X 10.5.6. In other words, this should not be happening.

Also, for what it’s worth, once Safari has gotten going, my site loads very fast… less than a second on my cable connection. So it’s definitely not something with my site (thankfully, since I can’t imagine what it would have been).

SimCity for iPhone: ASOD (Advisor Screen of Death)

I was ecstatic when I discovered SimCity for iPhone. It is, without a doubt, the best “deep” game for the iPhone that I’ve encountered. (Stuff like Bejeweled is great too, but they’re in a completely different league.)

I have long been a fan of the SimCity series. I haven’t really played SimCity 4 much, mainly because it seems that with each new version, Maxis EA gives the Mac version less and less attention. Or, more accurately, they give MacKiev even less time and a stingier budget to do the port from the PC version. So, it’s bloated and sluggish and slow. But for me, SimCity 3000 was great, and that is the edition that was the basis for the iPhone version.

I love it. It is unbelievable that they could pull off something like this on the iPhone, but they did it. Mostly. It’s great, but it’s buggy.

The worst bug I’ve encountered, twice now, happens occasionally when clicking one of the advisor links in the news ticker at the bottom of the screen. What you get is… ugh… this:

Sim City Advisor Screen of Death (ASOD)

In the spirit of the classic Windows 95 BSOD, I’m calling this bug the ASOD: Advisor Screen of Death. I have no experience with iPhone programming, but I suspect that the text you see is the variable names or some kind of parsed placeholder text where the actual advisor message is supposed to appear. Unfortunately, not only is the text not being properly loaded, the actions for the buttons aren’t, either, meaning that once this appears, there’s no way to make it go away… at least, no way other than clicking the iPhone’s Home button, which does a fine job of returning you to the home screen… but it quits SimCity in the process, and if you hadn’t saved in, say, the entire amount of time you had just been playing the game, it can be incredibly frustrating.

So… if you like SimCity and you own an iPhone or iPod Touch, by all means, buy this game. You will enjoy it immensely. Just remember two things:

1. Save. Often.
2. Think twice. Skip advice. (Or at least approach your advisors through the “…” menu instead of the ticker.)

Update: A few other bugs, or at least flaws, I’ve noticed: the city’s population seems to fluctuate wildly from month to month, with no logical explanation; demand for the different zones seems to bear no relation whatsoever to the tax rates for those zones, but almost seems to just follow an arbitrary pattern of ebb and flow; and the budget numbers do not adjust month-to-month, making it really hard to track current revenue levels. Maybe this last one is the same in the computer version too, but the budget seems to require a lot more close attention on the iPhone.

A few thoughts on this whole Zune fiasco

In case you didn’t know (and why would you, since I’m sure you don’t own a Zune), there was a big problem on New Year’s Eve for 30 GB Zune owners (dubbed Z2K9), all of which apparently suffered a simultaneous failure on that day.

Apparently, a bug in a driver for that model caused it to choke on the 366th day of the year. In other words, the 30 GB Zune cannot comprehend the concept of a “leap year.”

According to Gizmodo, Microsoft’s official “fix” was simply to wait it out until January 1, 2009. Nice one. But this begs the question, glaringly omitted from the FAQ on Gizmodo, of what will happen to these Zunes on December 31, 2012, since there’s no mention of Microsoft actually attempting to eliminate the bug from the software. I have to assume Microsoft just expects all of these Zunes to have arrived at their eternal home in a landfill by then.

Another question omitted from the page: Who actually owns a Zune anyway?

Zune Tattoo

Oh… um… that is… what I meant to say was… uh… the Zune is… a… uh… a wonderful device and… um… I’m sure lots of people own them. (Can I go now?)