Before I go into the main content of this post, I just want to say that Bruce Lawson has done a fantastic job of promoting HTML5 education both online and in print. I haven’t had a chance to get a copy of his and Remy Sharp’s book Introducing HTML5 but it is on my definite to-read list.
But sometimes it seems that HTML5 evangelists can get a little bit carried away in their zeal for promoting these new technologies and features, and they inadvertently end up misusing terms.
In my opinion, Bruce does this in Issue #204 of .net magazine, in the recently-revamped “gallery” section that now includes HTML5 websites.
While writing about Yell.com, Bruce says the following:
See those hints inside the form fields? Those use the placeholder attribute that’s available in HTML5 forms. In browsers that don’t support placeholder yet, the developers provide JavaScript to fake that behaviour — a perfect example of how HTML5 forms are designed for graceful degradation.
I understand what Bruce is saying here. What the Yell.com developers have done is best practice; I agree with it wholeheartedly, and I encourage all developers to do this in their projects to provide a similar experience for non-supporting browsers. But I’m afraid that’s using the term “graceful degradation” very loosely. That’s not graceful degradation; that’s code forking. There is no “degrading” here, instead we have something more like an if-else construct.
Definitions
“Graceful degradation” is defined on Wikipedia in part as:
[T]he property that enables a system (often computer-based) to continue operating properly in the event of the failure of (or one or more faults within) some of its components.
And Peter-Paul Koch explains it in straightforward terms in this old post:
Graceful degradation means that your Web site continues to operate even when viewed with less-than-optimal software in which advanced effects don’t work (no CSS in Netscape 3, no images in speech browsers). Add whatever special effects you like, just make sure the site is usable without them.
Koch goes on to explain that graceful degradation should have two basic rules:
- Any browser must be able to view the content of the site
- Any browser must be able to navigate the site
The placeholder text in the example discussed by Bruce on Yell.com is not necessary for the proper functioning of the site. So when JavaScript is used to mimic HTML5’s placeholder attribute, this is a form of code forking — the kind of thing some of us did back in the days of the Netscape-IE browser wars.
In both cases, it’s bad code. But in this instance, it’s preferred, because it’s a way to transition your projects from XHTML/HTML4 to HTML5. It’s pretty much the only way to do this cleanly while providing a near-exact experience in all browsers. But again, this is not graceful degradation. I think it should more accurately be called a JavaScript-based fall-back, because there isn’t really anything “graceful” about an HTML attribute that uses JavaScript as its fall-back.
In Some Cases, HTML5 Falls Back Gracefully
In certain cases, it certainly is “graceful” the way HTML5-features fall back to support older browsers. For example, if you use the new “email” form input type, the “email” type will be ignored in non-supporting user agents, and the input will degrade gracefully to a regular text input. That’s graceful. Using JavaScript to hack something into recognition is not.
Again, I’m not saying we shouldn’t do this. We absolutely should do it, but we can’t honestly call this graceful degradation, otherwise we’re just fooling ourselves.
I’m Just Saying…
I love what guys like Bruce are doing, and I will continue to promote his work wherever possible, but I just thought I would state my beef on this issue. We should not fool ourselves into thinking that providing these kinds of fall-back options are optimal in any way.
They are only optimal because of the transition period we find ourselves in — a period requiring that we support browsers with tons of HTML5 support as well as browsers with very little HTML5 support. Kind of like the difference between IE and Netscape back in the day — which is why code-forking was even necessary.
“I’m afraid that’s using the term “graceful degradation” very loosely. That’s not graceful degradation; that’s code forking. There is no “degrading” here, instead we have something more like an if-else construct.”
The term I should’ve used (especially as Remy uses it in our book) is “Polyfilling”.
But I might be right. After all, in pre-HTML5 browsers, no-one gets placeholder text without JS. Using the placeholder atrtibute means that those pre-HTML5 browsers still get no placeholder text. So their experience isn’t worse.
You can give everyone JS, and that plugs the holes in older browsers, and over-rides the default behaviour in browsers that do understand placeholder. So, everyone gets the same and no-one gets worse. But why over-ride a desired behaviour in Opera 11 and webkit browsers? Instead, we use feature detection to check whether placeholder is natively suppoorted: return ‘placeholder’ in document.createElement(‘input’); and if it is, the script ends leaving the browser to deal natively.
Code forking? In the loosest sense.
I think you’re right: “Graceful degradation” might be too generous a term, and “code forking” might be too cruel. “Polyfilling” is certainly more accurate.
But I tend to almost think “polyfilling” is just code forking on efficiency-steroids (if that makes any sense!).
Thanks for the feedback.
My question is: does calling it graceful degradation rather than code forking make any practical difference?
I suspect not, as what we are really addressing here is the thoughtful application of newer features, which are either not essential to the user, or desirable enough that the developers see the need to code a js replacement for the feature in unsupported browsers.
Either way, it seems the only people who would refer to it are thoughtful developers, and its the thoughtfulness that matters.
I guess my concern is what developers associate with “graceful” coding techniques. I think we need to admit that this is not an optimal way to code, and should only be done when absolutely necessary (which is true in the case of certain HTML5 features).
To me, falling back the placeholder attribute to JavaScript is the same as serving IE-only stylesheets using conditional comments. The latter is not considered graceful, so why is the former?
And again I emphasize that we’re in a period where this sort of thing is necessary and desirable in order to make the transition to HTML5. But that’s not a good thing; it’s more like a growing pain. We just need to have a clear distinction of what is good code and what is bad, that’s all. Necessary code doesn’t always equate to good code, and in this case necessity (at best) produces mediocre code.
“And again I emphasize that we’re in a period where this sort of thing is necessary and desirable in order to make the transition to HTML5. But that’s not a good thing; it’s more like a growing pain”
Yup, wise words. So I’ll probably steal them….
Joke. Thanks for the discussion. Now buy the damn book!
Heck, steal them — I’d be honored!
Yeah, I’ll get the book, probably in the next few weeks. That and Hardboiled Web Design are next on my list, and maybe CSS3 for Web Designers.
Maybe it’s the (small but important) confusion between graceful degradation, where you ‘build for the latest and greatest, then add handlers for less capable devices’ [http://accessites.org/site/2007/02/graceful-degradation-progressive-enhancement/] and progressive enhancement, where you build for the lowest spec, then build on that codebase with features newer spec devices and browsers have to enhance the experience but not loosing sight of the most important part, the content itself.
Adding a script, like the html5shim or one for placeholder text, is graceful degradation as it uses features of the most capable devices and then fills in the gaps for those without (to an extent).
Progressive enhancement would be to use placeholder text and show nothing to devices that don’t have the feature. As the HTML5 spec says, it’s just ‘a short hint (a word or short phrase) intended to aid the user with data entry’, and shouldn’t be crucial to the input field – that’s what the label or title attribute is for.
I think the issue here is that everyone is trying to put best spin on an out of control situation. We talk about web standards, but to be brutal they don’t exist in the same way as when we use the term standards elsewhere. And even if something is technically accurate it means nothing when looking at visual design and communication. When I produce a site my first duty should be to satisfy the audience who ever that is. This often conflicts with the needs of a business. So for me its a win if my work is consistent across platforms, makes my client happy and makes the primary audience for the website happy. To go beyond this to satisfy a particular web standard is crazy and un-economical. But with regards to the article above, while I agree its not graceful degradation, the outcome is one that’s superior, because they are coding to the best outcome possible on each platform…
very technical post,not for me :(
I agree with you. It isn’t necessarily “degrading” but rather replacing. If only in a perfect world, all browsers would update to support HTML5. To the time machine!
“But sometimes it seems that HTML5 evangelists can get a little bit carried away in their zeal for promoting these new technologies and features”
I thought this was very funny and accurate. HTML5 evangelists.. :)
That’s true today as it was when Louis made this article in Dec 2010.