Jokel Embed Development

Two months later, I’m finally writing the blog post I promised in my original blog post showing off Jokel embeds Part of the reason it took me so long to write this post was that it was so remarkably easy to do that I had a hard time outlining a substantial post. Even if the actual development was simple, figuring out the implementation details took us about 30 minutes and there were a few gotchas that popped up after, so those are outlined below as well.

The idea, as many of our inspirations for Jokels, came from Github: we really like to use Github’s “Gist” snippets on our blog. It’s really slick how easy it is to embed code samples with syntax highlighting, update the snippets without touching the post and to comment on or even fork code snippets. So we thought it’d be fantastic if we could offer the ability to embed Jokels. It would be a slick way to embed a joke in a blog post or your website, drive traffic to the site and as people add alternate punchlines those could show up as well, so we would get some of the cool dynamic update elements of Github’s embeds.

So, continuing our history of liberally stealing from Github, we looked at Github’s embed tag, and then inspected the Javascript file that it was referencing. It turned out to be remarkably simple. It used document.write to embed link tags to stylesheet and javascript files it needed, then wrote an escaped HTML / javascript snippet containing all of the Gist in a single line. It seemed clear that Github was probably just using <%= escape_javascript %>, so it was relatively simple to do the same:

The only tweaks we had to do were to change the existing Joke partial to accept a new “min” parameter which turned off everything except for the simple joke functions (no sharing, voting, new random joke, etc) and to move the necessary CSS and Javascript out into independent files so that we weren’t sending irrelevant code in our embeds – we want our embeds to function as quickly as possible so people will use them!

Of course, no commit is ever perfect (at least none of mine ever are) and a couple of issues popped up along the way, some of which surprised me, others of which I just forgot about during the process:

  • Style for the page in which the embed was being placed would break our layout, if we didn’t have fine-grained CSS selectors for the given elements. The example we found was that a page had a margin specified for all spans, but we wanted out spans to have a 0 margin, which was applied at a general class level, so the more specific selector one out. We tried to combat this with more specific selectors for important layout attributes, as well as “!important” flags for attributes.
  • We use mobile-fu on all our requests to catch incoming mobile devices and route them to our mobile site – but with embeds we clearly didn’t want this to happen: we have no control over whether the embed site is a mobile version or not, so we should always just display the normal version – so we had to add exclude clauses for these request handlers. It was an easy fix, but it caused several airbrake errors when someone tried to view our blog on a mobile device.

All-in-all, adding embeds was a remarkably easy thing to do in Ruby on Rails by leveraging the power of existing code and partials. It’s a great example of a low-cost but high-value and high-visibility feature that most sites could use. Just to show it off one more time, and to give my favorite joke some love, here’s an embed to send you on your way:



Leave a Reply

Your email address will not be published.