Social Media Club Buffalo: #TacoVinoII

Last night the local Social Media Club chapter here in Buffalo repeated last year's mid-holiday party success by putting on TacoVinoII. Similar to last year, the club teamed up with a local wine bar, Just Vino, and a local food truck, Lloyd Taco Truck.

Lloyd Taco Truck made a batch of its popular duck tacos for the crowd and Just Vino ran raffles all night for $25 gift cards to the bar. Attendees not only got to enjoy wine and duck tacos (along with other Lloyd staples), but they had the pleasure of pairing the two while chatting in real life with the very people they might only chat with online.

An event which started off with only 50 free tickets quickly filled up, and the ticket count got bumped up twice more to 150 people. Throughout the night it was pretty clear they all came through. The cold night certainly didn't stop anyone from waiting in line for tacos, either.

Buffalo.com sent a photographer to capture the evening and posted a gallery of 60 photos this morning for you to look through. My favorite photo in the bunch, of course, is the only one I am in — featuring my finger puns pew-pewing the Buffalo chapter president (#26 in the set).

If you are afraid you missed out on all the fun, you can verify that you did just by checking out the #TacoVinoII hashtag on Twitter.

Credit for this year's event goes to Erin Collins for organizing it and pulling it together, Nicole Schuman, Rachel Gottlieb and Jeremy Juhasz for manning the registration table and generally pimping the club, Kate Wolcott for the updated logo and signage, Ashlei Jachimowicz for on-site tweeting responsibilities, and Anthony Rizzo, who worked the crowd to sell raffle tickets.

Somewhat related —no Foursquare venue was created for TacoVino II, primarily because both Just Vino and Lloyd Taco Truck have their own venues on Foursquare. However, when you have a crowd of social media professionals and hobbyists, it's just a matter of time before one of them creates the venue for you. In this case the "matter of time" was about half an hour.

Previous Events

• Social Media Club Buffalo: #TacoVino, December 30, 2010.


• Twitter best practices panel, October 28, 2011.


• Social Media Day 2011 in Buffalo #smdayBUF, July 1, 2011.


• Buffalo Launches Social Media Club Chapter, September 23, 2010.


• Event Profile: #smdayBUF & #smdayBUF 2.0, August 12, 2010 (posted at City Love Cloting).


• Social Media Day in Buffalo #smdayBUF, July 1, 2010.

Read More

Don't Expect Microsoft's Auto-Update to Kill IE6

Last week Microsoft announced that it is planning to start upgrading users to the latest version of Internet Explorer that their computers can run (IE to Start Automatic Upgrades across Windows XP, Windows Vista, and Windows 7). Web developers for the most part were overjoyed with the notion that IE6, the bane of their existence, might finally be brushed aside.

But that's not what's going to happen.

Corporate

IE6 users in a corporate environment generally don't have a say in the browser they use. Typically if they have not been upgraded to a more recent version of Internet Explorer, it's for a reason. This reason can include anything from a customized version of the browser (yes, those exist) to an intranet/extranet application that was built to lean on the features of IE6 itself. When faced with the option of re-writing an entire application or just holding off on an upgrade, imagine which one is likely to win out (especially when weighed between the effort of the full rebuild or the effort of doing nothing). Back in March, ReadWriteWeb ran a poll with results showing that 29% of corporate users are still on IE6 with "no end in sight."

Microsoft makes Internet Explorer 8 and Internet Explorer 9 Automatic Update Blocker toolkits (for IE8 and for IE9) which allow enterprise environments to skip automatic installation recent upgrades. Since IE6 and IE7 aren't given their own opt-out toolkits and the process is still in the planning stages, it's hard to say how those two older versions will be addressed. It is likely, however, that corporate IT departments will err on the side of caution. It's already common practice for enterprises to decline to install updates and service packs because it may affect existing systems. These systems aren't necessarily built in-house, but are from vendors who themselves have not made any efforts to modify them in the years since IE7 came out (or have simply gone out of business). When an organization will not install Windows XP Service Pack 2 (late 2004), it is unlikely it is going to allow a browser upgrade.

Non-Corporate

There are other cases besides corporate environments where you may want to opt out — some assistive technology must be upgraded if the browser is upgraded. For example, upgrading to IE9 requires an upgrade to JAWS, Window-Eyes, Dragon Naturally Speaking and possibly other applications (Remarks on Internet Explorer 9 Accessibility and Compatibility with Assistive Technology). While this doesn't address IE6 specifically, each upgrade of IE has typically required other software updates for anything that relies on IE. These collateral effects sometimes make it cost prohibitive for an organization to upgrade even a free browser.

Microsoft's plan will affect users on Windows XP, Windows Vista, and Windows 7. Windows Vista and Windows 7 users aren't running IE6, so they're not going to contribute to any more IE6 market share drop. Some non-corporate users of Internet Explorer 6 are on genuinely old computers and aren't regularly updating their systems as it is. You may not see much of a drop there, if any. Couple this with the fact that Microsoft is not releasing recent versions of Internet Explorer for Windows XP, and those users will continue to languish on a permanently old browser, even if not IE6.

Asia

Microsoft's plan is also unlikely to address the Asian market, where China still sees IE6 running at a 28% installation base (versus 1.8% for Australia and 1.4% for Brazil, where Microsoft is rolling this plan out first). So many of those computers are running unlicensed copies of Windows XP, or are just older computers, that it is unlikely anyone will opt in for the automatic upgrades. While this may not affect most Western companies who don't do business in Asia, it is certainly inflating the numbers for IE6's installation base, and making international dreams for some companies seem a bit more daunting.

Conclusions

I feel like all I do is kill everyone's buzz whenever the coming demise of IE6 is promised. However, I've been killing that buzz for a decade now, so the odds are in my favor.

Microsoft's plan is a good one, and is no more than jumping on the bandwagon pulled by nearly all the other current browser makers. However, because Microsoft has a special place in the enterprise world and with its operating system dominance, I don't see this plan doing much to hasten the demise of IE6.

Related

• Internet Explorer to auto-update at .net Magazine.


• Web Developers Rejoice! Microsoft is Killing IE 6 and 7. at Reddit.


• Microsoft decides to automatically update Internet Explorer for everyone | Hacker News

Not really related, but this handy diagram shows where IE6 fits into the current world of the web:

Read More

Test in Lynx and Print, It's Your Job

I have admittedly not taken the time to attend An Event Apart any of the times it's been held, but I do tend to follow the #aea hashtag on Twitter so I can glean at least a little wisdom from the discomfort of my own desk as I wade through more mundane tasks.

That means I sometimes see tweets like the one below which, taken out of context, get my blood boiling:

I try hard not to Tweet in anger, but sometimes they slip out:

I had just this morning been taking time to review my own site in Lynx after a minor update, as I do after every update, just to make sure my alt text, page structure, content, navigation, etc. were all working the way they should. Lynx is part of my regular testing suite. It also helps remind me that reliance on JavaScript for things that can be handled on the server or with CSS isn't such a good idea.

I can't imagine a testing process that doesn't include Lynx. Lynx is the truly lowest common denominator on the web. It gives you insight into how a page is structured, how assistive technology will approach it, and even how search engines will perceive it.

In addition to testing in Lynx, I always look at how a page prints. I create a PDF from a handful of browsers for every project, targeting the home page, content pages, and some outliers (odd templates, gallery chaos, JavaScript flim-flam, and so on). I think that should be expected of all web developers, though clearly it is not. This particular issue has frustrated me more than once, as I outline in my posts Print Styles Forgotten by Responsive Web Developers and More Samples of Responsive Web Design ≠ Print.

Add together my beliefs about Lynx support and print styles, and I cannot accept that anyone would consider this to be something more than the most basic standard practice. Do we get excited when our pages validate? When we choose the right element? Do we celebrate when Twitter pushes out one of our tweets? When Google Analytics produces a chart? When my email gets to its destination? No, because these are basics we should expect.

Let's stop setting the bar so low and expect more of ourselves as developers. Until we do that we aren't professionals, we're hobbyists. Ego-driven hobbyists.

By the way, in addition to that screen shot of my site in Lynx (starting this post), here's my site when printed:

Read More

Everything Will Be the New IE6

There seems to be no shortage of people making a comparison to Internet Explorer version 6, or IE6, as the simplest way to declare that something is an impediment to progress. Sometimes the criticism is levied with the understanding that at one point IE6 was the bees knees (In praise of Internet Explorer 6), but more and more people forget that and just treat it, and by extension the subject of the comparison, with derision.

Here are some examples with the comparison right in the title, blithely link-baiting the unsuspecting reader:

• Is Google Chrome the New IE6?, December 2, 2011.


• JVM 5 is the new IE 6, October 31, 2011.


• Browser Market Pollution: IE[x] is the new IE6, September 27th, 2011.


• iPad Is the New IE6, January 31, 2011.


• IE 8 is the new IE 6, October 11, 2010.


• The iPhone is the new Internet Explorer 6, says mobile developer, February 8, 2010.

I'm not challenging the validity of these articles, some of them make some very good points and the comparison is apt. Having listened to non-tech people (the ones who use "HTML5" in conversation the way they used "DHTML") start to make these comparisons without any historic context, I think it's about time we as web developers came up with a new metaphor to flog. I kinda wish it was Netscape Navigator 2.

Remember Netscape Navigator 2, which brought us all sorts of innovations such as frames, cookie management, and JavaScript (nee LiveScript)?

People don't use Netscape Navigator 2 as an insult/comparison the same way because that browser didn't last more than 10 years in the wild (despite my best efforts), not to mention far too many people have never even heard of it now. IE6, on the other hand, has persisted thanks to too many developers targeting the browser instead of the standard, making corporate IT departments reluctant to move users to the next release. Let's not count the tie to the operating system and the inherent fear of upgrading from some sub-set of users.

Whatever your gripe with a technology, I think it's about time we only made the IE6 comparison when it is appropriate, not as a catch-all to something we don't like or that we think is making our job harder.

So let's start comparing things to Netscape Navigator 2 (Netscape 2, Navigator 2, NN2, NS2 and whatever other variants you want). Let's free IE6 from this burden and perhaps it will slip away into the night.

Somewhat Related on this Blog

• Microsoft Promoting the Death of IE6


• Enough about the Death of the Web

Read More

Flash is Dead! Long Live Flash!

Re-posted from its original home on the Algonquin Studios blog.

A lot of news has been made of Adobe’s recent move to end development of the Flash player for mobile devices (such as your smartphone or tablet). Even people outside of the tech community have heard about it and are trying to understand what it really means. I wrote up the details last month (Flash Isn’t Going Away, Except from Your Mobile) and tried to remind everyone that Adobe isn’t giving up on Flash, it’s just changing its direction on its mobile player based on industry trends.

Consider that Apple won’t allow the Flash player on its iOS devices, and that the mobile version of Windows is following suit. Consider that web developers are (finally, after a decade now) starting to focus on standards-based web development and accessibility. Consider how many different mobile devices and browser combinations exist, requiring Adobe to develop a Flash player for each.

Much of Flash on the web has been used to deliver rich multimedia experiences that either don’t translate well to mobile browsers (giant file sizes, areas too small to “click” with a finger, optimized for large displays, etc.) or can be replaced with new HTML capabilities which mobile browsers tend to support now without the Flash player (such as the lowly Flash video player).

Add all these factors together and it doesn’t make sense to push the Flash player to mobile devices any more. Adobe is instead using AIR to allow Flash developers to build native apps on the phone, bypassing the hassle of the browser plug-in altogether and still allowing those legions of Flash developers to do what they do best.

Here’s where people get confused — Flash as a platform isn’t going away. Regardless of the hype you hear about HTML5, HTML5 (including CSS3, SVG, and so on) just doesn’t have the capability (whether via the specification or by browser support) to do what Flash does. Flash is the only technology that can currently do what Flash does for such a broad audience. Its ubiquity across the web (98% installation) has guaranteed that users see what the developer wants, regardless of platform; regardless of whether or not what the developer created is any good.

This doesn’t mean we are Flash-crazy over here. Quite the opposite — we have historically counseled against Flash for web sites for many reasons, some of which are simply because it doesn’t address the goal. As we develop sites that are both mobile-friendly and desktop-friendly, we are increasingly coaching our clients on the right technologies to use to achieve their goals. Our position on Flash isn’t changing because of Adobe’s move, Adobe is simply reflecting the trend.

You can expect to see less Flash in web pages on your mobile, but you can also expect to see more of it behind the scenes in apps for mobile devices. As for your desktop browser, Adobe will release Flash players for years to come and people will still develop in it for as long as it takes HTML5 and its related specifications to finalize the rules and for the browsers to support them.

Read More

Thanksgiving, Social Media and Tech Support

Does this Foursquare map of holiday travel look like a turkey to anyone but me?

Three years ago I hosted Thanksgiving at my house, tweeting photos of the bird and small brush fire. Two years ago I wrote a post Enjoying Thanksgiving with Social Media and then wrapped my car around a lamppost instead of enjoying it. Last year I ran with the topic again and wrote Thanksgiving and Social Media, Redux, had a lovely meal without crashing, and mourned the coming doom of my favorite photo sharing site.

This year people are trying to make it different, and I don't know that I like all of the suggestions.

My not-so-local grocery store is using social media to help people who might be in a bind, offering to help folks who tweet it with the #Turkey911 hashtag, something that is happening across the country. Having quick access to someone who can help you is far better than calling the real 911, and is something that we just couldn't do very easily a few years ago. At least not without calling the one family member that maybe you don't want to tell that you are struggling.

Wait, what's that typeface? You want to be taken seriously?

Much as I'd like to talk about the typeface used in the photo I lovingly stole from the Atlantic article, Forget Shopping, Friday Is Update Your Parents' Browser Day!, I'm not going to. Instead I am going to marvel in awe at the suggestion that younglings sneak off to their parents' computers (insert grandparents, aunts and uncles, elder host, etc.) and fiddle with them. The article at least counsels the intended saviors (but instead unwitting harbingers of doom) not to move their parents to a new browser, but to at least try to keep them using what they are used to. There are two key problems with this:

1. The browser will work differently, whether within the UI or just from how pages look;


2. Some machines just can't be upgraded without slowing them or upgrading them;


3. Most IE6 offenders (who I suspect the article is truly targeting) are corporate users who can't change it (and aren't hosting you in their office).

