Gawker Learns the Hard Way Why ‘Hash-Bang’ URLs are Evil

URLs are an often overlooked part of web design, yet in many ways they may be the most important aspect of your website as Gawker’s family of sites recently discovered.
Gawker recently launched a multi-site redesign that, no sooner than being unleashed on the web, failed spectacularly, leading visitors to blank pages. The culprit was a […]

URLs are an often overlooked part of web design, yet in many ways they may be the most important aspect of your website as Gawker’s family of sites recently discovered.

Gawker recently launched a multi-site redesign that, no sooner than being unleashed on the web, failed spectacularly, leading visitors to blank pages. The culprit was a misbehaving piece of JavaScript, but when a single line of JavaScript causes your entire suite of sites to fail you no longer have websites, you have, well, nothing.

The problem with Gawker’s redesign is that it uses JavaScript to load everything. That means that, not only is there no chance for the site to degrade gracefully in browsers that don’t have JavaScript enabled, the smallest JavaScript typo can crash the entire website.

Developer Mike Davies has a nice breakdown of why Gawker’s JavaScript-based hash-bang URLs are a bad idea. Originally designed to allow Google’s spider to crawl Ajax content, hash-bang URLs have been popping up all over the web — Twitter and Facebook use them as well — but that doesn’t make them a good idea.

As Davies writes:

the #! URL syntax was especially geared for sites that got the fundamental web development best practices horribly wrong, and gave them a lifeline to getting their content seen by Googlebot.

And today, this emergency rescue package seems to be regarded as the One True Way of web development by engineers from Facebook, Twitter, and now Lifehacker.

The problem in Gawker’s case is that the URLs no longer point to actual content, everything depends on JavaScript parsing the hash-bang to retrieve the content. As Davies writes, “if content cannot be retrieved from a server given its URL, then that site is broken.” Think of hash-bang URLs as a worst practice of URL design.

If you’d prefer not to hang your site’s fate on the most brittle part of the open web stack — JavaScript — make sure you have a publishing system that allows you to design your own URLs and then follow the established best practices for creating good URLs.

If you’ve got Ajax content that would otherwise be missed by Google, then by all means use the hash-bang syntax, just keep in mind that the hash-bang is basically a hack, not the cornerstone of a well designed URL.

Eat at URLs photo by Scott Schiller/Flickr/CC.

See Also:

Meet HTML, The Spec Formerly Known as HTML5

It won’t be an unpronounceable symbol, but HTML5 is getting a Prince-style name change. From here on out HTML5 will simply be HTML — according to the WHATWG anyway.
Just a day after the W3C unveiled its new HTML5 logo, the Web Hypertext Application Technology Working Group (WHATWG) has announced that it will drop the term […]

It won’t be an unpronounceable symbol, but HTML5 is getting a Prince-style name change. From here on out HTML5 will simply be HTML — according to the WHATWG anyway.

Just a day after the W3C unveiled its new HTML5 logo, the Web Hypertext Application Technology Working Group (WHATWG) has announced that it will drop the term “HTML5,” stop the versioning of HTML altogether and instead treat the evolving specification as a “living standard.”

While eliminating the version number from HTML has been part of the WHATWG’s plan from the beginning, the timing of the change is clearly related to the W3C’s attempt to embrace the term “HTML5.” The W3C recently showed off a new HTML5 logo, but the accompanying FAQ used the term HTML5 to cover everything from the actual spec to only tangentially related tools like CSS 3, WOFF and SVG. Many developers saw the W3C’s nebulous use of the term HTML5 as a sign that the term had become, like “AJAX,” just another marketing buzzword.

The W3C has since rewritten its FAQ to clarify and more sharply define just what HTML5 is and is not, but before that happened Ian Hickson, the WHATWG’s editor, announced that the WHATWG was renaming its spec to just HTML. Hickson says the WHATWG was “going to change the name last year but ended up deciding to wait a bit since people still used the term ‘HTML5′ a lot.”

Hickson then makes a not-so-subtle jab at the W3C, saying HTML5 “is now basically being used to mean anything Web-standards-related, so it’s time to move on!”

The W3C has long had a tenuous relationship with the WHATWG. Technically the W3C is the standards body charged with publishing the HTML spec. The WHATWG — a consortium of browser makers — grew out of the W3C’s neglect of HTML and its misguided decision to pursue XHTML 2. Now that both groups are working on the same spec, in theory, their goals are the same. In practice, however, the two groups often butt heads. In other words, just because the WHATWG has decided to abandon the term HTML5, don’t expect it to disappear overnight.

