I’ve noticed this trend to screenshot tweets instead of copy-pasting their texts in blockquotes for some time now. On web design and technology blogs, no less. You’d think these sites who constantly write articles about HTML, CSS, web standards, usability, semantics would actually listen to their own advice.
What do people get out of doing it, though? Is Twitter really that much of a game-changer that you can now break the conventions of quoting people in articles on websites? Is it really that big of a deal to debate on how you should add tweets to articles—which is so obviously linkbait?
Are tweet pages designed so much prettier than your default blockquote designs that you feel compelled to use them instead (that’s definitely an “unsuccessful designer trend” isn’t it)? Though, consider the construction: large text, a clear indication of who said the tweet, and a fuzzy timestamp. Maybe that’s what blockquotes should aspire to be?
Are tweets such special data forms that you need specialized plugins and scripts like WP Quote, Twickie, QuoteURL to display them? Or do those exist to up one’s geek cred and feed the third-party Twitter apps machine?
Still, those aren’t as bad as web apps like tweetshots. Want to share a tweet on Tumblr? Use the Quote post type. WordPress is getting custom post types in its next major release too. But publishing platform or no publishing platform, that’s what the HTML tag <blockquote> is for.
Let me channel Steve Ballmer and say: Blockquotes, blockquotes, blockquotes, blockquotes, blockquotes. They’re not that hard to use, certainly not more than taking a screenshot and uploading it.
I understand why on some occasions using images instead of text and other data formats is preferred. They’re usually more portable when passed around in email, forums, social networks, and other communication platforms. More people know how to deal with images than URLs too. But for the purpose of quoting tweeple on websites, I see no excuse for displaying text as images.
I’ll spell it out for you in <strong> and <em>: display text as text, not as images, damn it!
Sure, screencapping tweets may not be as grave a sin as using tables for layouts, but back when that was the dominant method of creating websites, it was a pragmatic choice to make do with the technology available. The choice to use images for text is illogical today. It is confusing behavior that is inexplicably linked to Twitter’s success.
Blackbird Pie is Twitter’s very own tool for embedding tweets on webpages without the cumbersome, semantics-killing screenshot method. It still lacks the dead-simple interface Twitter is notorious for, since you have to enter the URL of the tweet to grab the embed code and it’s not even built into the system yet, but that’s because it’s a rough prototype at this point.
Since Twitter is an ecosystem of early adopters, it didn’t take long before a bookmarklet surfaced, which sports only a minor difference with the original code in the date format, and seems to display better on this site.
Note that this method inherits your websites styles, which means you may or may not have to tweak your CSS to accommodate it. Unfortunately it still looks bad in feed readers.
Has progress been achieved here?
I’m not sure this is any better than a screenshot. Putting aside the long-winded user flow of grabbing the code since that can be remedied once it’s built into the Twitter system, there’s an overflowing amount of inline CSS to copy and paste. The advantage to this static code, however, instead of a JavaScript embed is that the text is preserved even when the tweet is deleted.
The question remains: should people go through all this trouble to use tweets as quotes? Is there really that much more to be gained by preserving the tweet “format” over a simple blockquote? I still don’t think so.
Harry Roberts a.k.a. CSS Wizardry tweeted a certain tutorial by CSS Aid (page is dead now), which was enclosed with four little words (“Good lord, wrong much?”) that echoed such alarming levels of horror and shock (considering he tweets about poor examples of HTML/CSS code everyday), that I had to check it out.
First, the tutorial was entitled “Tables Without Tables”. If that doesn’t trigger warning bells in your head, then consider the opening paragraph:
It’s the year 2009, CSS rendering has vastly improved from when it was released, so there is no reason for any website to use tables as layouts. Although you can ditch the table tag when it comes to layouts, you may someday need to use it for what it was made for…or do you? I am going to show you an easy way to make a table with a simple unordered list.
No. Just no. Yes, <table>-based layouts are considered wrong because HTML is supposed to properly represent data. Lists should be lists. Tables should be tables. Layouts that look like tables (grids) can be done in CSS. That’s semantics, the core principle of web standards.
But avoiding the use of <table>s at all costs is no better. Perhaps it’s even worse, since it demonstrates not only ignorance but false expertise, feigning arrogance over an HTML element that has been shuddered at because of its misuse and abuse.
The page has gone down in between the time that I read the tweet and wrote this post. Fortunately the forum thread that seems to be the source of the link is still up, and shows us the author’s reasoning for writing the tutorial. Take post #7:
Because I hate the <table> tag
Is this the extreme dark side of web standards, where we’ve been conditioned to hate <table>s so much that we can’t even think to use them for what they were meant for anymore? A sad, sad turn for us all.
By post #15 he’s already backed down and promises not to use the experiment for real-life cases, but this summarizes things nicely:
It’s a pointless experiment though. It’d be like experimenting making a house out of tampons. Doable but just plain wrong.
It’s bad enough that we have to deal with preaching proper web standards, dropping crusty old browsers from, and adding newfangled technologies to our web design arsenal. Let’s not get sidetracked by punishing HTML elements by twising them into things they weren’t meant to be.
It’s April 9th somewhere around the world and that means it’s time for the annual CSS Naked Day. Just how elegant and semantic is your website’s markup? Stripping out your stylesheets will determine that. Good houses must have good foundations, and so must good sites.
The idea behind this event is to promote Web Standards. Plain and simple. This includes proper use of (x)html, semantic markup, a good hierarchy structure, and of course, a good ‘ol play on words. It’s time to show off your <body>.
As an aside, I like that this ‘Day’ is arbitrarily stretched out to 48 hours instead of the usual 24 to accommodate locations all over the globe. I think more worldwide events and holidays should be more timezone-neutral.
We need more standards-focused advocacies like Blue Beanie Day, the countless kill IE6 websites, and this.
*/