Those first two will result in needless frustration on the part of your parents (elders) and deserved tech support hassle for you.

Gizmodo took this creepy photo from True American Dog.

For much of my family they only know that I "work with computers." While it is somewhat accurate (although nearly everyone works with computers nowadays), to them it means I can fix them along with any other electronic device ever invented. Since I tend not to wear my "No, I will not fix your computer" T-shirt to more formal events, I am often assaulted with the kind of help desk questions that make 11-year-olds cringe.

Gizmodo feels my pain and is trying to help with its article How to Keep Thanksgiving From Being a Family Tech Trainwreck. Though the article attempts to keep your hassle to a minimum, it also recommends you upgrade, nay, crossgrade your parents to a whole new browser. Don't be a twit, you'll get calls forever. Otherwise the article offers good advice — answer their questions for them, not for you. Pushing your parents to some new bleeding edge tech is just more hassle for you in the long run. Pay attention to what tech they complain about (is the TV remote to complicated? do they struggle with the computer set-up at their job?) and steer clear of creating an analogous situation.

If you really want to help, make notes of everything you do and pass them down to your children. Then when you are struggling with new technologies in your old age, you can justify your smugness at how new technology has it all wrong and your children can justify their pity for you.

MOAR!

Now go relax. Read The Oatmeal's comic on Thanksgiving as a Kid vs. as an Adult. Prepare for where you'll site using College Humor's Thanksgiving Seating Chart. Take this Map of Thanksgiving Dinner to plan your assault on Crudités Dam. Go over to the Opera site (the folks who make the browser, not the faster-than-light neutrino source) and weigh in on whether or not the lucky bird should live. In short, disregard your family and stare at your computer/phone all day, just like the moody teen we all truly are.