The W3C will continue to work toward “snapshots” that reflect stable milestones of the ever-changing WHATWG version of the spec. For now at least, that means the term HTML5 will be alive and well at the W3C, as the group works through its standard practice of issuing working drafts, holding last calls on changes and finally publishing the spec as a “recommendation.”

Since browser makers have long been well ahead of the W3C when it comes to implementing the latest and greatest parts of the HTML5 spec, they will likely focus on the WHATWG’s HTML spec, which will, like Google’s Chrome browser, follow a “rolling release” schedule.

No doubt the media and marketers will continue to use HTML5 as a buzzword that means far more than just the spec, but even that’s not always a bad thing. There’s no doubt that Apple, Google, the New York Times and everyone else who’s used HTML5 as an analog for the New Shiny has helped HTML5 — and all the other tools it’s come to stand for — gain momentum. As web developer Jeff Croft puts it, “sometimes we just need a word to rally behind.”

While not everyone understands the nuances of what’s HTML5, what’s CSS 3 and what’s just JavaScript, that doesn’t change the fact that everyone is excited about building a better web and that is exactly what HTML(5) is designed to do.

See Also:

HTML5 Gains Logo, Loses Meaning

What’s that thing flailing awkwardly over the mouth of a mechanical shark? Why that’s HTML5 in its dashing new logo. Yes, the W3C, the standards body that oversees the development of the HTML5 spec, has blessed HTML5 with a snazzy new logo.
Naturally there are badges you can add to your site and t-shirts and […]

The W3C’s new HTML5 logo

What’s that thing flailing awkwardly over the mouth of a mechanical shark? Why that’s HTML5 in its dashing new logo. Yes, the W3C, the standards body that oversees the development of the HTML5 spec, has blessed HTML5 with a snazzy new logo.

Naturally there are badges you can add to your site and t-shirts and stickers are already on sale (a portion of the proceeds go to the development of the W3C’s HTML5 Test Suite). The only thing left to do is figure out what “HTML5″ actually means, and that’s where the W3C has has thrown “HTML5″ over the shark.

HTML5 already enjoys more buzz that a web developer left alone in the back of a Mountain Dew truck (it even has it’s own posse), the only problem is that the buzz makers conflate just about every emerging web technology under the HTML5 umbrella. Purists have long decried headlines proclaiming the glory of HTML5 above an article about JavaScript and CSS 3, but now the one group that ought to know best appears to throwing in the towel and embracing the HTML5 hype.

While the new HTML5 logo looks good, the FAQ that accompanies it is troubling. According to the W3C, the logo is “a general-purpose visual identity for a broad set of open web technologies, including HTML5, CSS, SVG, WOFF, and others.”

It doesn’t really matter if the New York Times thinks CSS 3 or SVG are HTML5, but we’d like to think that at least the organization in charge of describing what is, and is not, HTML5 would make some effort to distinguish between tools. Lumping everything together is as silly as a carpenter referring to every tool in their toolkit as “a hammer.”

As web developer Jeremy Keith quips, “the term HTML5 has, with the support of the W3C, been pushed into the linguistic sewer of buzzwordland.” We had high hopes that Bruce Lawson’s acronym NEWT — New Exciting Web Technologies — would catch on and save HTML5 from buzzwordland, but alas, that appears unlikely.

With the blessing of those who oversee it, HTML5 now apparently means just about anything new and cool on the web. The new HTML5 logo is pretty sharp and the t-shirts look nice, but if we can’t have precise terms and linguistic clarity could we at least get a unitard with belt and cape?

See Also:

Styling Webpages With ARIA’s ‘Landmark Roles’

We’ve covered how you can make your webapps more accessible using WAI-ARIA — the W3C’s emerging specification for Accessible Rich Internet Applications — but did you know ARIA can also help style your pages?
Web developer Jeremy Keith recently took a look at how ARIA’s “landmark roles” can be used, not only to make your […]

We’ve covered how you can make your webapps more accessible using WAI-ARIA — the W3C’s emerging specification for Accessible Rich Internet Applications — but did you know ARIA can also help style your pages?

Web developer Jeremy Keith recently took a look at how ARIA’s “landmark roles” can be used, not only to make your pages more accessible, but for styling purposes as well. Consider HTML5’s header and footer tags. The average page has a main header and footer and then may also use the same tags within an article tag, for example, to wrap a headline, dateline and other auxiliary information.

