Home >
One of my readers sent in the following email, and as I definitely do not have the best answer, I thought it would be a great item to discuss here. I'll begin with his question:
This code is setup to support both JavaScript enabled and disabled browsers. If you run the page with JavaScript disabled, a click on Load Child 1 will simply fetch test_child1.html. If you have JavaScript enabled however, something interesting happens. We have taken over the link and told jQuery to load the same file as before, but by specifying #content, we will only display the text we care about. The layout, header, footer, whatever is fetched, but not displayed.
So as a practical example, this was not a lot of additional work. It requires planning ahead of time (within test_child1.html I want to ensure I properly wrap the content that i want displayed via Ajax), but I wouldn't necessarily consider it twice the work.
Now, the counter example to this is form validation. I absolutely love doing form validation in jQuery (the Validation plugin is incredible), but this is a case where effort must be duplicated. You can't trust the client to 100% validate a form. If you do, you're leaving your site open to potential attacks and hacks. At the least the validation is simpler client side, so I can normally do the client side validation in perhaps 5 minutes, while the server side adds another 10 minutes. But it definitely requires more work.
Following up on this though - as much as I recognize the value of progressive enhancement, I haven't always follow it. A good example would be my LighthousePro bug tracker (http://lighthousepro.riaforge.org) (forgive the plug!). This is a simple bug tracking application that makes use of jQuery. Issues are displayed in a table that has pagination, sorting, and search features. While it is possible to do this in a way that would work with JavaScript disabled, I felt that as an application, my audience was more limited and therefore it made sense to assume JavaScript was enabled. (I even document it too... I think.) So my decision here was based on certain assumptions of my users. I haven't had any feedback concerning that decision, but maybe I'm losing potential customers because of it?
Folks, I'm really looking for comments here. As I've said (probably too much), I still feel very new to the RIA world. While the technology aspect is growing on me, issues like this are definitely something I'm struggling with, and I assume (hope!) I'm not alone.
I was wondering, if you have not already, would you be willing to blog on some of the other aspects of "Web 2.0" type solutions, namely when NOT to use them, how you decide whether to account for users disabling JavaScript, and the like. Maybe I have spent far too much time in the government contracting arena, where everything must work for every browser under every condition or risk the agency being sued, but while there certainly is so much I could do using jQuery and AJAX (both ColdFusion 8's implementations and jQuery), I struggle with how much concern to pay to those that have JavaScript disabled when doing so when I do my own side work. There may be some cases where its not that big a deal to make it work both ways, but in my growing myself as a developer in these areas, I find many things that would need to be built twice, once for JavaScript and once for not, just to cover all the bases. I wonder if, in the "real world", decisions to not support those having JavaScript disabled are easier to make and have fewer ramifications.This is a huge topic, but I think we can maybe break it down into a few areas of discussion. First off, as the "web guy", a lot of times the question is out of our hands. The client will just say what is and what is not allowed. That can definitely make life easier (except when they ask you to support IE6 of course). I can think of one client in particular. I've worked with this client for maybe 8 years now. In the beginning, they were very concerned about supporting every browser/OS out there, and also very concerned with ensuring only those browsers were allowed into the site. We actually spent quite a bit of time setting up Browserhawk to do detection and processing of incoming visitors. You were either allowed in, blocked, or sent to a warning page. I really felt like that was overkill, but I wasn't the one making the decision. Secondly, it is important not to think of JS/Ajax as an "either/or" decision. Certainly a JavaScript-based feature is only going to work with JavaScript turned on, but the site functionality you build doesn't necessarily need to stop working when the browser blocks script execution. Most JavaScript frameworks (like my favorite, jQuery) allow for "progressive enhancement". This is a fancy way of saying that the JavaScript improves the experience, but is not the only experience. Consider a simple of using jQuery to load content onto a page:
<html>
<head>
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js"></script>
<script>
$(document).ready(function() {
$("#thelink").click(function() {
$("#content").load('test_child1.html #content')
return false
})
})
</script>
</head>
<body>
<p>
<a href="test_child1.html" id="thelink">Load Child 1</a>
</p>
<div id="content"></div>
Tag Cloud
Podcasts & Screencasts
@InsideRIA on Twitter
Follow InsideRIA on Twitter
Facebook Application Development
People who disable Javascript are old school techies who believe a website should not require Javascript in order to function, or they are paranoid security conscious people. They must have encountered loads of websites that don't fully or partially work before they arrive at your website, so why should they expect their experience to be any different?
It's like ripping the electrics out of a car. It may still drive but don't expect the ABS, air bags, sat nav, radio, trip computer, etc to work.
I still support IE6 when I develop new sites. Why? Because IE6 users account for up to 20% of browsers being used. That's a massive number of visitors to turn your back on. If your client or potential visitors are government or big corporates then that figure probably rises to at least 50%.
jQuery is fairly IE6 compatible and if your preferred method to get something working fails on IE6 there are other ways to skin a cat. One of my big sites still supports IE5.5. (Really! But I will stop that soon.) Where I haven't found a workaround for IE5.5 I simply ensure it fails gracefully without throwing errors, or politely prevents a user from doing something that requires IE6+.
As a web developer I see compatibility as a challenge, it's part of the job. We had it in the days of Mozaic/Netscape, then Netscape 3 vs IE3, and it's no different now.
Good post Ray,
I'd say there are pretty few instances though where an app really doesn't make sense without JS (drawing tools perhaps?). In almost any case, it's just the proper way to build for the web. It's not just about older browsers - plenty of new mobiles will give you a similarly broken experience to the browsers we'd like to believe are now off our radar. Making things functional without JS has benefits beyond user-accessibility too - I think it's a heck of a lot easier to maintain code that's written that way (both on the front-end and back).
But once your app is built in that way, it's very important to make sure users are getting either one experience or the other (and not a broken mashup in between the two, which happens quite frequently). We've found that by using a feature detection script, you can make a really clean divide between those who should or should not be given the JS-oriented enhancements. By conditionalizing your scripting and CSS based on a pass/fail feature test result, you can ensure a site will be usable to most any device that hits it, and it's a cinch to add such a script to a workflow. There are benefits to this beyond user access too, such as conditionally loading styles and scripts to those who need them (big performance plus).
Anyway, that's my take: safe progressive enhancements made through capabilities testing. Here's a related presentation video/slides: http://bitly.com/mwfg7
Um, Gary, sorry. I work at the SEI and our sisters are CERT, Q-CERT and US-CERT, the latter of which is part of Homeland Security. While JS and Java applets are used in some very highly monitored custom and COTS apps, our intranet business applications cannot utilize JS if it means core functionality relies upon it. And we have a large number of very high volume internal and external custom business/financial applications which do very well, thank you, performance wise and in end user endorsement and regard.
Not meant to be a flame, but if you believe that disabling JS is "old school", perhaps you might consider business considerations outside of what you think is "new school" capable. I have no problem with JS, personally, outside of concerns about the ability of developers to _really_ support it, but delivering a blanket statement that the users and businesses whose decisions require disablement of JS is to be considered the realm of "paranoid security conscious people" just indicates a small non-peripheral vision of reality. Use of JS to provide functionality that improves user efficiency is not my counter-statement; it is your statement that the use of JS is justified in all environments, regardless of situation or need. Security trumps efficiency every time if both cannot co-exist at the same time. If your bank utilizes AJAX in it's online applications for data communications with the server, I would certainly hope that you have at least *some* concern about the data security concerns that JS reliance incurs...not to mention whether or not that bank's IT department is truly certified in (and capable of) AJAX injection prevention and network monitoring. SSL alone does not make it secure.
Again, not meant to be a flame, per se. Just not too happy with a blanket statement about "old school", I guess. JS is a tool like any other, and a good worker uses the correct tools for the job needs required, and to the customer's requirements.
I think that there are too many developers that don't think about accessibility when coding JS. I've often seen things like attaching click events to divs when they could have been attached to anchor tags. That makes it so that people who rely on keyboard navigation can't tab to the element to click on it. Support for keyboard navigation is necessary for some people with assistive technology or mobile browsers.
one trick I always use is:
document.getElementsByTagName('head')[0].className = 'js';
This allows me to write css specially designed for JS enabled browsers.
.js body {background:red;}
body {background:green;}
I mean:
document.getElementsByTagName('html')[0].className
not head :$
@Tom - I believe you're being a bit too harsh on Gary for his statement. In his worldview that probably does not include government regulations he is perhaps correct. Turning javascript off is an odd thing for most people to do. And most people in the wild that turn it off tend to be old school or paranoid about security. Which, by the way, most of those that turn it off for security paranoia do so in an attempt to protect their local machine from the servers they visit. It has nothing to do with the security of the server itself which is what your example addresses.
Yes, it is an excellent example of when not supporting javascript in your project is a requirement but it is a very specific case. Your example is an internal application on a specific intranet that has severe government regulations on it for security reasons. Probably very valid security reasons but they are probably severe enough to be considered "paranoid". I'm not saying that's a bad thing but it is what it is.
I don't think what Gary was speaking of fits within the bubble of your example. He was describing everyday run-of-the-mill websites and I would think most people knew what he was talking about. You were really close to insulting him based on his opinion that is slightly different than yours even though they were on two totally different topics. As I said, what he referenced was security paranoia on the client side while you are discussing security on the server side.
As for your bank example, yes I would worry over it but I would be more worried over the whole of their security and not focus on one facet of it because of javascript. But I'm sure you think the same.
Another consideration is team size and makeup. I work for a company where all of the developers are remote. The senior developers are fairly stable and to a certain extent know each other, but we have no way to control who will maintain the code after we initially write it. The junior developers come and go and have pretty uneven skill sets--some only know ASP, some know ASP and some js, some know a bit of CSS, etc. So we tend to try to avoid techniques that might require special knowledge. If I think the technique is beneficial enough, I'll use it anyway and comment, comment, comment.
I have a question that hopefully some accessibility experts can answer:
Suppose your audience is comprised mostly of much older people, those who are not as savvy with internet technology, but need larger font size, easier navigation, etc.
Is it safe to assume that, if they arent particularly savvy with their browser, they wouldnt ever turn off Javascript, because they wouldnt know how to in the first place?
Im not coming down on our older generation (they came up with the fundamentals of computing that give us the internet today)
but my point is, can we safely assume Javascript is a key technology to use with older audiences, since they would never turn it off?
(Maybe I am just underestimating Grandpa Joe's ability to navigate the online world and catch on :] )
thanks for any advice