Read More

Perplexing Prefixes

Mostly I wanted a title with a little alliteration (like that sentence). What I am talking about in the title are vendor prefixes for CSS, those little bits of words and dashes that appear in front of what would otherwise be a W3C CSS declaration, but denotes that this one is actually an experimental or beta implementation of the specification by that particular browser.

Continuing with the recent trend of smart people in the know openly and publicly debating issues that do and will continue to affect web developers, Henri Sivonen wrote an article earlier this week with his main point right in the title: Vendor Prefixes Are Hurting the Web. For those of you who are curious but don't want to wade through his entire post, he has a tl;dr version:

I think vendor prefixes are hurting the Web. They are hurting Web authors. They are hurting users of browsers. They are hurting competition in the Web browser space. I think we (people developing browsers and Web standards) should stop hurting the Web. It would also make sense for browsers to implement other browsers' prefixed features to the extent existing content uses prefixed features.

He is kind enough in his post to include some counter arguments and preemptively respond to them, including linking to other counter arguments that are direct responses to him. Alex Russell provides his own tl;dr version in his response, Vendor Prefixes Are A Rousing Success:

Henri Sivonen's arguments against vendor prefixing for CSS properties focus on harm without considering value, which in turn has caused him to come to a non-sensical set of conclusions and recommendations. Progress is a process, and vendor prefixes have been critical in accelerating that process for CSS.

Daniel Glazman provides a point-by-point counter argument in his post CSS vendor prefixes, an answer to Henri Sivonen. He doesn't provide a tl;dr version, so I am using this quote in place of one:

The ineffable Henri Sivonen has contributed a long, a very long, a probably too long post about CSS Vendor Prefixes. In short, he thinks they are harmful and should be dropped. I tend to totally disagree and will explain why below.

My opinion

Nobody has asked for it, but you did choose to come here and read this far, so I guess you deserve it.

I think that prefixes have their place, and codifying their non-standard behavior (as in, there is no standard in place to describe how the feature should work) with a prefix makes for a very readable, consistent method to identify this non-standard chunk of code along with what rendering engine relies on it. Ideally it also makes for a consistent way to run a regex or search and replace to adjust or clear them in the future.

Web developers who implement these pre-standard features run the risk of creating a hassle for future maintenance and need to consider if they are just being bleeding edge or solving a real need. When working with clients or on projects where once it launches it is unlikely to see regular updates, it's unlikely that someone will come through and clean these up until there is an overhaul. When you see these all over a site, it's not the vendor prefix hurting the web, it's the sloppy or short-sighted developer who is relying too much on them and not building a process to excise them down the road when the time is right.

Companies who build vendor prefixes into their CSS/DOM editing tools are doing a disservice to developers. Promoting support for every browser while offering the most cutting edge features ends up putting developers who rely in these editors in a tough situation. Without exposing them to the code or providing an easy way to manage these non-standard features, more of this bloat makes it into the page. The proliferation of abstraction layers compounds the chaos. Removing the developer from the code and failure to educate the developer on the implications of his or her choices is the issue in this case, not the vendor prefixes.

