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?

Apps Are Not Killing the Web

Forrester Research is an oft-cited source by businesses when making decisions or declarations about trends and technologies. In many circles Forrester is something of a de facto standard for analysis. As such I fully expect to start dealing with a recent statement from its CEO claiming that the web is dead when I sit down to talk with clients.

On Thursday morning at the DeSilva + Phillips Media Dealmakers Summit, George F. Colony, CEO of Forrester Research was on a panel discussing the future of media in light of tablets and e-readers. Expanding on an answer to a question he fielded, Colony said, We think the Web is dead.

When he says we, he means the folks at Forrester. Back in October another Forrester staffer was quoted as writing that the golden age of the Web is coming to an end. This was in an article by The New York Times covering the hub-bub about Wired Magazine's over-hyped death of the web article. Wired's article relied heavily, but not totally, on a graph showing the decline of the web as we know it, but Boing Boing quickly refactored that graph with a more accurate visualization using the same numbers. You might recall that I wrote up my own response to Wired's argument in my post Enough about the Death of the Web

In May of 2009 Forrester also claimed that the smartphone was dead. To be fair, the full title of the study was The Smartphone Is Dead: Long Live Smart Phones and Smart Gadgets, showing that Forrester didn't really think the concept of the smart phone was dead, but that it was no longer worth breaking into its own category given the ubiquity of capable phones and devices. That may very well be the logic the Forrester CEO was using in his comments, although I don't think so.

The web is not dying (again). If anything, the advent of tablet and tablet-like devices coupled with support for HTML5 and CSS3 (really just CSS3) in the browsers that are coming on those devices (Webkit-powered Safari and Chrome on iPads, iPhones, and Android devices) is going to ensure that the web will be around for quite a while longer. The Webkit engine (along with the mobile version of Opera that many are grabbing) does a good job of supporting the newest still-in-development standards, creating opportunities for far more interactivity and style than could be achieved in browsers targeting just CSS2.

Angry Birds is a great example of an app that you cannot replicate as easily in HTML/CSS, if at all. But so many other apps are geared toward media, such as eReaders and photo sharing utilities, that delivering much of that content through a browser is a more cost-effective approach. For example, an app like Picplz has to be built separately for both iPhone and Android devices in order to use the cameras built into each. The method you use to browse your photo, profile, and the photos of others, however, is delivered through an embedded browser. This allows the app developers to focus on the features unique to each device while the universal elements are maintained back on their web server, removing the need to push an updated app to users for each minor tweak.

