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);
}
add_filter('the_content','embed_fix_stray_parens');

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).