I do agree with the assertion that sample and demo code across the web (such as tutorials) that shows off new CSS features does not get updated, so developers may use it in all its vendor-prefix glory well after a feature has been standardized. These samples need to do a better job of managing the reader's expectation that the standards may have changed and the code may be out of date. It's still up to the developer, however, to choose good and recent examples that are appropriate to the need. Not understanding the code being copied is not an excuse, it should be a clue that the developer needs to spend a few minutes reading.

Removing vendor prefixes can stymie the real-world use case testing of feature implementation that is hard to come by when looked at from a purely academic view. Suggesting browsers support one another's prefixes means if one vendor changes the feature, all the others would have to follow suit, regardless of the existing (or lack of) specification.

I do like the idea of vendor prefixes only in the experimental builds of browsers, but then developers may be disappointed that their favorite new bleeding edge feature won't work for regular Joe users.

This isn't a simple issue, but getting developers to be more responsible and judicious in their use of these new properties would certainly help.

Related

Peter-Paul Koch broached this very topic way back in March 2010 with the post CSS vendor prefixes considered harmful and his follow-up (based on reader reaction) CSS vendor prefixes redux.

While I instruct my team to avoid vendor prefixes, I have warmed to them for experimental projects or sites with a greater likelihood of ongoing updates (where the client expectation has been managed). In my post The evolt.org Logo Using Only CSS2 and CSS3 I make extensive use of vendor prefixes, just to show it's possible. The opening image of this post is pulled from a JSFiddle I made of a CSS3 cube to submit to Chris Coyier's CSS shapes article (although it isn't in there — yet).

Read More

Struggling with Semantics

Now that HTML5 is starting to crack the mainstream, misunderstood and misrepresented though it may be , it makes sense that more and more developers and contributors should start to struggle with the shifting assignment of semantic meaning to the HTML5 elements. I wrote about this on Halloween in my post HTML5 kills [time], Resurrects [u], where I struggle with the changes elements have gone through from HTML4 to HTML5, and even during the course of the development of HTML5.

It makes sense, then, that given all this flux people might start to grapple with each others' definitions of semantics in the context of HTML5 elements. This week has seen a lot of activity around that topic, kicked off by the article Our Pointless Pursuit Of Semantic Value by Divya Manian. Regardless of the title, it's an interesting opinion piece about the process of choosing an element when coding a page. She hits on four main points in the post:

1. The web no longer consists of structured content;


2. Is it really accessible?


3. Is it really searchable?


4. Is it really portable?

The article itself is a good read, but the comments after the article include a lot of well-thought responses, some of which were reformulated and written up as separate responses of their own. Many felt the article itself was too aggressive and made over-generalizations, even to the point that the Smashing Magazine editor-in-chief wrote that the article should have been edited better. I disagree. The tone of the post is what kicked off the maelstrom of debate that has been lacking for some time now on the value of struggling with semantics in HTML5.

Jeremy Keith wrote a response on the same site, Pursuing Semantic Value, where he points out that there truly is a semantic difference between elements:

[...] a div conveys no meaning about the contained content whereas a section element is specifically for enclosing thematically-related content [...]

I disagree with his example of how you can see the difference in some browsers, since it is based on an arbitrary style decision made by a browser vendor and inserted into the default browser stylesheets:

You'll notice that the same element (h1) will have different styling depending on whether it is within a div or within a section element [...] So that's one illustration of the practical difference between div and section.

Regardless, his points clear and a good read for anyone who is struggling with choosing the right element and who might find him/herself giving up too easily and falling into the dark trap of div-itis.

Steve Faulkner weighs in with a comment on the original article that he then converted to a post on his own site, HTML5 semantics and accessibility. He opens up by, as he says, stating the obvious:

Semantics are not just about accessibility, accessibility is not just about assistive technology. But semantic information (name, role, states and properties) carried by HTML elements and attributes is integral to making content on the web accessible, especially for those who rely upon assistive technology to access and interact with web content.

He goes on to cover hgroup, header, hgroup, figure, figcaption, longdesc (the attribute) and even the HTML5 outlining algorithm and reminds us that the browsers have the burden of making these all function as accessible elements, driven by the developer community.

Paul Irish responded to Jeremy Keith's response in his post Semantics in practice and mapping semantic value to its consumers. He distills the struggle between and with accessibility and semantics pretty well, in my opinion, with this statement:

The practicalities of making accessible web content are messy, but important. The fact that we seem to spend more time on div vs article vs. section than on learning ARIA is a crime. (Furthermore, learning ARIA isn't complete unless youre listening to the results in a screenreader.)

John Foliot jumped onto the response bandwagon with his aptly titled post, My Thing About the Thing That Thing Wrote About Thing. His response is much more aggressive on the accessibility side and is far too difficult for me to distill with one takeaway quote. You need to really read through his post to understand everything. He was, however, nice enough to provide a tl;dr version:

Divya is quite confused about web accessibility. I examine everything she says in a detailed, semi-sarcastic, no-holds barred manner. Conclusion: Semantics matter – a lot.

In case you are wondering what that opening image is from, I stole it from CSSquirrel and its post The Value of Meaning. Consider that snippet from the comic to be my selection of a quote from the article.

Recap

Recent changes and chaos in HTML5 are frustrating developers who already struggle with the proper application of these new elements. One article exclaiming this frustration has started a much needed (even if it seems like common sense to many of us) discussion of how we as web developers need to approach choosing the right element for the job. If you are working in HTML5, it behooves you to read these articles and posts, and especially to read through the comments — here are gems of ideas and a treasure trove of links to help educate yourself. Take advantage of them.

Update: November 18, 2011

On some level I think Smashing Magazine has become ground zero for this debate. Bruce Lawson has a new article today on the site, HTML5 Semantics. This article goes into a good deal of depth on semantics and is worth a read.

Read More

Even the Return of [time] Is a Painful Process

Last Monday I wrote about some recent changes to the WHATWG HTML5 draft spec (HTML5 kills [time], Resurrects [u]), which then lead to my post discussing how the process to adjust the HTML5 spec only serves to confuse developers (End of <time> Is Not Helping the Case for HTML5). Then we all heard that our voices as developers were effective in restoring an element we valued to the W3C version of the spec (Well, It's about <time>).

And that wrapped up a nice little story about how, even with a convoluted process within and between WHATWG and W3C, change was affected.

As I started writing this post, <time> had not yet been reinstated. Though the direction from the HTML Working Group chairs was to restore the element [...] no later than the end of day on Tuesday 8th of November, that only happened within the last hour or so (probably around 12:30 EST on November 11).

This day-and-a-half delay isn't much at all. When measured against the whole of the life of the HTML5 specification (which is still ongoing) and considering nobody ran out and dropped <time> from their projects, it seems hardly worth mentioning.

Except it isn't a minor issue when you consider whether this is the normal process that the HTML5 specification will continue to follow.

Steve Faulkner, involved in the discussions from the start, sent an email the day after the promised revert date asking for an update and received this response:

The Chairs are working on this situation. Please be patient.

No expectation management of timing or any detail on what is happening, just a request to be patient. In my office, this is an unacceptable response. To see it come from the W3C and have no recourse to walk down the hall and set someone straight on expectation management is infuriating. Steve Faulkner's statement in the original email rings true with me:

I suggest the appearance of intransigence in resolving this issue only serves to undermine community faith in the W3C's stewardship of HTML.

It is my understanding that Ian Hickson (Hixie) has been silent on this topic, declining interviews, until this post from .net Magazine, Ian Hickson responds over HTML5 getting 'time' element back. This is an interesting statement from that article:

When we reported on the latter [the W3C decision to restore the <time> element], Hickson wasn't available for comment, but he's since kindly decided to answer our questions on the original backlash and the element's reinstatement.

In the interview Hickson makes his case and states the <time> element will be restored and will also take into account some of the new use cases from the recent debate. He also suggests other elements like <geo> or <scalar>, which could handle other highly specific data formats that the proposed <data> element might be too generic to tackle.

People are so fired up that even what I consider an off-hand comment about future HTML development resulted in a series of tweets and even an email to the W3C public mailing list with the suggestion to replace the HTML5 editor, by which the writer means Hickson.

Meanwhile, unrelated to that message, the WHATWG blog (Please leave your sense of logic at the door, thanks!) was updated with this week's news describing the return of <time>. The better news, however, is the return of <time> to the W3C version of the HTML5 specification.

The even better news is that with both WHATWG and W3C restoring <time> (or at least promising to) is that we are now not at immediate risk of seeing the HTML5 specification for into two similar, yet competing, standards managed by two different bodies with two different processes. It's bad enough we have ISO HTML, and look how well that's been adopted.

Seeing this chaos over just the <time> element has eroded my confidence in the process within and between WHATWG and W3C. To be fair, this may be the only process that works for them, but my distaste for it makes me question that. While I may be better off not paying attention to every detail, I am not so confident that doing so will result in a specification that will addresses my needs.

Update: November 17, 2011

The conversation you see in the comments below shifted over to Google+ as the week started. If you are curious, then you can read Ian Hickson's post (and its accompanying comments) and then read Steve Faulkner's response.

Read More

Flash Isn't Going Away, Except from Your Mobile

You may have heard some rumors that Flash is going away. You may read it as vindication for Steve Jobs. You may have decided web development will now change. You may be under the impression that HTML5 can do all the things Flash can. You can be excused when you read much of they hype, including such link-baiting headlines as Jobs Was Right: Adobe Abandons Mobile Flash Development, Report Says, clearly intended to draw Apple fanboys. Some of the news today:

• Exclusive: Adobe ceases development on mobile browser Flash, refocuses efforts on HTML5 (UPDATED)


• It’s Official: Flash Mobile Player is Dead


• Adobe stops developing Flash for mobile

Before we get too far ahead of ourselves, this cessation of development is for mobile devices only (read Adobe's release). I also want everyone to take a deep breath and stop crediting Apple with this. Adobe has long been unable to make a Flash player for mobile devices with a small enough footprint to not feel like you are wading through pudding to see some pointless animation (or worse, a navigation bar). The iOS market share in the mobile space is still below Android's (suggesting to me that Apple cannot kill it on its own), but Flash's ability to play well on anything in the mobile space is still below all of that.

We can expect this to affect how Flash will be implemented on other sites, but not immediately. Web developers worth their pay are moving toward adaptive layouts that scale and reformat themselves for mobile devices. These developers have mostly excised Flash from their toolkit because it doesn't play well with these new approaches. Younger, less experienced developers, along with developers trapped in 2001, will still use the only tool they have (insert hammer/nail metaphor) until they have exhausted it.

As someone who has been resistant to Flash on client projects for years, partly because of accessibility concerns and partly due to its resource demands, there is no love lost here for the platform. I am happy to see it wander off into a corner and yield right-of-way to CSS3, HTML5 and its related specifications. Over 10 years ago, when Flash was already causing stress to web developers and user interface designers, Jakob Nielsen finally got on board with his article Flash: 99% Bad. Today is just another step in a much larger process of web standards development, even if Flash wasn't an official one (de facto has carried it this far).

In the meantime, expect to see Flash persist on the web of desktop browsers and expect to see it persist in old, forgotten sites for years (perhaps most of the restaurant web sites I see). Until HTML5 can figure out what it wants to be when it grows up (End of time Is Not Helping the Case for HTML5) and the debate over video codecs truly ends (Are Patents Killing HTML5 Video?), things aren't going to change for most of us very soon.

I am intentionally skipping the discussion around Adobe's statement to more broadly support HTML5, since it's not really news given its latest products. I'm also skipping the statements from Adobe about using Flash to feed to app development platforms like AIR since I think we all have seen that move for a while now.

Related (on this blog)

• Adobe vs. Apple or Flash vs. HTML5, April 12, 2010.


• Adobe to Drop iPhone Support, Target Android, April 21, 2010.


• More Salvos from Apple and Adobe, to No One in Particular, May 13, 2010.


• More on HTML5 as DHTML, August 8, 2011 (for the Adobe Edge points).


• Thoughts on Muse (Obvious Pun Avoided), August 16, 2011.

Update November 10, 2011

As I suspected, the hype is starting to settle down after a day has passed. Some more news bits with more of an overall perspective:

• Adobe axes Flash for TVs too at CNet.


• Mobile Flash ISN'T dead at ZDNet.


• Some Thoughts On Flash And Devices by Ben Forta of Adobe.

Read More

Well, It's about [time]

The decision to allow <time> back into the HTML5 fold has been made. Just like that, one element is restored. This recent dust-up still tells me that all the elements are always in peril.

You can read the full decision in the email archives. This section of the email describing the process is worthy of a blog post of its own, but I just don't have the energy to trace it all out tonight:

This change is related to bug 13240 [1] which was never sent to the HTML WG since it used a possibly incorrect Bugzilla component. Since WG members were NOT notified of the creation of this bug the Chairs have decided that this change should be subject to the Enhanced Change Control rules in the WG Decision Policy [2]:

"Therefore during a pre-LC review, or during a Last Call, feature additions or removals should only be done with sufficient prior notice to the group, in the form of a bug, a WG decision, or an on-list discussion. This applies only to LC-track drafts and does not apply to drafts that may include material for future versions of HTML."

We therefore ask for a revert of this change to be completed no later than the end of day on Tuesday 8th of November. If this revert is not complete by that time, we will instruct W3C staff to make this change.

You can also read the full bug report (filed because <time> was removed) along with the feedback.

If you are interested in tracking the process itself, you can also read the minutes for the meeting. The minutes don't provide a clear resolution and include nuggets like this which only continue to concern me about the whole process:

mjs: asking for vote to not having time element vs having time element

1 vote to not have it...larger number of people (7) would like to have time element

mjs: asking for data element vs not having data element

... it seems that it's clear (not full working group) favor having both elements <time> <data>

hixie: most of these use case are irrelevant

Yes, I cherry-picked that.

You can also read my other two posts on this topic if you need some context:

• HTML5 kills <time>, Resurrects <u>


• End of <time> Is Not Helping the Case for HTML5

Also, don't forget to see CSSquirrel's cartoon: Can Hixie’s <Data>leks Exterminate <Time>? It's funny because it's true. And daleks.

Update

Shortly after the decision came down regarding the return of <time>, Tantek Çelik put together a proposal for changes to the <time> element with the W3C:

Add the <time> element to HTML5 with all of the following

• the functionality it had before removal


• plus support for year-only dates per [1] (e.g. vCard4 RFC6350 / hCard 'bday' use-case)


• plus support for year-month only dates per [2] ("")


• plus support for month-day only dates per [3] ("")


• timezone per [4]


• duration per [5]

Read More

End of [time] Is Not Helping the Case for HTML5

Yesterday afternoon I posted a general overview of recent changes in HTML5, focusing on this weekend's development over the removal of <time>: HTML5 kills <time>, Resurrects <u>

I thought I was already a little late to the party, but apparently not so. With the start of the week people swung into action to protest the move, even firing up a brand new site, Why no <time>?, working its way across the web thanks to the #occupyhtml5 hashtag on Twitter.

As you follow the hashtag and read comments on Bruce Lawson's blog post and Zeldman's blog post, you can see a trend start to emerge — people are often annoyed because they have already implemented <time> in their own projects. For some it's personal and pet projects, for others it's been done on client sites, and then there are popular sites that have worked it in as well, such as Reddit, The Boston Globe, the default Wordpress theme, and now parts of Drupal's core.

Each of these represents some investment of time, effort and/or cash (I argue all three). These are people implementing it before it's a final specification. They are selling bread when the batter isn't even fully mixed but with the promise that it has no nuts.

In January 2010 I wrote about whether it was too soon to advocate HTML5. At the time I believed it was too soon. As the specification has moved forward and people have found good business cases for leaning on promised features (who aren't confusing them with WebGL, SVG, CSS3, and so on) I have started to warm to the idea.

If you go back to August 2009 you might recall when the HTML5 Super Friends (Zeldman, Jeremy Keith, Eric Meyer, etc.) got together to voice their concerns over elements and attributes in HTML5, even raising points about <time>. Back then the campaign got some resolution and things seemed to stabilize for at least one element — <time>.

This recent dust-up leads me to question just how stable the specification is. Even <time>, after a review and edits, still only got just over two years before it was gutted. Software projects can take that long to implement, so relying on a feature (in this case an element) at the start of a project that might go away before you are done is a huge risk.

If HTML5 is supposed to be a reflection of the current state of web development, as we see in its cavalier approach to attribute quoting, closed elements, proper nesting and so on, then I can't imagine why an element in the wild for over two years gets cut while other derided elements like <u> get a reprieve and are brought back into the fold.

Now let's add the case that WHATWG has made for moving HTML5, the one under its auspices, to a version-less model. WHATWG explains it in the post HTML is the new HTML5:

…[W]e realised that the demand for new features in HTML remained high, and so we would have to continue maintaining HTML and adding features to it before we could call "HTML5" complete, and as a result we moved to a new development model, where the technology is not versioned and instead we just have a living document that defines the technology as it evolves.

We have just witnessed what that means. An element in which significant investment has been made can just go away at the whim of one man. For this reason John Foliot has hit the nail on the head with this tweet when referring to the HTML5 specification:

I am taking a different approach with clients. I am resisting the gee-whiz desire to be bleeding-edge with no business case to support HTML5 implementation and sticking with HTML 4.01. It's amazing how limiting that isn't given all the other great things going on with parallel web standards.

Update November 2, 2011

• To distill the post Timeless by Jeremy Keith, Keep using the time element.


• Oli Studholme touches on these same points and discusses <data> in Goodbye time, datetime, and pubdate. Hello data and value.

Update November 3, 2011

The <time> element has been restored. Read more: Well, It's about <time>

Read More

HTML5 kills [time], Resurrects [u]

The HTML5 specification as managed by both W3C and WHATWG is an unfinished, incomplete specification that can change at any time. That isn't a criticism, it's just a statement of fact. It's a fact often ignored by people and companies who choose to implement it and then cry foul when something changes.

<i> and <b>

So far HTML5 has done things like convert the deprecated (in HTML 4) <i> and <b> elements to impart stylistic meaning with specific results. While the stylistic effect was known, this is why I stopped using them years ago, instead imparting semantic meaning by using <strong> and <em> and style via CSS. HTML5 Doctor covers this in more detail in The i, b, em, & strong elements. This caused me much consternation.

<small> and <hr>

Then they restored the <small> and <hr> elements by giving them semantic and structural meaning, repurposing yet more mis-used elements for reasons different than how people were already mis-using them. Once again, HTML5 Doctor addressed this in the post The small & hr elements.

The <img> altAttribute

Then in what I consider to be a profoundly anti-accessible move that can only make it easier for CMS vendors to cut corners, the requirement for an alt attribute on every <img> element was dropped under specific conditions. I know I wasn't alone on feeling this was a terrible decision when my two posts on this topic were widely distributed and still see a good deal of traffic six months later: Image alt Attributes Not Always Required in HTML5 and More on Image alt Requirement in HTML5.

And Now <u> Returns

I suppose, then, that I should not have been surprised when word came down that the <u> element was back. This is an element we blocked in our CMS, telling our clients that an underline meant text was clickable and there was no good reason to use it in regular copy. Even so, I still had a use case that I thought made sense — to indicate what character for a form field is accessible with the keyboard via the accesskey attribute. So of course the real reason for its resurrection surprised me. Let me reprint the entire entry for <u> in the WHATWG HTML5 specification:

4.6.18 The u element

The u element represents a span of text
with an unarticulated, though explicitly rendered, non-textual
annotation, such as labeling the text as being a proper name in
Chinese text (a Chinese proper name mark), or labeling the text as
being misspelt.

In most cases, another element is likely to be more appropriate:
for marking stress emphasis, the em element should be
used; for marking key words or phrases either the b
element or the mark element should be used, depending
on the context; for marking book titles, the cite
element should be used; for labeling text with explicit textual
annotations, the ruby element should be used; for
labeling ship names in Western texts, the i element
should be used.

The default rendering of the u element
in visual presentations clashes with the conventional rendering of
hyperlinks (underlining). Authors are encouraged to avoid using the
u element where it could be confused for a
hyperlink.

Proper names in Chinese and misspelled words. The u has returned and we get little detail for how to use it but plenty of detail on how not to use it.

Once again HTML 5 Doctor came to the rescue and provided explanations and use cases for the zombie <u> element in the post The return of the u element. To distill it here, some examples:

• Chinese proper name marks, such as the names of people, places, dynasties, or organizations. It's akin to capital letter in English. Eg: 屈原放逐，乃賦離騒。左丘失明，厥有國語。


• For indicating family names in Asian languages. Given that the family name often precedes the given name, this can be confusing to Western readers. This is an alternative to the capitalization we often see when translated to English. Eg: Lynn Minmay versus LYNN Minmay.


• To indicate potential spelling errors, like you might see in MS Word or word processors and browsers with spell checkers. Eg: This is not my bootiful house.

In each of these cases you could use CSS to modify the <u> display to put a wavy line under the text (for the first and third examples) or to shift the characters to uppercase (the second example). The argument here is that the <u> underline will still render if the CSS is lost.

The specification lists the browsers that support this element, showing Internet Explorer, Firefox, Opera and Webkit. These browsers support it from its prior incarnation, however, as they have been supporting the <u> element since its presence in prior versions of HTML. Whether they support this new re-imagining is a different story. Since this new explanation is still primarily about display, the browsers may support it's new meaning by accident. The wavy line CSS, however, is only in Firefox right now.

The End of <time>

Over the weekend I saw a tweet-storm from people who are closely tied to the pulse of HTML5. The <time> element was slated for destruction and quite a lot of people who have come to rely on it immediately swung into action — partly to educate those of us who aren't so intimately familiar with the element. The #occupyHTML5 hashtag on Twitter is on fire with people deriding the decision, though I defer to two experts on the subject to give a little explanation.

Ian Devlin, author of the new book HTML5 Multimedia: Develop and Design, wrote up his reaction in "On the disappearance of HTML5 <time>." To quote:

Many documents and pages that get posted on the web have some sort of timestamp attached to them. Think of every news and blog article that’s written, this very post included, that indicate somewhere when it was posted. Having a machine readable element that encapsulates this special case piece of information is very useful for both machines and humans alike to read and understand.

He notes that the new <data> element, which is intended to replace <time> as a more generic element, isn't a bad idea in itself, but is also a little late to the game.

Bruce Lawson, one of the HTML5 Doctors and one author of Introducing HTML5 (along with his role as standards evangelist at Opera), has received quite a lot of support for his post Goodbye HTML5 <time>, hello <data>! Awful Cher video notwithstanding, he raises good points:

<time> (or its precursor, <date>) has an obvious semantic (easy to learn, easy to read). Because it's restricted to dates and times, the datetime attribute has a specific syntax that can be checked by a validator. Conversely, <data value=""> has no such built-in syntax, as it's for arbitrary lumps of data, so can't be machine validated. This will lead to more erroneous dates being published. Therefore, the reliability and thus the utility of the information being communicated in machine-readable format diminishes.

He goes on to point out that Reddit, The Boston Globe, the default Wordpress theme, and now parts of Drupal's core have built <time> into them.

A request to reverse the decision to drop <time> has already been filed. There is also a shared document for people to log their arguments for keeping <time>, ostensibly for taking back to Hixie to reconsider the decision.

The Takeaway

Given all the ongoing tweaks to the HTML5 specification by WHATWG, my opinion that dropping the version number and making it a living document with no set versions is flawed. As developers who want to be on the bleeding edge start to integrate elements and attributes from a specification that's not fully baked, this moving target just means more refactoring and ultimately cost or delays to the end users and/or clients.

Related

• The return of the <u> element


• Second chance for u in HTML5


• Goodbye HTML5 <time>, hello <data>!


• On the disappearance of HTML5 <time>


• HTML5 scraps semantic "time" element


• Ian Hickson's note closing discussion on the change.


• 4.6.10 The <data> element

Updated November 3, 2011

The <time> element has been restored. Read more: Well, It's about <time>

In case you had not read my piece following up this one with a broader look at the whole process around removing and restoring an element, go read End of <time> Is Not Helping the Case for HTML5

Read More

Twitter's t.co Continues UX Failure of Link Shorteners

It's been a few weeks since Twitter moved to its own link shortening service for tweets. Originally the shortener only kicked in for tweets over 18 characters, but Twitter recently moved to have it affect all URLs in tweets. Twitter's argument was that this allows Twitter to reduce the number of spam and phishing URLs embedded in tweets. In Twitter's own words (from the t.co site):

Twitter uses the t.co domain as part of a service to protect users from harmful activity, to provide value for the developer ecosystem, and as a quality signal for surfacing relevant, interesting Tweets.

Twitter's Reasons for the t.co Shortener

Twitter's explanation sounds reasonable but doesn't bear itself our now that I've had some time to try it out. Let me explore...

As Protection from Spam/Phishing

I still get the same number of spammers on Twitter, I did not expect a link shortener to change that. Those spammers also use link shorteners, so whether or not the t.co service came into play it wouldn't matter much — the link is still obfuscated. If the t.co service was doing its job, however, then those tweets would be caught or flagged. Even if it wasn't a pro-active service (because we know people can change the destination of a link shortened by many services, rendering it malicious from an initial innocuous configuration), I would expect it to do its job when I follow a link. It doesn't. Just this morning I received a spam tweet, and for the scope of this post opted to click the link. The t.co address showed up in browser, it spent time processing, and then sent me to the phishing site. Twitter's first claim is false.

A couple weeks ago I followed a tweeted link from a local business that fed through the t.co service. The t.co service told me that the link was to a spam or malware site. It was not. The link was to an online petition for a local issue. While I was motivated to just grab the original link from the tweet, there's no way to tell how may others may have had the same experience and were unable to weigh in on the petition. The risk here is that the t.co can also produce false positives, damaging anyone's reliance on Twitter as a link dissemination tool.

As Value for the Developer Ecosystem

Let's be clear here — as a user I don't care how much easier it is for developers. I don't let my web team just throw a bunch of fields on a web form without regard to the end user, no matter how much more quickly they can do it. But Twitter has a model that is less about the end user and more about driving organizations to rely on Twitter through its API and reporting features. The t.co shortener provides a boon to Twitter because it makes it easier for web masters to see how much traffic came to their site from a Twitter-shortened link.

Sometimes that t.co link isn't from Twitter (it's been shared elsewhere such as a blog, through originally from a tweet). Sometimes the same web page address has more than one t.co address. Sometimes that t.co link is to a bit.ly (or other shortener) link, which are often created for use on Twitter anyway.

As a Quality Signal for Relevant or Interesting Tweets

Given that I have no confidence in Twitter's ability to filter malware, spam and phishing sites, I certainly cannot believe that quality is an appropriate word. Just seeing the t.co address in a tweet doesn't tell me that it is relevant or interesting. Twitter may decide a link or tweet is relevant or interesting simply by measuring how many clicks it gets. In the absence of a clear explanation, those two metrics are also suspect.

Other Factors

Twitter Clients

I use TweetDeck on my computers and Seesmic on my phone. I have used Hootsuite and sometimes I use Twitterfall for a Twitter wall at events. They all display the t.co address instead of the full address underneath. These apps don't update at the same pace as the Twitter web site and not all users will allow frequent updates (whether by corporate IT policies or lack of interest) to their Twitter clients for when they do support expanding the t.co addresses.

This means I regularly see a t.co address. This wouldn't be an issue except I rely on the URL to know what will happen when I click a link: youtu.be means my Twitter client will play a YouTube video, twitpic.com means my client will show a picture, and so on. That link scent is now gone and I click fewer links as an end user because I don't know what I will get.

Twitter-Provided Tweet Streams

I use the Twitter-provided JavaScript code to embed a Twitter feed on my personal site. This does not expand the t.co URLs to show the full address. I push the Twitter-provided RSS feed of my tweets to my blog. This does not expand the t.co URLs to show the full address. Tweets pushed to Facebook or other services come with the t.co, again hiding the full address and link scent.

Extra Bandwidth Burden

At peak times I have found a link that goes through t.co takes longer to redirect me to my destination address. Often that destination address is being hit by only a few users, maybe a few thousand. The destination site can typically handle the traffic. The t.co service is taking the brunt of all the traffic from all the users on Twitter. This increases the bandwidth used across the web (and on my phone) and results in a longer click-to-destination time.

Copy/Paste Hassle

This may sound like a minor issue, but I regularly copy an entire tweet or just the URL from a tweet, often wanting to share via email, in my blog, or elsewhere. When I do that I typically get the t.co link, and I think it's obvious by now that I do not want that. If this affects me, then others who may do the same but not know how to tease the expanded URL out of a tweet could end up pushing traffic to my site from a blog that reports itself as a t.co referrer. In my reporting I will now be unable to distinguish traffic from a link and from a source that I may want to otherwise engage.

Blocking

I have read from a few sources that t.co is blocked in China. Given Twitter's prominence in recent events such as the Arab Spring, London riots, and now even Occupy Wall Street, creating a single point of failure with t.co means not only are the links blocked, but the expanded link may be blocked easily by any organization or government that wants to quell activity on Twitter.

My Former Reliance

I use a photo sharing service that pushes a link to the photo to Twitter. I used to take the RSS feed, along with the geolocation of the tweets, and pull the URL from the photo service to quickly hack up into a path to the thumbnail. I would then embed this modified RSS feed into a Google Map to show my activities and travels — most recently for a trip to Italy.

Because I was not using the Twitter API I could not be considered a developer, so I don't fall into Twitter's stated support for developers. As such, when the RSS feed from Twitter converted the URL from my photo sharing service my maps didn't display images and my followers stopped clicking links to my photos.

I also regularly craft URLs in tweets to remove the query string nonsense and unnecessary "www" prefixes (among other bits). I also regularly craft a tweet with the intent to make the URL visible to the end user because the address often feeds into my point or joke, Instead I find I exclude the "http://" from the address to get my point across, but it also means the link is not clickable for many users depending on their Twitter client.

A common annoyance is that Twitter now encodes URLs that are already far shorter than the Twitter-encoded t.co address. My own tweets have seen URLs double in character count after Twitter applies its link shortener.

Why Did Twitter Do This?

Three key reasons that I can contrive:

1. Twitter owes much of its success to developers building apps and integrating it into other services. Shortening URLs reduces the efforts an end user has to make in a third-party tool to stay under the 140 character limit.


2. Twitter's importance as a driver of web site traffic is reinforced when webmasters see the t.co links in their logs.


3. All the t.co links track information, which puts Twitter in a position to monetize the data it captures from each shortening and each click.

For all the reasons I state above, Twitter isn't really helping the end user (either content consumer or non-developer). Twitter's goals here are more for its own gains. In the end, since it's a free service they have the right to do that. I would certainly appreciate a more direct and honest explanation and a consistent implementation across its API and own services (RSS, JavaScript widget).

Sadly Twitter has continued to set the mark for other developers and, like its infinite scroll and other user annoyances, it will continue to enable developers to make poor decisions that are counter to a good user experience.

Related

From Twitter

• About Twitter's Link Service (http://t.co)


• Twitter's t.co URL wrapper is now on for all URLs 19 characters and greater

My Posts about Link Shorteners

• URL Shortener Spam Overrunning Blogger Stats, Feb. 4, 2011


• You Get What You Pay For, Dec. 17, 2010


• Libya's Terror Plot: Link Rot (Linkpocalypse?), Oct. 11, 2010


• More News in the URL Shortener Market, Dec. 15, 2009


• List of URL Shorteners Grows Shortener, Oct. 5, 2009

Read More