Soon we can expect that an app delivering content of any sort will really be a wrapper for a web browser, handling just the interaction with the hardware and operating system that is necessary for things like user validation, preferences, and so on. This will reduce the cost of app development as the heavy lifting is done via the web server and CSS3 (HTML5 if you've bought into the hype). You can expect to see RIM and Microsoft move to catch up by deploying more capable browsers to lower the bar for app developers to deploy to Blackberry and Windows Mobile devices. This closes the gap in available apps for each device, making them more appealing to more users.

This approach also supports users who don't have these new devices, allowing your typical desktop user with a capable browser to access the same content, even if he/she uses a mouse instead of a finger. A good example of this is the Marvel Comics comic book reader for Chrome. Originally built for the iPad, and supporting a swipe interface, viewing it in Chrome gives you a similar experience but with clicks instead of a more tactile experience.

The new model is build it once, deploy it across the web and your apps. Except it's not a new model. It just makes sense.

As I was wrapping up this post I stumbled across this article from The Nieman Journalism Lab, The Newsonomics of apps and HTML5. I think that, even though it takes a different path, it comes to similar conclusions as I do.

Update: February 10, 2011

Go read Robert Scoble's take on the new HP TouchPad. If he's right and it takes off, building web-based apps seems that much more like a good idea now, doesn't it? Supporting compiled apps for each of iOS, Android, WinMo, RIM and WebOS seems far less compelling to me.

Update: February 11, 2011

John Dowdell explains the concepts a bit more succinctly over at his Adobe blog: Blends of native and global. It's pretty much the same argument I make — some bits will have to be developed to run on the device, some bits can be best delivered via the web. Automatically excluding either of those options isn't a sound business or technical decision.

URL Shortener Spam Overrunning Blogger Stats

URL shorteners are in your web logs, stealing your clicks. Ok, maybe not in all your logs, but certainly they can show up in reports, tricking you to click on them, potentially exposing you to spam or viruses.

If you aren't familiar with URL shorteners, they evolved as a method to take those terribly unwieldy web page addresses (you know, the ones with all the random-seeming numbers and letters that go on forever) and replace them with short, simple addresses. Just being able to paste these shortened addresses into emails without them wrapping was already a good enough reason to use them. Twitter has made them a necessity thanks to its character limit coupled with peoples' desire to include some commentary on links they tweet. The process by which they work is simple — you provide one web address, and the shortener service provides another simple address that redirects all traffic to the address you provided.

But there is a risk. This obfuscation of the destination address makes it hard to quickly evaluate whether or not this is a link you want to follow. You can use these to RickRoll your friends, for example, hiding the true destination of the link. You can also choose links that are far less innocuous. There are many more issues with link shorteners, ranging from link rot to reporting, topics which I have discussed here before, but this time I want to focus on the destination address obfuscation, or what I am now calling Link Lying. And now I'm done calling it that.

There is a new trend that's been annoying me for some time now, but has picked up dramatically in the last few days. When I go to my Blogger Stats tab to see what kind of traffic this site is getting (which may be anemic, but is still valuable to me) I no longer see pages of value in the Traffic Sources section ("referrers" to us in the know, or "referers" if you misspell it like the HTTP spec does). Instead I see a stack of shortened links, nearly all of which point to the practically-prostitution site Adult Friend Finder (if I thought it was run by a bunch of whores before, this game of lying through linking just solidifies that opinion).

I am prepared to take the risk with shortened URLs from my Twitter stream, but I follow a list of people that I trust not to spam me. If they did, I simply wouldn't follow them. I know not to click on links from DM spam (such as when a friend's account is hacked). I know not to click shortened links in unsolicited emails. I had not considered that I'd have to apply the same wariness to my Blogger reports. This image demonstrates how these shorteners have taken over my stats, successfully tricking me twice now to click (this image shows just traffic from today).

It's not like the spamming in my stats is a new trend. I see links to sites show up regularly that clearly do not link to me in any way, but manage to get themselves in there regardless. But I don't click on those. I can tell by looking that they are spam. These next images show a week of stats, a month of stats and a year of stats. You can see how the value of this report has dropped off dramatically now that spammers have figured out how to overtake it.

Of the 7 (out of 10) links the other day that were from shorteners, only one presented me with a warning message from Bit.ly that the link itself might be a bad idea to follow. As you can see, this one points to the same site of liars that I reference above. Apparently this one has been reported by another user who was spammed and Bit.ly has flagged it.

But what's telling about this message is insight into how this bait and switch is possible (Bit.ly's language, not mine):

• Some URL-shorteners re-use their links, so bit.ly can't guarantee the validity of this link.
• Some URL-shorteners allow their links to be edited, so bit.ly can't tell where this link will lead you.
• Spam and malware is very often propagated by exploiting these loopholes, neither of which bit.ly allows for.

For those of you young studs looking to break into the cheaters and liars world of spamming via link obfuscation, that's all you are going to get from me out of this post. I think, however, it's pretty clear how this happens.

How You Can Avoid This

In this example, until Blogger fixes how these are reported by pre-filtering the links, you really can't avoid them. I recommend installing a link previewer in your browser. For example, in Google Chrome I have installed ChromeMUSE, which allows me to see the destination of the link before clicking it. Now I can see where the link goes without the risk of infecting my computer or otherwise visiting the site of a pack of liars.

Rely on a more robust service such as Google Analytics, or even something that reads your web server logs like WebTrends (which captures data on all browsers, not just the ones that can run the JavaScript that Google Analytics uses). Leaning on your Blogger dashboard is nice for a quick review, but when the referrers are spam links, you have to wonder how much of that represents real traffic and not just an attempt to show up high enough in your logs for you to click the link.

Net Effect