So how do you target just the main header and footer tags without also styling the inner tags? Well, you could drop some IDs in your page, something like <header id="main">. But ideally the ID attribute is not simply a styling hook to be thrown around at the designer’s whim.

Keith points out a better way: using ARIA’s landmark roles. To stick with the same example, you could write something like this:

<header role="banner">
    ...header code here
</header>

Now you can target that specific header tag with CSS’s attribute selector:

header[role="banner"] {
    your styles here
}

Not only have you avoided the plague of otherwise meaningless ID attributes, you get the accessibility benefits too — ARIA roles are supported in JAWS, NVDA and Voiceover. It’s a win-win solution: more accessible code with styling hooks built in.

Be sure to read through Keith’s post for some landmark role examples. Also see our early post on building a more accessible web with WAI-ARIA, and of course, read through the WAI-ARIA role spec, which has more examples and guidelines for when and where to use them.

Italian Masks photo by Peter Lee/Flickr/CC

See Also:

Google Dropping H.264 Codec from Chrome Browser [Updated]

Google has rather nonchalantly dropped a bombshell on the web — future versions of the Chrome browser will no longer support the popular H.264 video codec. Instead Google is throwing its hat in with Firefox and Opera, choosing to support the open, royalty-free WebM codec.
Google says the move is meant to “enable open innovation” on […]

Google has rather nonchalantly dropped a bombshell on the web — future versions of the Chrome browser will no longer support the popular H.264 video codec. Instead Google is throwing its hat in with Firefox and Opera, choosing to support the open, royalty-free WebM codec.

Google says the move is meant to “enable open innovation” on the web by ensuring that web video remains royalty-free. While H.264 is widely supported and free for consumers, sites encoding videos — like YouTube — must pay licensing fees to the MPEG Licensing Association, which holds patents on AVC/H.264

Prior to Google’s announcement, the web video codec battle was evenly split — Firefox and Opera supported the open Ogg and WebM codecs, while Safari and Internet Explorer supported H.264. Google took the egalitarian path and supported all three codecs.

Google’s move away from H.264 makes sense given that Google is already heavily invested in WebM. In fact, the only reason the WebM codec exists is because Google purchased On2, the creators of the VP8 codec. Once Google acquired the underlying code it turned around and released VP8 as the open source WebM project.

There’s been considerable outcry from developers concerned that they now need to support two video codecs to get HTML5 video working on their sites. However, given that Firefox — which has a significantly greater market share than Google’s Chrome browser — was never planning to support the H.264 codec, developers were always going to need to support both codes for their sites to work across browsers.

Google’s decision to drop H.264 from Chrome does raise some questions though. For instance, Android also ships with H.264 and so far Google hasn’t made any announcement regarding the future of H.264 on the Android platform. One of the reasons H.264 has become so popular is that the codec enjoys robust hardware support across devices — whether it’s desktop PCs, mobile devices or set top boxes. While WebM has made some strides in hardware acceleration since it was originally released, it still lags well behind H.264. At least for now it seems that Android most likely needs to continue supporting H.264.

The move also raises questions about YouTube, still the largest video site on the web. Currently the site serves H.264 videos to most browsers, whether through the HTML5 version of the site or using the Flash Player. It seems obvious that Google must be hard at work converting the site to use WebM, but will it continue to support H.264 for those browsers and devices that don’t support the WebM codec? So far Google hasn’t made any announcements regarding YouTube and H.264.

Critics of Google’s decision to drop H.264 support in Chrome point out that Chrome ships with Flash, which, like H.264, is not really an open web technology. Indeed it would seem hypocritical for Google to dump some closed tools while keeping others, but, in Chrome’s defense, Flash is well entrenched in the web and ditching it really isn’t practical. Rather Google’s decision seems to be pragmatic — the company is in a position to take a stand on video codecs and it is doing so before H.264 becomes as entrenched as Flash.

[Google did not respond to a request for comment on this article. A Google Spokesperson tells Webmonkey that the announcement is related to “Chrome only and does not affect Android or YouTube.” Presumably both will continue to offer H.264 support. As for Flash, the Spokeperson says, the Chrome announcement “is about the importance we place on open technologies being the foundation of the emerging web platform moving forward.” In other words, dropping Flash support isn’t practical.]

See Also: