Microsoft Promoting the Death of IE6

That map above shows, as of February 28, 2011, the level of Internet Explorer 6 usage around the world. What's interesting is that this map was produced by Microsoft. This map is also (stolen by me) from a Microsoft site that is trying to move people off Internet Explorer 6, ostensibly on to Internet Explorer 8 or 9.

The site ie6countdown.com was unknown to me until today when I discovered it thanks to a tweet from @IE (Microsoft's Internet Explorer account) promoting it:

Interestingly, perhaps only to me, this tweet is exactly one year later than the surprisingly highly-publicized IE6 funeral (it supposedly died on March 1): RIP IE6 (Not Really, But Here's to Hoping). That people want to see IE6 go away is hardly news. You can read some of the history of companies and applications dropping support for IE6 by following the "IE6 must die" tag on Mashable articles. Sites like the obviously-named ie6nomore.com and ie6death.com have been pushing for these even longer. In fact, you can trace the history of the call for the demise of IE6 to the first breaths of IE7, sooner if you were a web developer.

While Microsoft is certainly hoping people will stop using IE6, and while the rest of us hope that people will also stop using IE7 (at least), there are still many users who have little or no choice in the matter. So many organizations built internal applications that rely on IE6 that upgrading the browser company-wide has a huge cost impact in everything from re-writing their applications to spikes in help desk requests. That employees cannot surf their local community not-for-profit site that inexplicably blocks IE6/7 is of little concern to IT managers.

What offends me about th ie6countdown site is how it promotes the use of an IE conditional comment to tell IE6 users to upgrade, something that may validate the existing terrible practice many developers have of trying to push users to the developer's favorite browser. However, since it only affects IE6 users and may help them take the necessary steps to upgrade, it has merit. Whether it makes their IT departments do so is another story.

Before you get too self-congratulatory about how much you used to despise IE6, take a look at this contextual view of IE6 back when it first launched, written by a Microsoft staffer: Presenting IE6 with the Lifetime Achievement Award. The title may seem a little too much like he's freebasing the Kool-Aid, but there is some good content presented in the context of 2001, including a screen shot of Netscape 6, my preferred browser at the time. If you want more history, go read Microsoft's history of Internet Explorer (I wish they would include the add-on to Microsoft Word that let you surf from the comfort of your word processor).

Much as I'd love to segue into the upcoming IE9 and where it stands, I'd rather this post solely be yet another (and hopefully last) memorial for IE6. That and I have to get to a meeting...

Update: 2:51pm

I came back from my meeting to find that Microsoft has a blog post about this very topic (announcements put it 2 minutes after my blog post): Counting Down Internet Explorer 6 Usage Share. In the post Microsoft acknowledges the IE6 funeral, talks about the olden days of IE6, and promotes the demise of IE6 — at least down to 1% market share. There is one statement for which I wish they had provided a link:

We know that many IE6 users are on the older browser because it's at their workplace. We've put together some resources for IT pros to help understand the business value of moving off IE6 and are delivering to them the tools to help them navigate the process.

A link to those resources would have been handy. Microsoft should take advantage of anyone reading its post who might need those links by allowing them to get to those resources immediately.

Later in the same post is a link to theie6countdown.com. Note the addition of "the" to the address. Apparently both work and answer separately at each address. Microsoft is costing its plan for the end of IE6 some valuable link juice.

Update: March 5, 2011

Bruce Lawson asks a very good question in the post The mystery of Microsoft IE6countdown.com — why can't Microsoft just make IE9 run on Windows XP, the most used OS in the world, instead of requiring users to upgrade to Windows 7 or Vista? Bruce points out that his employer, Opera, can do it. However, IE9 leans on features baked into the OS and Microsoft would much rather have you upgrade to the new OS anyway. My understanding is that Safari is the same on Mac. I know I have been unable to upgrade to the latest Safari on our older OSX machine without first upgrading to the latest feline version.

Recent(ish) News on Google, Bing, SEO/SEM

I have written many times here about SEO/SEM and how so much of it is sold to organizations by scam artists (though I recoil at the thought of calling them "artists"). Too often it includes demonstrably false claims, like how meta keywords and descriptions will help your site and that you should invest in the SEO vendor to do just that.

I also try hard not to spend too much time addressing the ever-changing landscape of the search engines, let alone focusing on just one of them. However, sometimes it's worth wrapping up some of the more interesting developments because they can genuinely affect my clients who aren't trying to game the search engines.

Content Farms and Site Scrapers

If you've spent any time searching through Google you may notice that sometimes you get multiple results on your search phrase that look the same in the results, but when visiting the site you find they are just ad-laden monstrosities with no value. Sometimes one of these spam sites would appear higher in the Google search results than the site from which the content was stolen.

Google has now taken steps to not only push those sites back down to the bowels where they belong, but also to penalize those sites. These changes started in late January and went through some more revisions at the end of last month.

I think it's fair to expect Google to keep tweaking these rules. Given all the sites that offer RSS feeds of their content (along with other syndication methods), it's likely that many sites integrate content from external sites into their own. The trick here will be for Google to recognize a site that has a original content that also syndicates third-party content from a site that has nothing but content taken from elsewhere. If you do syndicate content, then you should be sure to what you site stats and your ranking in the search results to see if you are affected at all.

Additional reading:

• Finding more high-quality sites in search
• Google Changes Algorithm To Penalize Site Scrapers
• Do You Republish Other People's Content? You'll Want to Read This
• Google Declares War on Content Farms
• Google Announces Massive Algorithm Change, Declares War On Content Farms, Including Demand Media

Page Titles

Perhaps you have spent a great deal of time carefully crafting your page titles (specifically the text that appears in the title and which displays in your browser title bar). Perhaps you have noticed that in Google the title you entered is not what appears on the search results page. This isn't a bug, doesn't mean your site was indexed improperly, and doesn't necessarily mean your page title had some other affect on your page rank. This is done intentionally by Google.

This does imply, however, that your titles are unwieldy. Google does this when titles are too short, when they used repeatedly throughout a site, or when they are stuffed with keywords. If you find that your title is being cut off (implying it's too long) then you may want to limit your title to 66 characters, or at least put the most important information in those first 66 characters.

Additional reading:

• Dynamic Title Snippets on SERPs
• When Google Rewrites Your Title Tags
• When Google Titles Don't Match Page Title

Social Media

It wasn't that long ago that Google and Bing said that links in social media (think Facebook and Twitter) will affect a site's position in search results (PageRank for Google). Some people may even be tempted to run out and post links to every social media outlet they can find, hoping that the more inbound links, the better for their site. Thankfully it's not that simple.

Both Google and Bing look at the social standing of a user when calculating the value of an inbound link. This can include number of followers (fans/friends on Facebook), number followed, what other content is posted, how much a user gets retweeted or mentioned and a few other factors. In short, those Twitter accounts that come and go in a matter of hours that tweet a thousand links into the ether aren't doing any good. A good social media strategy that is garnering success, however, should also give a boost to the sites it links.

What is not clear, however, is how URL shorteners (and which ones) affect the weight of those links.

Additional reading:

• What Social Signals Do Google & Bing Really Count?
• The Straight Dope on Facebook, Twitter, and SEO
• Google + Bing Confirm that Twitter/Facebook Influence SEO

Random Bits

These are some random articles I collected for posts that never happened. I still think there's good stuff in these and warrant a few minutes to read.

Google: Bing Is Cheating, Copying Our Search Results and Bing: Why Google's Wrong In Its Accusations should be read together. The accusation from Google that Bing is stealing its search results is fascinating on its own, but reading Bing's response demonstrates a host of things Bing also does differently. For me it was an entertaining battle, but that's about it.

HuffPo's Achilles Heel discusses how Huffington Post relies on questionable SEO techniques, which I equate to spamming, and wonders how long the site will be viable if AOL isn't willing to keep up the SEO game as the rules change. It could be a great purchase for AOL, or a dead site full of brief article stubs.

Is SEO Dead? 1997 Prediction, Meet 2009 Reality is a two-year-old article dealing with a twelve-year-old argument. And still relevant.

When A Stranger Calls: The Effect Of Agency Pitches On In-House SEO Programs should be particularly interesting to people who are charged with some form of SEO within an organization. Too often the unsolicited call or email comes in making grandiose promises and citing questionable data and results. This article provides a good position from which to push back and make sure you and your employer aren't taken to the cleaners.

A 3-Step SEO Copywriting Confession almost sounds like an admission of wrongdoing, but instead talks about how to structure your content for SEO without completely destroying it.

Additional reading (that I wrote):

• Negative Reviews Can Now Affect Site Rank Downward
• Your Site Speed to Affect Its Google Rank
• Verified: Google Ignores Meta Keywords

Facebook Likes…Your Data

Developers are starting to lean on the features of Facebook outside of the walled garden of Facebook itself, and there are implications for us as users that we might not be considering.

The current trends of web design include giant footers, social media icons, extensive background images, and the omnipresent Facebook Like button. This Like button is the eye of Facebook, watching our slow march across the web from its tower at the heart of Menlo Park. At least that's how it feels to me given its great potential to track my activity.

The use of the Like button on a site involves using Facebook's Open Graph Protocol, essentially allowing a site owner to publish updates to a user's feed. Facebook has realized that site owners aren't taking advantage of this feature as much as they could, so Facebook even reminded developers of this feature a couple weeks ago on its developer blog. If a site that has been liked by visitors decides it wants to start promoting heavily on Facebook, visitors might find their Facebook feeds being overrun with spam.

But that's not all. The Like button has just gone through a transformation, incorporating the more invasive features of the Share button, as the Share button itself gets phased out. Soon when you click the Like button on a page, you may find that your Facebook profile page (your own wall) will get the headline/title of the page, an abstract of the content and a thumbnail.

But wait, there's more. Facebook has just updated its Comments Box plug-in to make it available to outside developers with more features than previously offered. Users can leave comments that appear both on an organization's web site and on its Facebook page. Third-party commenting services like Disqus might be looking for a new business model if this takes off.

And that's just the last few days. You may recall back in January when Facebook decided to make a user's address and phone number available to developers. While this did not go over well with the community at large, all that angry tweeting and blogging (like this one?), along with some inquiries from Congress, have done nothing to keep Facebook from moving ahead. You may want to read today's post at Mashable, which includes some links to the letter from two US Congressmen and Facebook's response: Facebook Will Continue To Share User Addresses & Numbers.

As an aside, you may want to follow the advice from this tweet:

Since Facebook will now let apps access your address & number, I have set my no. to 650-543-4800 (FB Customer Service) http://bit.ly/gkJvYD

Facebook already contains the personal information of millions of users to varying degrees of detail. Add to that Facebook's recent moves to take over commenting and linking services, pushing third party content into its own walled platform, and tracking everything you do within Facebook itself, and you can see it is quite a pile of data waiting to be mis-used and abused by anyone who has access. Factor in Facebook's history of privacy problems and missteps, and we as end users should all be cautious about using all these features popping up across our favorite sites.

Perhaps in time we'll come to think of sites that incorporate Facebook features as phishing scams or as simply being out of touch. For now we need to be cautious consumers and responsible developers when it comes to the lure of the ease of use.

See the image in context at its source.

Related

• How to publish updates to people who like your Open Graph Page
• Whenever you hit Facebook's "Like" button you're signing up for a subscription.
• Facebook Like Button Takes Over Share Button Functionality
• Facebook 'Like' button replacing 'Share,' world domination next
• Facebook Comments Box
• Facebook Brings Its Comments Plugin to Outside Publishers
• Rogue Facebook apps can now access your home address and mobile phone number
• Facebook Now Shares Phone Number & Address With Third-Party Apps
• Facebook Will Continue To Share User Addresses & Numbers
• Securing Facebook Places (from Your Friends) (on this blog)
• Facebook Privacy UI Redesign Ideas (on this blog)

I'm not proud to admit this, but if Facebook could somehow expand the Grammar Filter (scroll to bottom) to the entire web, I might be more willing to succumb to Facebook's rule.

Update March 3, 2011

Some time ago I heard about the Facebook limit of 5,000 friends. I had long since forgotten about it and the complaints people posted. Apparently so did Facebook. Jeffrey Zeldman ran into this limit and found it affects his ability to Link anything. This may be a blessing, at least from my perspective. Regardless, read his post Like and Friend are broken in Facebook for more info.

Don't Choose Between Mobile Web and Mobile Apps

When Adobe released InDesign it included a novel feature that was otherwise unheard of to the average agency — the ability to import content into its page templates from XML data. Having developed a web content management system (QuantumCMS for those of you interested in hiring us), we had selected XML as an output option for content, allowing us to deliver that content into any medium that could support XML (such as web pages via XSLT). The idea we proposed to our agency clients was simple: author your content in one place, one data store, and push it out to the web, print, and other media.

None of them got it. Fear of the technology and comfort with an existing platform made it impossible for them to step back and evaluate whether there was a good business case in play. This approach (or lack thereof) is not limited to agencies. Unskilled web developers spent years building text-only versions of sites, feeling terribly proud of themselves when they realized they could wrap different templates around the same content instead of maintaining duplicate sites. Even now in 2011 I still see web developers take advantage of clients by selling the text-only site as an add-on service.

We're in the same place in the world of mobile. Organizations and developers (clients and vendors) are struggling with the right way to deploy their products to the masses (customers, end users). For reasons perhaps grounded in technology assumptions (preferences, fears, lack of understanding) they tend to look at two options for mobile — apps and web. Assuming that there are only two options is the first mistake they make.

With the recent marketing push over HTML5, CSS3, new APIs (such as geolocation) coupled with the most compliant browsers we've seen in years appearing on mobile in far greater percentages than desktop, we have a viable platform on which to develop web-based experiences that are functional and effective. The idea that a developer can develop one web-based application and deploy to the web, to iPhone, Android, Palm, Blackberry and Windows Mobile devices should be a compelling reason to consider that a starting point.

There are many things, however, that we cannot yet do via the web, such as access your mobile phone's camera, or take advantage of more robust touch-based interfaces. These are features best utilized directly through the mobile device, ideally via its API.

It is possible to develop an app for a mobile phone that is nothing more than an embedded web browser (by instantiating the default browser) along with elements that access the phone's hardware features. You risk the loss of a more robust user interface for your web-based content, but you gain the benefit of developing simpler apps for each platform while retaining control over your core service and content in your own hosted environment.

With the new payment models that are shaking out in the mobile apps market, the web-first approach might be a more appropriate way to build your business model. Given the uproar over Apple's recent requirement that subscription-based app developers offer subscription options through the Apple app store (and at no cheaper on their own sites), in exchange for a hefty 30% cut, relying on the mobile device itself to deliver your content becomes a suddenly more costly solution. Instead, just having a mobile-friendly site can be sufficient to handle sign-ins and subscriptions, which also carries over to other devices (iPad, Android) and platforms (desktop, tablets).

Certainly not everything can be deployed via the web. A music service, for example, is tough to do even with excellent support for the unfinished HTML5 audio element. But looking at a web-first or hybrid approach allows you to reduce your development and deployment costs as you support fewer platforms, and share your content with nearly any web-enabled device.

Related

• The False Dichotomy of Native vs. Web Apps
• How HTML5 Is Aiding in Cross-Platform Development
• Is Developing a Mobile App Worth the Cost?

Posts on this blog that help lay some of the groundwork of these thoughts.

• W3C Starts Mobile Web App Standards Roadmap
• Apps Are Not Killing the Web
• W3C Releases Mobile Web App Best Practices
• Targeting the Mobile Web
• Current(ish) Smartphone Use
• More on Hover vs. Touch
• UX Challenges in Touch Interfaces (at evolt.org)
• Luke Wroblewski on Mobile First

There is so much content out there about the Apple app store rules that, while I had planned to write post about it on my own, I felt that adding to the noise wouldn't help. Instead here are some of the links I cultivated for the post I never wrote.

• Apple’s Big Subscription Bet: Brilliant, Brazen, Or Batsh*t Crazy?
• Apple new subscription rules now upsetting developers, too
• Readability’s App Store Rejection Portends a Cloudy Future For Developer
• An Open Letter to Apple
• Opinion: Apple's subscription policy is a poisoned Apple
• Why you should fight Apple’s Subscription Extortion

Update: March 11, 2011

If you read An Open Letter to Apple from Readability, then you know that it submitted an app to the Apple App Store that was in limbo. The issue came down to the Readability business model (70% of subscriptions to writers) bumping up with Apple's new store rules (30% to Apple). Even though Readability already had a mobile version of the site, on Wednesday Readability released updated apps for multiple devices that are really just wrappers for web content. In the end, this can bypass the Apple App Store if Readability can deploy it all via the web, removing the need to use an in-app purchase that pushes 30% directly to Apple. Yesterday ZDNet covered this in the article Readability goes HTML 5 on iOS, expect others to follow, where I think you can see others are starting to see the viability of the business and technology model, partly spurred by Apple's new pricing model.

W3C Starts Mobile Web App Standards Roadmap

The W3C has taken a step toward gathering all the information relevant to the mobile web, as authored by its disparate working groups, under one umbrella as a singular (recurring) reference source: Standards for Web Applications on Mobile: February 2011 current state and roadmap (read the accompanying W3C blog post).

You may recall when the W3C released its Mobile Web Application Best Practices "cards" with tips and techniques for web developers diving into mobile. You may also recall that it was very focused on mobile and didn't address how those best practices are handled via the standard desktop browser (such as the tel: URI scheme).

This, however, promises to be a bit different. Instead of being pushed out by the W3C monolithic entity, one person has made the effort to take on this responsibility and clearly state that he can't possibly get it all right all the time:

...[T]he data in this report have not received wide-review and should be used with caution. Feedback on every aspect of this document should be sent to the author (dom@w3.org) and will serve as input for the next iteration of the document.

The document outlines a series of categories of technologies that apply to the web, including the relevant technology for each. These categories are:

• Graphics, which includes SVG, CSS, WOFF and other acronymns.
• Multimedia, such as audio and video.
• Forms, including the new input types and attributes like pattern and placeholder.
• User interactions such as touch and speech events and even a vibration API (no specs, just working groups).
• Data storage such as the different file APIs and local vs. web storage.
• Sensors and hardware integration which will lean on the geolocation API and eventually APIs for using your phone's camera and microphone.
• Network, which covers XMLHTTPRequest (level 1 and 2) and the WebSocket API.
• Communication using the messaging API to allow SMS and emails from web apps.
• Packaging, consisting of HTML5's ApplicationCache and W3C Widgets.
• Performance & Optimization such as the Mobile Web Application Best Practices along with support timing and threading.

Each of these items includes a table that outlines the appropriate specification, working group, maturity, stability, draft status, current implementations and test suites — if any — for each feature.

When it's all gathered in one place for us to review, it's a pretty compelling list of features in the pipe, even if we all know it will be quite some time before most of them shake out. I look at this roadmap as more than just a reference source, but as a path to shedding the costs and limitations imposed by building custom apps for each device (iOS, Android, desktop, television, etc).

Related

• Apps Are Not Killing the Web

WebM, H.264 Debate Still Going

On February 2, Microsoft released a plug-in for Chrome on Windows 7 to allow users to play H.264 video directly in Chrome. In addition, Microsoft has said that it will support WebM (VP8) when a user has the codec installed. And so began the fragmentation of the HTML video model, back to relying on plug-ins to support what was otherwise intended to be supported natively within browsers.

Microsoft went on to ask three broad questions in a separate post (HTML5 and Web Video: Questions for the Industry from the Community), taking Google to task for what Microsoft considers inconsistent application of its own patent concerns and openness (emphasis Microsoft's):

1. Who bears the liability and risk for consumers, businesses, and developers until the legal system resolves the intellectual property issues;
2. When and how does Google make room for the Open Web Standards community to engage genuinely;
3. What is the plan for restoring consistency across devices, Web services, and the PC.

The same day Microsoft was announcing its plug-in approach to addressing the WebM and H.264 battle, the post On WebM again: freedom, quality, patents came out addressing what it felt were the five most common issues raised with WebM (which I have paraphrased):

1. Quality: the argument here is that it's a function of the encoder and the WebM can match H.264;
2. Patent Risk: comparing the 164 unexpired U.S. patents used in a single encoder, he finds that 126 of them are there for the encoder's H.264 support, the remaining (used by WebM) are in a library released by Google.
3. Not open enough: there is little argument here, given that it's currently in Google's hands to manage and develop.
4. H.264 is not so encumbered: but only for non-commercial use for freely-distributed web video.
5. Google provides no protection from infringing patents: nor does MPEG-LA.

Changing the Nature of the Battle

On February 11, the post MPEG LA puts Google's WebM video format VP8 under patent scrutiny outlines how MPEG-LA, the licensing entity for multimedia codecs such as H.264, has put out a call for patents related to VP8, the underlying technology in WebM. That deadline for submissions is March 18, or less than a month away as of this writing. From there, MPEG-LA will create a patent pool of contributing patent holders for any items that are deemed essential to the codec. This patent pool can then be used to negotiate licensing. In short, VP8/WebM could soon be more patent encumbered than it has been. This puts Google on the defensive as it will have to show that none of the patents in use are valid and/or infringed.

The same author of that last post posted on the 14th at The Guardian, Royalty-free MPEG video codec ups the ante for Google's WebM/VP8. In case that title isn't clear enough, a new royalty-free video standard may be in the pipes. MPEG, a standards body separate from MPEG-LA (the licensing body) has called for proposals toward a royalty-free MPEG video coding standard. One of the goals is to make this new standard comparable to the baseline used in H.264.

If this pans out, it puts another barrier in front of the WebM offering from Google, namely that for WebM to be adopted it will have to best any new royalty-free MPEG codec. The three items that can bring WebM (VP8) down:

1. If the MPEG-LA call for for patents and resulting patent pool for VP8 nets some patents, MPEG-LA will now form a patent pool to push for licensing agreements, which Google will have to fight at each step.
2. If MPEG can genuinely develop a royalty-free video coding standard, it can beat WebM either from the patent perspective or by forcing WebM to be technically superior.
3. Assuming WebM can get past the first two items, it's still back where it started — in a battle for adoption and endorsement against the already entrenched H.264 standard.

Real-World Needs

Considering Google is the company that delivers so much of the video viewed on the web via YouTube, it makes sense that Google presumes it can take the lead on video codec standards. Netflix, however, has its entire business model built around video, which is now moving inexorably to the web. Netflix commented back in December (HTML5 and Video Streaming) that it needs some things sorted out before it can even rely on HTML5 and video to deliver its content (the first 6 of which it has resolved through its own proprietary technology):

1. The acceptable A/V container formats (e.g. Fragmented MP4, WebM, etc.);
2. The acceptable audio and video codecs (e.g. H.264, VP8, AAC, etc.);
3. The streaming protocol (e.g. HTTP, RTP, etc.);
4. A way for the streaming protocol to adapt to available bandwidth;
5. A way of conveying information about available streams and other parameters to the streaming player module;
6. A way of supporting protected content (e.g. with DRM systems);
7. A way of exposing all this functionality into HTML5.

It's clear that the web video debate extends far beyond the academics of HTML5. As long as issues related to patents and licensing are unresolved, or perceived as unresolved, we will see more proprietary solutions gain more ground, further balkanizing the future of video on the web.

If you think this doesn't affect the end user, all that time and effort put into creating proprietary solutions ultimately costs you as the consumer in the form of increased fees for your content. Granted, it will be some time for browsers to catch up with the selected codec, and yet more time for users to catch up with the supporting browsers, but the more this debate continues, the longer before we can even start that long road of user adoption.

Possibly the best outcome we can hope for is that this battle results in a royalty-free MPEG standard, nullifying many of the arguments against both H.264 and WebM.

Related

• H.264 Getting Dropped from Chrome, January 11, 2011.
• Simple HTML5 video player with Flash fallback and custom controls, February 17, 2011.

Beyond Hash-Bangs: Reliance on JavaScript Is a Bad Idea

In November I wrote up a post (How Many Users Support JavaScript?) outlining the process and results from Yahoo's study about how many users have JavaScript disabled (How many users have JavaScript disabled? and Followup: How many users have JavaScript disabled?).

The Numbers

In those articles, Yahoo stated that even using the meager percentage it found, that number corresponds to 20-40 million users across the internet. At 2009 census numbers, that's the entire population of New York State on the low end or more than the entire population of California on the high end. That tiny percentage is no small number of users.

Before you think that all those users are sitting in parts of the world that don't care about your product or service, Yahoo itself fields 6 million visits per month from users without JavaScript (whether it's disabled or the browser doesn't support it). That easily justifies Yahoo's work to make the home page accessible to everyone.

Gawker and Twitter

In a very recent example of what an over-reliance on JavaScript can cause, on Monday the sites under the Gawker umbrella, Gizmodo, Lifehacker, iO9, and Gawker itself, all failed (Gawker Outage Causing Twitter Stir). And not in the typical way we're used to seeing such as server 500 errors, timeouts, and other artifacts of generating too much traffic or pushing the wrong button. In this case the error was a function of a complete reliance on JavaScript to render the page. The sites are back up and functional, unless of course you have JavaScript disabled (this screen shot is from today):

The Gawker sites aren't the only culprit. Twitter is another example. When I attempt to link to a tweet from last night about these issues, I can't access the page at all with JavaScript disabled (turn off JavaScript and try it yourself). I just end up at the Twitter home page. Some other sites rely on so much JavaScript on top of the HTML that the page is constantly reflowing. One culprit is Mashable.com, requiring me to wait patiently while the page finishes drawing before I risk any interaction with the page for fear of an errant click.

How JavaScript Is Breaking the Web

Last night I came across a post, Breaking the Web with hash-bangs, which specifically references the Gawker downtime along with Twitter's confounding page addresses. You might recognize the site (or author) because it's the very same site that took issue with Yahoo's methodology for reporting on JavaScript disabled users (Disabling JavaScript: Asking the wrong question). In that post he outlines other ways that browsers might report a lack of JavaScript support:

• The site serving the JavaScript file might be unreachable, a risk when relying on JS libraries hosted on third-party sites.
• The URL for the JavaScript file needs to be correct.
• The connectivity to the JavaScript file must exist, which means network lag, DNS issues, bad jumps, etc. can all break that path.
• An intermediary server passing that JavaScript file along could decide it is spam or malware, based on its own rules, and just purge the contents of the file.
• Other policies at the destination may strip the file or block it in some way.

In last night's post he draws attention to the new reliance on page addresses that really only exist as fragment identifiers that are then parsed by JavaScript to return a particular piece of content. What this means is that in order to see the page, you have to not be in the 20-40 million number without JavaScript support and you have to successfully make it past the five items I outline above. Oh — and the JavaScript cannot have any errors. Some examples of JavaScript-related errors (from the article):

• JavaScript fails to load led to a 5 hour outage on all Gawker media properties on Monday. (Yes, Sproutcore and Cappucino fans, empty divs are not an appropriate fallback.)
• A trailing comma in an array or object literal will cause a JavaScript error in Internet Explorer - for Gawker, this will translate into a complete site-outage for IE users
• A debugging console.log line accidentally left in the source will cause Gawker’s site to fail when the visitor’s browser doesn’t have the developer tools installed and enabled (Firefox, Safari, Internet Explorer)
• Adverts regularly trip up with errors. So Gawker’s site availability is completely within the hands of advert JavaScript. Experienced web-developers know that Javascript from advertisers are the worst lumps of code out there on the web.

I feel so strongly about how poorly Gawker implemented its new sites, about how Twitter relies on the same approach, how it all relies on a hack in Google's spidering technology in order to even make it into the search engines, that you really do need to go read this post, to which I am linking again: Breaking the Web with hash-bangs

For years I have tried to talk people out of relying on JavaScript for everything. I usually end up trying to explain the concept to someone who thinks it takes more time to build a site to not rely on JavaScript. Which is totally wrong. If all your forms validation is done via JavaScript, for example, then you are really putting yourself at risk (do you sniff for SQL injection attacks solely via JavaScript?).

JavaScript is a method to enhance your site (progressive enhancement), not replace features you should be building on the server and in your HTML. Relying on the end-user's browser, and there are so many variations, to execute your JavaScript without generating an error (which all too often brings everything to a halt) just isn't a very resilient approach to development. On top of that, how many developers really know how to build support for WCAG 2.0 into their JavaScript?

Without JavaScript there are a few sites on the web I cannot use at all, owing to their shoddy implementation practices and poor business decisions. On the bright side, surfing sites like Mashable without JavaScript means I don't see any ads and the page render time increases dramatically. However, even with JavaScript enabled, poor scripting techniques still spare me the sight of those ads:

I would be willing to bet that this simple JavaScript error would have brought any of the Gawker family of sites down. And if the JavaScript is passed in from the ad service, the only recourse is to cut the ad altogether and lose the revenue.

Even at that most basic level you can see how poor of a decision JavaScript reliance is.

Updates: February 11, 2011

In the post Hash, Bang, Wallop the author provides some alternate views and arguments on how the hash-bang approach isn't necessarily the wrong way to do things. His argument is compelling, until the end when he wraps up discussing users without JavaScript and users without quality internet access. His statement that JavaScript errors breaking execution can be almost entirely avoided with good development practices presumes that end-users have any control and that the amount of errors we see now is an aberration — something my 15+ years of experience tells me isn't true. He also talks about poor connections by saying that there are people daring to live somewhere in the world where packet loss is a problem. I somehow suspect that Twitter users in Iran or Egypt might disagree that they dared to live there, or had a choice.

Two more articles railing against the reliance on hash-bang URLs, AJAX and JavaScript:

• Going Postel by Jeremy Keith.
• Broken Links by Tim Bray.

And for a little self-congratulation, this post was referenced in this week's Web Design Update, something I have read for nearly its entire existence and hold with rather high regard. If you consider yourself a web developer and aren't on this mailing list, you're not really a web developer.

Updates: February 12, 2011

I found this script this morning which is designed to end the reliance on hash-bangs and the resultant URLs they force into page addresses: History.js.

History.js gracefully supports the HTML5 History/State APIs (pushState, replaceState, onPopState) in all browsers. [...] For HTML5 browsers this means that you can modify the URL directly, without needing to use hashes anymore. [...]

While this looks like a nice alternative to the hash-bang problem (which it is, not a solution), it relies on two things: the user having an HTML5-capable browser, and the JavaScript still executing despite everything I've outlined above.

In short, the wrong problem is being addressed here. The reliance on JavaScript is the issue, not just the methodology of that reliance.

Updates: June 1, 2011

The post It's About The Hashbangs points out that hash-bangs' use as a stop-gap until pushState is supported in browsers isn't a valid reason to use them. He also addresses how hash-bangs break standard URL rules, confusing and confounding tried-and-true server-side processing methods. It's worth a read.

Update: May 7, 2015

It's 2015 and yes, this is still a thing. So I'll just leave this here for your review: Everyone has JavaScript, right?