I already have a problem with link shorteners. I've said as much in previous posts:

• Libya's Terror Plot: Link Rot (Linkpocalypse?)
• More News in the URL Shortener Market
• List of URL Shorteners Grows Shortener

I don't trust that a shortened URL will bring me to a safe page. Certainly not when the link comes from a third party, an untrusted source. So if I get an email or a forwarded tweet, for example, and I see a shortened address you can be confident I won't click it. I am not the only one who feels this way. More people are coming over to this camp all the time. Eventually people will not trust shortened links on the whole.

In time we'll see more organizations who have rolled their own or branded a service like Bit.ly with their own address, letting Bit.ly perform all the technical work (redirections, reporting). Web content management systems are finally catching up to the trend, offering aliasing features to allow organizations to create shorter addresses for pages, sometimes bypassing the need for a shortener altogether. In time you may come to recognize a branded URL shortener, like nyti.ms or 4sq.com, and if you trust that organization then you may be comfortable clicking the link.

Related

• Ten Evil Uses for URL Shortening Services
• With 70% Spam Links, Facebook Blocks j.mp URL Shortener

Update: Feb. 26, 2011

While I didn't think this was unique to Blogger (which has improved dramatically as of late, thankfully), Vox (Scott) posts his own Wordpress stat frustrations and provides a nice link back to me.

Update: June 26, 2012

Found a post from May 2012 dealing with a similar issue, Link Shorteners and Referral Spam Suck. It was over a year since I posted this article and the problem still isn't going away. We may all just be getting used to it.

Apple.com (Not Really) Updated to HTML5

Apple has released a revamped version of its web site today, ostensibly in HTML5. Except it doesn't use anything from HTML5.

That Apple wants to move to the platform that it touts as the Flash-killer is not surprising. Apple refuses to allow Adobe Flash on its mobile devices and claims everything Flash does can be done in HTML5. While not totally accurate, it's certainly part of Apple's motivation along with its long-standing claims to support standards. I followed this for a while until it became just senseless bickering:

• 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.

A few very pro-Apple sites have already carried the news about Apple's new move to HTML5, citing the new look, one even offering a screen shot of the first four lines of the HTML as proof that it's HTML5.

Except when you look past the first few lines of the code, or really past the DTD which identifies the page using the new minimalist HTML5 DTD, all similarities to HTML5 cease. I'm going to go after the low-hanging fruit here, mostly because I am writing this on a self-imposed deadline. When I opened the source code, I looked for some telltale HTML5 elements, specifically nav, header, footer or canvas (that last one is supposed to be the Flash killer). I found none of them.

Instead I see the standard tag-soup of divs being jammed into roles now replaced with the new semantic and structural elements of HTML5. As an example, this screen shot shows the HTML that drives the footer, all wrapped in nested divs. These could be replaced with the HTML5 footer element.

I understand that browser support is probably the driving concern here. Apple may not want to implement elements that don't have support in many current browsers. But this half-baked approach, which may be copied by Apple die-hards and HTML5 n00bs alike, does more damage to HTML5 than just leaving the site in HTML4. No, this is a case where prioritizing the marketing message along with ongoing battles with Adobe and now Google are causing Apple's web development team to fail to implement the specification as it is intended (or will be, when it is final). Which calls into question just how well they will implement any aspect of it, including its attempts to supplant Flash.

But this roll-out wasn't done with a mountain of HTML5 fanfare. It is possible that I am being too critical, that Apple's updated site is the first practical step toward future and ongoing implementation of the unique HTML5 elements as the browsers catch up. In that scenario Apple can be forgiven. Except I am not quite so willing to let Apple off that easily given how hard it pushed its HTML5 Showcase back in June. The showcase wasn't really as much about HTML5 as it was about Safari, and then what CSS3 and JavaScript can do. HTML5 itself didn't have much of a role in that showcase. It was just a great way to get people to download and use Safari, given that the content was riddled with Safari- and Webkit-specific features. I'm not the only one who takes Apple to task for it (for example, Apple's HTML5 Showcase Less About Web Standards, More About Apple at Webmonkey). Given Apple's prior behavior regarding HTML5 (pushing primarily CSS3 and JavaScript) and its motivations (Flash foil, Safari pusher), I'm not so sure Apple is taking the right approach with the new site.

