Good embedded tweets

This morning I made a little funny on Twitter:

Another thing that’s so 2006: Using screenshots instead of live embedded tweets. buzzfeed.com/mjs538/tweets-…
  — Dr. Drang (@drdrang) Thu Jul 12 2012 9:11 AM CDT

The linked article at BuzzFeed, 30 Tweets That Are So 2006, is a hipper-than-thou post—broken into two parts, the better to serve you ads, my dearie—showing tweets about topics/websites/people that are now outoutout.

What I thought was worth poking fun at was the way BuzzFeed showed the tweets: as screenshots taken from the Twitter website, with no links to the actual tweets or the users who wrote them.

Some people took issue with my tweet, and gave reasons for using screenshots instead of “live” embeds with working links. There was this one, suspicious of Twitter’s commitment to data longevity:

@drdrang given Twitter’s skill at accessing old data, aren’t screenshots less likely to break in the future? Let alone if it’s deleted?
  — Rob Mathers (@skiingRob) Thu Jul 12 2012 9:14 AM CDT

And this one, suspicious of Twitter’s commitment to privacy:

@drdrang I prefer screenshots so as not to give Twitter cookie/analytics extra visibility. I don’t want to cookie my readers unnecessarily.
  — Drew Breunig (@dbreunig) Thu Jul 12 2012 9:16 AM CDT

Both of these are legitimate concerns if the only kind of “live embedded tweets” you know about are the ones supplied by Twitter itself. But that wasn’t what I was talking about.

The embedded tweets I post here use my own code, a variant on Jeff Miller’s blackbirdpy script. The content of the tweet is grabbed from Twitter through a Python script when I write the post and is put directly into the post’s source file. Even if Twitter goes the way Digg, that content will still be in my post. The only “content” that’s gathered dynamically via JavaScript/JQuery when you load this page is metadata: the user’s avatar, background image and color, and link color.1

And of course I don’t add any tracking code or cookie manipulation. If you don’t believe me you can read the source code yourself.

One reader had very specific ideas about how a tweet should be embedded:

@drdrang @viticci I think both are bad. A blockquote with the tweet text + custom CSS is accessible, future-proof and preserves privacy.
  — Ole Begemann (@olebegemann) Thu Jul 12 2012 10:17 AM CDT

Take a look at the source code, Ole—that’s exactly how I do it.

html:
<div class="bbpBox" id="t223436034602582016">
<blockquote>
<span class="twContent">
<a href="http://twitter.com/drdrang">@drdrang</a> 
<a href="http://twitter.com/viticci">@viticci</a> I think both are bad. A blockquote with the tweet text + custom CSS is accessible, future-proof and preserves privacy.
</span>
<span class="twMeta"><br />
<span class="twDecoration">&nbsp;&nbsp;&mdash; </span>
<span class="twRealName">Ole Begemann</span>
<span class="twDecoration"> (</span>
  <a href="http://twitter.com/olebegemann">
  <span class="twScreenName">@olebegemann</span>
  </a>
  <span class="twDecoration">) </span>
  <a href="https://twitter.com/olebegemann/status/223436034602582016">
  <span class="twTimeStamp">Thu Jul 12 2012 10:17 AM CDT</span>
  </a>
  <span class="twDecoration"></span>
</span>
</blockquote>
</div>

And I’ve been doing it that way since 2010.

What happens if a tweet gets deleted after I embed it? Let’s see. Here’s a tweet I posted this evening from an account I’ve used to test the spam reporting code in Dr. Twoot:

A tweet that’ll get deleted soon.
  — Drang Spam Tester (@drangspam) Thu Jul 12 2012 9:06 PM CDT

I deleted the tweet shortly after embedding it, but all the important information about it is still here. You can tell that it’s been deleted by clicking on the timestamp. Instead of seeing the tweet on Twitter’s site, you see this error page:

Twitter error page

I’ve written about blackbirdpy several times as I’ve made changes to it. The most recent post was just a few days ago. If you’re interested in embedding tweets this way, download the code from the repository and look through my posts to see how to use it.


  1. Until today, I had the user’s name and screen name collected dynamically, too. This was both redundant and lazy, and I’ve fixed it.