Apple isn't the only one making this HTML5-but-not-really mistake:

• HTML5 and CSS3 Confusion
• Google, Arcade Fire Confused on HTML5
• Google Doodle: Bouncy Balls Aren't HTML5

Sadly, we are at a point in time where people are implementing HTML5 the way they implemented HTML4 (as in, poorly). It's like we just invented the screwdriver but everyone is using it to pound nails.

More on the HTML5 Logo

There is so much buzz now and in the past week that it's hard to pick out only a few items to address. I still have an opinion on just about everything going on with the spec, W3C, WHATWG, additional specs, the "pundits," and many other things that could lead to endless ranty posts. But for now I am going to give some more detail on the logo "controversy."

I am physically air-quoting controversy because the logo itself isn't really the source of the issue, but the process and supporting documentation around it has caused a lot of discussion and a fight among at least a handful who have some say or influence on the specs themselves.

Tantek Çelik is a name most web developers will (or at least should) recognize, though if you don't I suggest you look him up. He wrote up a blog post citing how he, Jeremy Keith and Bruce Lawson were rather critical of the HTML5 logo FAQ from the W3C (let's forget that I may have scooped at least one of them, which just shows you how big I let me ego get) for claiming that the HTML5 logo represents more than just HTML5. While the W3C went ahead and fixed the FAQ based on the (rather valid) feedback from them and so very many others, Tantek still has more feedback for W3C. In particular he called out Offline & Storage, Device Access, Performance & Integration and The Movement. What is so much of a relief to many of us is to see that the W3C has made those changes today, showing that as an organization it is being responsive to the feedback from the people who are actually using and evangelizing HTML5. You can read Tantek's comments in detail at W3C Updates HTML5 Logo Messaging FAQ, Open To More Suggestions.

Doug Schepers had a hand in the new HTML5 logo and takes some time to address all the criticism that has been levied at the W3C as a result of the logo and accompanying language. The title of his post gives away his perspective before you need to dive in too far: HTML5 Logorrhea, or Use Your Inside Voice. He recounts some of the decision making process that went into developing the logo, which was surprisingly secretive for a body providing open standards. And then Jeremy Keith jumped in with comments, taking what was almost a plea for people to calm down and turning it into a well-mannered brawl. But a brawl that I think needed to happen for both sides to get all the items on the table. Of course, with a comment system you get other people tossing in their two cents (including someone who felt the logo and support icons are clearly based on military markings and far too violent a theme for a spec). In the end, the fight in the comments comes down to the process the W3C went through to generate the logo.

Given the W3C's attempts to abandon HTML for the semantically pure but practically infeasible XHTML2 specification, which demonstrated just how out of touch the working groups were with day-to-day web development and causing the formation of WHATWG, it's no surprise to see people recoil at the notion that the W3C is again doing some tinkering behind closed doors.

There has been plenty already said about the logo, some of which I am re-linking below, and there have been plenty of parodies, which I also link below. One thing is clear — the process and language around the logo have certainly generated far more interest and activity in HTML5 from those not involved in the W3C or authors on these topics than you could hope to get from a plain old press release.

Related Links

Logo/Process/Language Commentary

• HTML5 Gains Logo, Loses Meaning at Webmonkey.
• Two cheers for the W3C's HTML5 logo at HTML5 Doctor.
• W3C's new logo promotes HTML5--and more at cnet News.
• HTML5 Super Friends Assemble! at CSSquirrel.
• HTML5 logo: be proud, but don’t muddy the waters! at The Web Standards Project.
• W3C tackles HTML5 confusion with, um, more confusion at The Register.

Logo Variations (fun stuff)

• A collection of parodies of the HTML5 logo.
• The HTML4 logo, as envisioned at The Oatmeal and based on the shiny new HTML5 logo (scroll way down, and scroll further for the Cheetah version of the HTML5 logo).
• A lovely ironical (that's my word) Flash version of the HTML5 logo.
• The HTML5 logo using the canvas HTML5 element (best viewed in Chrome or Opera).
• The Tardis in the style of the HTML5 logo over at Reddit.
• The HTML5 logo as if it were a Netscape Now! badge.
• The HTML5 logo in H.264 video.

Chrome and Mozilla Announce Tracking Blockers

Last month Microsoft announced that Internet Explorer will be adding a "tracking protection" feature to its browser, allowing users to prevent advertising sites from tracking their activity on the web (ad targeting, really). This move was partly to stay ahead of an FTC push to mandate that browser makers add that feature. If you spent that few days between Christmas and New Year's hiding from computers and family, then perhaps you missed my post, Browsers to Add Tracking Blockers.

In that post I mentioned how Firefox had started the work, pulled it, and then brought it back. Well now it's official. You can read up on how it works at the Mozilla Wiki, where they were kind enough to put together a DoNotTrack FAQ. The FAQ helps readers understand that this is not the solution that will ultimately be implemented, since it relies on an HTTP header.

Google is relying on a cookie-based approach via a browser add-on. The only real difference from the voluntary Network Advertising Initiative that allows users to opt-out, which relies on cookies, is that the Chrome add-on won't blow away those cookies when a user clears all other cookies on his/her browser. You can read up on the confusingly-named Keep My Opt-Outs on one of the Google blogs (there are so darn many).

I suggest that if you plan on using these new features, which are not enabled by default and require some level of configuration to be useful, that you take a few minutes to read up on them:

• Mozilla, Google take different approaches to ad tracking opt-out at ars technica.
• Mozilla & Google Announce Browser "Do Not Track" Features at Mashable.
• Firefox and Chrome Add "Do Not Track" Tools To Their Browsers at ReadWriteWeb.
• Web Tool On Firefox To Deter Tracking at Wall Street Journal.
• Protecting Consumer Privacy in an Era of Rapid Change, preliminary FTC staff report (PDF).
• Self-Regulatory Program for Online Behavioral Advertising
• Network Advertising Initiative
• chrome-opt-out-extension at Google code blog.
• Keep My Opt-Outs from the Chrome web store.
• More Choice and Control Over Online Tracking from the personal blog of the Global Privacy and Public Policy Leader at Mozilla.
• Thoughts on Do-Not-Track from Michael Hanson, Mozilla Labs.

Updates

• Big browsers hop aboard the 'Do Not Track' train at New Scientist, Jan. 27, 2011.

W3C Clarifies HTML5 Logo Is for HTML Only

The W3C has rolled back its definition of what the new HTML5 logo represents:

This logo represents HTML5, the cornerstone for modern Web applications.

In case that isn't clear, which it might not be, the FAQ gets far more specific on the inclusion of CSS3 in the logo definition (emphasis added):

Is W3C saying that CSS3 is part of the HTML5 specification?
No. However, many HTML5 Web sites and applications do take advantage of CSS3 for styling and presentation.

If you saw my post on Tuesday, HTML5 Finally Gets... a Logo?, then you know that I and many others were frustrated at the further confusion the W3C introduced by declaring that the logo for a particular W3C specification actually includes a handful of other specifications. This needlessly confuses the definition for so many, and worse, muddies the waters on expectations between users, vendors, clients, customers, browser makers, developers, and so on.

The W3C heard the message and just a few hours ago posted an explanation and clarification:

The most unified criticism has centered around the FAQ's original statement that the logo means "a broad set of open web technologies", which some believe "muddies the waters" of the open web platform. Since the main logo was intended to represent HTML5, the cornerstone of modern Web applications, I have updated the FAQ to state this more clearly. I trust that the updated language better aligns with community expectations.

The release also addresses the concern that the logo is not yet official, mostly by clarifying the intent of the launch.

It's still relatively early and the news is still somewhat new, but already there have been blog posts grateful for the clarification, such as Jeremy Keith's post Clarity. He echoes what many of us feel, that the W3C version of HTML5 is a technical specification and not a collection of other specifications that may or may not be included in any project.

This news also means I have to go back and edit a post I was working on about the status of HTML5 as a buzzword and not a specification.