You cannot rely on JavaScript being available. Period.

I have a question for people who label themselves as JavaScript developers: Have you forgotten about, never heard of, or never cared about the terms progressive enhancement, graceful degradation, and Hijax? If the answer is yes, then please tell me why.

I would also like to know whether you actually consider disregarding those best practice methods to be compatible with modern, responsible, and professional JavaScripting.

The reason I’m asking this is that I have recently read no less than three articles in which WaSP member Ian Lloyd describes the problems he has been having with certain online services (Blogger, Bloglines, and Ma.gnolia). All three services use JavaScript in ways that make them fail, without warning or explanation, when scripting is disabled or blocked by firewalls.

Blogger

Ian posted the first article, Blogger - Can I get in please?, after realising that he could not log in to his Blogger account from his place of work. The reason? The firewall at his office (and no doubt in many other offices across the world) is configured to block suspicious JavaScript.

On Blogger’s home page (looks like they’ve been doing some tweaking on their own since Doug Bowman helped them redesign a couple of years ago) there is a script that writes the login form to the page. If scripting is not available, a fallback is provided in a noscript element. Not exactly elegant, but it does work if JavaScript is fully disabled. In Ian’s case JavaScript is enabled but parts of it is blocked, making both the script and the fallback fail.

The lesson to be learned is to put submit buttons in the actual markup that all browsers receive, not in a noscript element (which is a sign of outdated development methods anyway).

Bloglines

The second service to break down was Bloglines. Ian notes the problems he encountered in Bloglines Is Broken (for me, at least).

The reason is apparently that Bloglines started using one of those very popular, <irony>absolutely fantastic and time saving</irony> JavaScript frameworks. That framework happens to trigger a security setting in the firewall at Ian’s office. Troubleshooting that should be pretty easy if the developers had known the code they use, but having decided to rely on a script library written by someone else they seem to have a bit of trouble figuring out exactly what is causing the problem.

The lesson to be learned here is that if you start using JavaScript frameworks you should be prepared to spend lots of time enterpreting and learning to understand the code someone else wrote when you run into trouble.

Ma.gnolia

Next up is Ma.gnolia, a service which in Ian’s words (and I agree) is Using a sledgehammer to crack a nut.

What it comes down to is the submit “button” in Ma.gnolia’s login form requiring JavaScript. I simply cannot understand why anyone would make a submit button require JavaScript, especially without providing any visible fallback or information for people browsing with JavaScript off. Looking at the code they use I can only shake my head and wonder what they were thinking. Yes, it works if JS is off and you hit enter. But how is the user supposed to know that? The button is still there, begging you to click it, but nothing happens when you do.

If I may make a suggestion, here’s the approach I would use if a visual designer pointed a gun at my head, threatening to pull the trigger unless I get rid that default, horribly ugly, and user-recognisable button:

  1. Put a normal, honest, bullet proof, works-everywhere submit button in the markup.
  2. Do not use CSS to hide it.
  3. If JS is available, hide or remove it and insert the fancy-schmancy styled link instead.

Done. Progressive enhancement (if you can call that enhancement) instead of dis-graceful degradation.

How many others are making similar mistakes?

It’s very disturbing to see this trend of not giving any (or enough) thought to what will happen when a browser doesn’t support the technologies you want to use. It’s even more disturbing to see the JavaScript framework craze sweeping through the developer community make people use JavaScript for all sorts of things that are better done without it.

JavaScript frameworks seem to have a lot in common with the DHTML libraries of the late nineties - start using them and common sense goes out the window unless you have the experience to use them right. I admit that I too went overboard with scripting around the turn of the century. But I think I learned my lesson. I really hope I did.

Before you start accusing me of being anti-JavaScript, let me assure you that I am nothing of the kind. JavaScript used right is a great tool which I find myself using more and more. The key is to use it responsibly and always in the spirit of progressive enhancement or Hijax.

I thought we were over the reckless scripting practices of the 20th century. Apparently I was wrong.

Posted on December 4, 2006 in Accessibility, JavaScript

Comments

  1. I think a big cause of most of these issues cropping up around the web is that with the rise of AJAX, Web Designer positions seem to be requiring Java/DOM scripting on top of XHTMl and CSS. XHTML and CSS I can understand and fully support (how do you paint a picture without a brush?), but Java/DOM scripting should be left to people that know what they’re doing.

    The Web Designer is left with no choice but to rely on these libraries, and the result is a bunch of garbage.

  2. I have been using Java at school for quite some time now, and we were learning about JSF and the horror that met my eye was that a simple link in JSF is an anchor with inline javascript.

    You can avoid this, but alot of funcunality is lost. I cant see how sun can create a framework that is unusable without javascript activated.

    The comment I got back is that most browsers hava javascript now…

    About javascript frameworks, I think its good in the sence thats they are often well proven and tested. So it wont only work in IE and Firefox

  3. Things aren’t helped by ASP.NET - most of its “cool” controls will still appear in the page but stop working if JavaScript is disabled, yet the majority of people stitching sites together using Visual Studio.NET wouldn’t be able to tell you which controls are dependent on JS and which aren’t.

    Typical of this is the extranet login for a company I have dealings with: I type in my username and password, but it doesn’t submit correctly when I hit enter while the focus is in a text field; it relies on something being done in the submit button’s onclick handler. I very much doubt that the developer responsible even understands that onclick is not the same thing as onsubmit, having just dragged-and-dropped the button without any knowledge of how it works.

    I’ve yet to see an ASP.NET site with any degree of interactivity (beyond basic links) which works properly if at all when JS is disabled. (Well, except the one I did, of course ;-)

  4. Replace “javascript” with “flash”, now ask that question again :) The answer will probably be: “because it’s there”.

  5. Have you seen the new Yahoo TV Listings page? It’s completely unusable. I’ve tried it in many different browsers. It’s got some much flashy AJAX making it extremely slow. People have been bashing their bragging blog posting about the new version for a few days now with negative comments: Yahoo TV.

  6. Agreed. Things seem to be getting more and more overboard each day. There are of course some advanced web applications that are in title to demand JavaScript for complete functionality, but then they should of course offer some fallback to people who don’t have (the necessary) JavaScript support.

    If I may make a suggestion, here’s the approach I would use if a visual designer pointed a gun at my head…

    Eh… How about just [input type=”image”] instead of your suggestions? :-)

  7. Ok… Your preview “promised” that my code would get through. :-)

    What I meant to suggest instead was just an input type=”image”

  8. Along the lines of the classic IE argument. If you expect to satisfy 95% of your potential user with your setup, then you focus on making it work and deal with the remaining 5% later.

    On my new site I can make it work in a degraded version, but I plan to ignore that option for the first couple of months at least.

    If you are trying to make a technically advanced site you have to cut some corners to get a decent time to market. So as long as you plan to support degraded operation I think it’s resonable.

    Given the sites you mention I guess many of them don’t really intend to do that though.

  9. The idea of firewalls blocking certain parts of my code, but not others, is not something I had considered before. It’s good to keep this in mind when you write the code that should really only run if all JavaScript is there.

    That said, I disagree with Robert that applications should provide a fallback. In many cases a fallback makes no sense, or is way too much work. The To-Do List application I did for JotSpot last summer comes to mind here. Sure – assuming the rest of the Jot suite had fallback – I could have provided the list in pure HTML, with a lot of buttons and links to manipulate the list, but it’s just not worth the time (and therefore money).

  10. sebastian: Unfortunately several major players make outdated technology. JSF stinks in more ways than one.

  11. I think the accessibility problem largely has to do with the difference between designers and developers. Designers really get into the best method to solve interface problems where developers are more interested in how to solve back end problems.

    When a developer solves a front end problem, they make different assumptions than designers make. That is, they assume that scripting is needed, since that is the language they speak. I have to fight tooth-and-nail sometimes to get accessible solutions implemented where I work, and I have to constantly remind developers that they need to assume JavaScript doesn’t exist.

    Further, some people still don’t think in terms of accessibility. If it works for them, it works.

    None of it is a good excuse. This is why I fully disagree when I hear people say that now-a-days designers don’t need to be a jack of all trades. It is imperative, in my opinion, that good designers know HTML, CSS, JS, and at least one server side scripting language. You can’t rely on all the pieces coming together by magic. Someone has to be able to control the parts that need to lock together. I think the designers are the best suited for that sort of creative thinking.

  12. December 4, 2006 by Roger Johansson (Author comment)

    Robert:

    What I meant to suggest instead was just an input type=”image”

    Because that will prevent the user from increasing text size.

  13. I made the decision to require javascript early on in the development of my latest application. My philosophy is that the three domains, Structure, Design, and Action (HTML, CSS, JS) are all important and that any platform that does not sufficiently support any one of them is, in a way, broken.

    Now I’m not saying it was an easy decision. The above is rather idealistic and simplistic, I admit. I had a hard look at the functionality I needed to accomplish, and much of it is entirely impossible without javascript. Also, the audience is focused enough to allow me to estimate the importance of adding fallback functionality. My case should not be the default case, but it is the right one for me.

    It’s just not important enough to add fallback. In the time it takes to build a fallback that will be appreciated by 1% of users I could be developing new functionality that will be appreciated by the other 99% of users.

  14. I have heard this song before…

    I am kinda iffy on this matter, since what I would want to do and what I have time to do - that is infact two completely different tunes. What our clients would want to have, and what they are willing to pay for - that is two different tunes as well. I guess you get the hang of it.

    Our backends are moving more and more into the realm of AJAX with no backwards compability, simply since 0% of our clients who administer the systems have it disabled. If we were to get a customer which didnt have JS, I would probably not rewamp our systems, it would be much more affordable loosing that sale.

    I do however agree that progfressive enhancement, or whatever buzzword fits you for this technique, should be used on frontends, since a frontend user is infact anybody. A backend user, hey U need JS!

  15. I don’t think the 95% argument can really work here - as you as the developer really have no idea if your scripts are getting through to the user. Who’s to say that you aren’t missing 10 or even 15% of your market due to these issues?

    Perhaps more users would sign up for your new online app, but they noticed in trial that it wasn’t working on their office computer and decided to go with a competitor.

    Furthermore, finding out if you’re meeting 95% of your market is very difficult to do. For a long time, banks claimed that very few of their customers were coming in with a non-IE browser, hence the IE only stance. But the only reason people kept going with only IE browser (or having Firefox identify itself as IE) was due to the fact that the site only supported IE browsers.

  16. Dont create applications that need javascript. Create applications, then simplify and/or elaborate them with javascript.

  17. Not to say your suggestions aren’t significantly better methods of coding, but…

    It sounds like the only reason these sites are breaking is because the firewall is making arbitrary edits to the sites’ code.

    And I can’t say I have any sympathy for that. The complaints should be directed at the makers of the firewall rather than the developers of these services.

  18. I have to agree with Nick above - a server side language that is completely reliant on JS to function properly is a big problem. Forms don’t work properly because the entire page is one big form that gets submitted. JS doesn’t work properly because .net rewrites ID names of your elements. It’s all a big clusterfuck, and while .net seems like a great framework for windows apps, I’d like to see web developers move away from it unless it gets vastly improved by MS.

  19. THANK YOU! I’ve been saying that title of the article to people for something like 5 years.

  20. I too agree with Nick - I wish I could claim I’ve written a site in ASP.NET that would work as well with JS on or off though. It’s funny having to justify allocating time in a project to go back through a web application to remove automatically inserted extraneous JavaScript. I hope VS2005 will play nicer in this regard (when I can afford to upgrade).

  21. A while back I wrote an article about why I don’t recommend teaching Javascript to beginner-level web design students and one of the things I said was that Javascript is never really necessary for web development. There was some good discussion on that entry and a follow-up I wrote for it but I got a couple die-hard Javascripters on there who completely disagreed with everything I said and one of them even found it necessary to make personal attacks on me and criticize my knowledge. I don’t know what reasons developers have for insisting Javascript is necessary but they sure can be defensive about it. It’s just a shame that while you can make these statements without a whole lot of negative feedback, little guys like me have to endure really nasty comments when saying the same things :(

  22. The only time an app should be written to where it will not work without JavaScript is in an Intranet, or if it is a purely client side app. And as far as M$.NET or JSFs…why not just use Tomcat and code Java Servlets or JSPs by hand? More control over your code that way.

  23. Roger, I am a JavaScript developer, and when we can use a hijax approach, we do. But there are times when you’re writing an app so big, you simply need to have JavaScript turned on. Period. There is no getting around it. I firmly believe that writing two separate apps is well worth the time and effort. Writing a rich internet email application like Y! mail beta with a fallback ‘hijack’ approach is probably the stupidest approach a developer can take. It’s best at that point to just say “hey you person without JavaScript, use this other app.”

  24. December 4, 2006 by Jonathan Allen

    You cannot be sure your users are not using Netscape 3 either. There is a certain point where you have to say this is the minimum my site supports and I don’t care about the users who don’t meet that minimum.

    More often than not, supporting the scriptless users will cost more in development time, let alone opportunity cost, then the lost sales.

  25. jk: Good idea in theory - but I started off as an ASP developer and naturally went on to ASP.NET (with PHP as a side-stream).

    I just can’t afford to ditch everything I know and learn a new language and technology, so gotta stick with Visual Studio and make it work.

  26. Roger,

    I agree with you. God knows, we’ve all pushed the idea of progressive enhancement. What Ian’s talking about, though, is a different concept; some, but not all, of your script not loading. Now, I’m all in favour of making your scripts progressively enhance in that kind of environment too, but you must know how hard that’d be. Imagine, for a moment, that you detect, when the user loads the page, that everything you need is in place — browser support for the DOM features you use, your JavaScript framework is loaded if you choose to use one. You set up the page you’re on, and then later on when you load another part of the script (because you don’t want to load it all up front in case it isn’t needed, to make users not wait too long), that other part gets blocked. Yes, we should be building applications to cope with this kind of environment. However, that’s a pretty new concept to deal with — no-one else, no-one else, in any programming environment has to write code where they need to cope with bits of what they’ve built not being available. It’s new. We should be working out ways to properly deal with that kind of situation, not berating people for not managing it yet. People are starting, slowly, to get the message that you can’t rely on JavaScript being available; that’s a good thing, thanks in part to those of us who know this stuff, like you, flying the flag. Having to deal with JavaScript that is available and then suddenly mysteriously vanishes is a new concept.

  27. Stuart - wasn’t that what CRC was developed for? Sure - at a different level, but similar concept.

  28. December 5, 2006 by Henry

    A recent example:

    A few weeks ago I did up a css/html template based on a design our designers came up with. Design wise it wasnt that great, and was pretty basic. The client wanted someone else to turn the template into a site. That was fine with us, as we had lots of work going on anyway.

    I checked to see if the site was live yesterday, and it appears they have finished it. However, I just cannot believe how badly they fucked it up. They obviously have no server side scripting knowledge, so instead used javascript to include the menu on each page (!).

    Anyway, have a look at the abomination, try turning javascript off, and laugh at the incompetance (and the fact that they will probably never get listed on a search engine).

  29. Devil’s Advocate: give me statistics on how many browsers have javascript disabled and then I can build a business case for creating a site that works without javascript. Realistically 98% will have javascript available, and convincing my boss to develop an HTML-only version is going to be difficult.

    Roger, you’re describing an idealistic point of view. Dustin Diaz describes a pragmatic point of view, based on how long something takes and how much it costs, and for better or worse, he will win out.

    Henrik’s point of view is a good comprimise:

    “On my new site I can make it work in a degraded version, but I plan to ignore that option for the first couple of months at least.”

    Do the whizzbang stuff but keep an eye out for other considerations - prioritise for the majority but don’t abandon the minority. Gmail is a good example of this approach.

    For the few people here talking about ASP.NET with relation to javascript - it’s a disaster area. If you would like to use the framework and languages while not having to rely on the ASP part, I’d recommend the Monorail project at www.castleproject.org.

  30. December 5, 2006 by Nathan de Vries

    I 100% agree with those who have said “build first, enhance later”. I’m also one of the people that Christian Montoya describes as a “die-hard Javascripter”. Go figure.

    In all the cases that have been described here, Javascript was used poorly. Luckily, Roger is able to point out those wrong-doings and warn people from doing the same instead of just blindly stating that “Javascript is the worst language evar”, or any number of other false and opinionated accusations.

    That being said, does anyone feel that there are applications which warrant a disregard for progressive enhancement? Applications such as GMail would become near impossible to manage (from a development perspective) if it were required to work in a degraded state. It’s not accesible and it doesn’t degrade gracefully, but does the usefulness of its’ Javascript enhancements make that fact unimportant?

    What other applications can be forgiven for relying on Javascript? Are there any?

  31. “What other applications can be forgiven for relying on Javascript?”

    YouOS - youos.com

  32. I only require javascript if you want to add a comment in my blog. The reason NOT to use submit buttons is to keep the comment spammer robots from automatically posting to your comments. No submit button - no action in the form = no robot comment spam.

    In general anyone who blocks javascript with a firewall is paranoid beyond reason. There is absolutely no reason to write code to see if any of your javascript has been blocked in such an idiotic fashion.

    People who say javascript is not needed in a web application are living in the past. Yes you can go through enormous loops to build an application with nothing more than links and submit buttons, but the result is painful to use, ugly and likely to get poor reviews.

  33. December 5, 2006 by Court

    One should be aware (and i see this on a lot of blogs about this subject) is that not all web apps are blogs or news sites or social networking sites. There are many apps that are run thru, or example, a hardware appliance, where a thin client is replaced with an agent-less client, i.e. a web browser. Some of these apps rely on javascript as a fundamental; for example, to show network data in real-time. If real-time display is a fundamental of the application, the alternatives, such as Active-X objects… well, trust me, we DONT want to go there.

    My point is that not all web apps are public sites designed to be read by all. These people have to design semantically and they need to know elegant CSS, but dynamics are required if the thin clients are to be replaced by the web browser, and I think that’s a good thing—it means another installed app is eliminated.

    Thanks for your blog.

  34. Outside of work, I use UltraEdit to handwrite PHP5 code. I am conscientious about making sure my sites function correctly without Javascript. I care about accessibility.

    At work, however, I use MS Visual Studio to produce ASP.NET code. And I must honestly admit that I cannot be bothered to tinker with all the Javascript crap that it produces. I bitch about it but do little more than that. Accessibility be damned.

    Using Visual Studio to produce websites is analogous to using IE6 to test them. This is not an excuse but rather a warning. I’m not sure that issues of accessibility can be properly addressed until the people responsible for producing web development tools and web browsers start truly caring about accessibility.

  35. With more and more web applications emerging I think there is a need to reconsider some “best practices” and to make distinction between content-driven, mostly static pages, and highly interactive application. That applies to the former does not necessarily apply to the latter. I can certainly understand “javascript & cookies support required” being a requirement for such an app. And no, I do not think that graceful degradation must always apply. For some applications degraded version would be like driving your car with all tires flat: you can do it, but is no fun. Of course, if you decide (after careful consideration) that JS is a must for your app, this must be clearly stated for users.

  36. Hi Roger, I’ve had words with a premium web dev firm here on several occasions with ‘award winning’ designs coming out that have javascript placing a drop down menu on the home page for example - usually with no other way to reaching the subpages on that list if JS is disabled. Or navigation bars with no fallback to let you into the site if JS is disabled.

    My concern is that people really don’t get this one and its basic web 101 stuff - don’t make assumptions about the users platform or available technologies.

    It doesn’t matter if nobody can quantify exactly which percent of users do or don’t have the technology available - not really! Logical common sense dictates even .1 percent of internet users nowdays is kind of huge enough to pay attention to. How many people is 5% again?

    The conversation regarding the influence of AJAX being cool is important too. An ex client of mine was sprouting the wonders of his new up and coming AJAX real estate site with drag and drop boxes and yada yada… and I wondered wasn’t that the DHTML of yesterday? Without the ability to degrade gracefully that’s really what it boils down to - DHTML has become cool on the back of AJAX the buzzword.

    Anyway just my 2 cents in passing. The right tool used wisely is key. Sometimes JS is the right tool, but looking around often its not unfortunately.

  37. Want to be horrified? Just go to SIRIUS’ site. (It’s a satellite radio company in the US.)

    Click the Listen Online “link” at the top and “View Source” if you’d really like to feel your head explode. JavaScript can, as you say, be extremely useful, but this site is a prime example of poorly written, completely unnecessary JavaScript.

    I nearly have an aneurysm every time I log in during the morning. I’ve written to them before, but they just can’t seem to understand why they should fire their entire Web development team. It’s beyond incompetence, and it amazes me that a site used by millions of subscribers can be so terribly bad.

  38. Who fully disables javascript? C’mon people… This is like sending email in plain text. It’s 2006!!!

  39. Well, Biff, I for one use Firefox’s Noscript extension to block JavaScript except on sites that I specifically allow.

    I agree with Rimantas. I too have noticed that these comments don’t seem to make a distinction between normal web sites/pages and web-apps. I think acknowledging the difference is very important to this discussion. The purpose of normal web pages is to provide information to the public, while a web-app’s purpose it to allow the user to perform a task. Web pages are much easier to create without requiring the use of JavaScript, while on the other hand, due to the user interaction involved in web-apps it is extremely difficult to make them highly usable without the use of JavaScript. These two articles delve into this a little further:

    Thanks for posting this topic, Roger.

  40. Why does it need to degrade? Who doesn’t use have a browser that supports javascript? Last time I looked browsers were free. I always wondered who these unfortunate people are who are forced to use old browsers. I picture them living in deep caves in the earth clicking away on some old version of netscape, wondering why google maps isn’t working for them.

  41. And don´t forget that most mobile phones / handhelds do not have javascript enabled. I surf quite a lot with my handheld together with either mobile IE or Opera mini, most Ajax sites do NOT work with them for example www.hitta.se or www.eniro.se (it’s like a swedish google maps). That sucks when trying to find a place when on the road.

  42. I think all pro’s and con’s have been discussed. In a perfect world, where money doesn’t matter and time is a plenty, we all could be building websites which degrade well. Even up to the level of lynx :o)

    In my opinion “with great power comes great responsibility”, irony intented.

    My approach always is to inform the customer about the drawbacks of using certain technologies and try to persuade him/her to provide alternatives (the money for it anyway). Usually, sadly enough, it takes laws to enforce this level of accessebility.

    When building for myself, well I let myself go wild in exploring the alternatives. Or not if I don’t feel like it. I’m not getting paid ? Right?

  43. December 5, 2006 by Roger Johansson (Author comment)

    Thanks for the comments so far. It’s nice to see that we’re able to discuss this without things getting out of hand :-).

    I do think I need to make a clarification though:

    The “must degrade well” rule is mostly applicable to normal websites and light Web based applications such as bookmarking services. Other rules may apply for advanced Web based applications and administrative interfaces for content management systems.

    Now watch everyone start calling their site “an advanced Web application” ;-).

    Montoya:

    t’s just a shame that while you can make these statements without a whole lot of negative feedback, little guys like me have to endure really nasty comments when saying the same things :(

    I’m actually very surprised that the comments so far have been quite civil.

    Dustin:

    But there are times when you’re writing an app so big, you simply need to have JavaScript turned on. Period. There is no getting around it.

    Agreed - see above. I am not thinking about huge Web apps here.

    Nathanael:

    I just can’t afford to ditch everything I know and learn a new language and technology, so gotta stick with Visual Studio and make it work.

    You don’t have to use Visual Studio to work with .NET though (except for compiling and stuff). At work we use .NET for most sites, and our sites do not rely on JavaScript. The trick is to forget about the built-in controls that come with VS.

    Stuart:

    What Ian’s talking about, though, is a different concept; some, but not all, of your script not loading.

    That is one part of the problem. The other is that the services he is having problems with are using JavaScript for the wrong things, in the wrong way. But yes, of course partial filtering of JavaScript is very tricky to handle.

  44. I recently did a review of browser statistics that included a look at the current JavaScript support; at the moment, the number of users without JS support sits at about 5%.

    Judging from the comments many people seem to consider this a minority not worth considering. It’s not exactly analogous to browser usage, but it is the equivalent of ignoring all Safari and Opera users combined who, in one set of statistics, account for less than 3.5% of browser users.

    That said, I’m a fan of JavaScript. The examples in the Yahoo! UI Library, for instance, are great but I tend to prefer techniques that manipulate existing markup rather than methods that generate markup and content with JS.

  45. It’s not exactly analogous to browser usage, but it is the equivalent of ignoring all Safari and Opera users combined who, in one set of statistics, account for less than 3.5% of browser users.

    I agree - my previous employer’s web stats indicated that Firefox usage was less than 5%; imagine the complaints from web developers if it was decided that supporting Firefox users wasn’t necessary as they were such a small percentage…

  46. I use ASP.NET a lot at work (it’s our standard platform), and depending upon where the application is going to be placed (internet/intranet) I do varying amounts of work to remove the javascriptiness.

    The online apps should work without javascript; the intranet ones may require it but will have been tested against assistive technologies. It’s an ideals vs practicality thing…

    While my accessibility “camp” means that I want to make everything available to everyone, I have no problems with - if I have to - making some things fail to work without javascript, provided that that javascript works with assistive technology.

    For example, a lot of the .NET javascript controls can be avoided, but the key one - the javascript dopostback - seems to work with various sorts of assistive technology, and has been tested by a number of people. (My test case is available here: http://www.thepickards.co.uk/index.php/200610/javascript-testcase/).

    Of course, I don’t know how partial filtering of javascript would handle this, but if I must do it this way, I won’t lose any sleep over it…

    Although I would obviously point out that this would automatically give a WCAG single-A fail, and therefore as someone working in the public sector it couldn’t be used on our internet sites.

    I find myself shifting towards the other “camp” with regards javascript: as long as people aren’t prevented by reason of disability from being able to use it, I don’t have a problem. If someone’s firewall is blocking my javascript, that’s their problem, not mine. Either take it up with their security guys if they need to site for work - or if they don’t, stop looking at it in work’s time :-)

  47. December 5, 2006 by Ben Williams

    @James- you cannot equate the number of browsers without JS support with the number of users without JS enabled. As has been said before its the coroprate filter/block on javascript which is the clincher here. My network admin even wanted to block CSS due to its ability to run scripts- similarily flash is not installed and JS is blocked (although now the occaisional site is creepeing in). Thank goodness for being an Admin.

    Fully agree re the website/webapp position although I do wonder what happens with full blown webapps under current accessibility/disability descrimination laws . I guess it all boils down to thoughtfull webapp design- heh or a click once windows app(or even WPF/E!)

    As for ASP.NET, I could not do it without VS.NET and intellisense- how do you manage without that Roger? I never use the designer, but live without intellisense- not on your nelly. Not to mention all the developer productivity boosts you get (Resharper etc)- you just have to have your head screwed on right. Its really not difficult to produce non js reliant , accessible and valid sites using asp.net. Sure there are plenty of ‘developers’ who don’t grok the client side accessibilty issues- but these exist everywhere accross all platforms- education is they key. Atlas uses a nice model (well mostly nice) of attaching events through an xml-script parsing engine- no js, no events.

    I mean the last time I looked at RoR the client side script handling was a mess- inline event handlers a-go-go. Not exaclty a paragon/leading light there either.

    What about mobile browsers and JS support- can any one point me to some detail on mobile browsing support of JS?

    Great discussion.

  48. To quote Dustin:

    But there are times when you’re writing an app so big, you simply need to have JavaScript turned on. Period. There is no getting around it.

    The administration area of sites we (I, but I’m being polite here) create always rely on javascript (formchecker, ajax call every now and then) because we can safely state that the one using the admin area (which most of the time mostly is 1 user, or only a few) are using IE6 (with javascript on), or we can suggest them to using FireFox.

    The public part of the created sites we do try to keep as clean as possible …

  49. December 5, 2006 by Harknell

    I have one thing to say: mobile devices. Phones, PPC, Palm, etc. None really support javascript enough to work properly on a heavy ajax oriented site. Right now most people don’t use their phones and such for their core internet usage, but eventually as EVDO and bandwidth get better, people will expect things to work on their phones as well as usual on their PC, and they just won’t. Also, as browsers change (i.e. 6 to i.e. 7 and so on) tweaks in javascript implementation can easily lead to a broken site. Who knew a few years ago how fast Firefox would take a significant part of the PC browser share—who knows what might happen in a few years? You have to start with it works 100%, then add to it, or your competitors will eat you alive when theirs does and your doesn’t.

  50. I have always believed the best way to approach this is to forget about javascript (all of it) when you first build the site/app.

    After making sure all the functionalities and links work, then maybe you can say ‘let’s apply some ajax juice on it now’. The markup stays the same, and all links or forms with JS action can return false while you do your fancy things with them. If javascript is not available or partially not available, then everything still works because it has always did.

  51. December 5, 2006 by Ned Baldessin

    Blogger and Bloglines: the issue lies with the firewall filtering, not the sites. I can’t imagine how you can realistically write JS while thinking about what might trigger a firewall filter…

    Magnolia: I agree here. For the last project I worked on, the art director wanted cute submit buttons (with a :hover highlight). We first coded them using links and JS, but then reconsidered, and coded them using a simple button tag (don’t forget type=”submit” for IE).

  52. Sadly, I think the bottom line is along “it works for most people, and it’ll cost too much to fix it for those who can’t see it.. we’ll do it, uh, soon”.

    This kind of mentality has to change, although in saying that I did feel like your post (although good) was rather angry lol.

    Have to agree with Alvin (#50) … build the app, make sure it works, then enhance it with Javascript. It’s the only way to be sure.

    :)

  53. It seems to me the market will decide if this is a problem or not. If Blogger is making a huge mistake with its coding practices, they will lose users to a system that has a more accessible interface. From what I can see, and I may be wrong, this doesn’t seem to be happening. I just don’t see any market trends saying these problems are widespread.

    On another note, you specify that the noscript tag is the sign of outdated coding practices. Could I hear a bit more on this? I’m interested in hearing the alternatives. I do object testing within my js, to test for the availability of certain features, but obviously that’s not going to suffice for users without js.

    (also your notes say you don’t have to enter an email address to comment, but mt displays an error if it’s left blank)

  54. I just discovered another broken site. I was using Yahoo Mail in one tab, and testing a different site (under development) in another tab. When testing, I turn off javascript. I forgot to turn it back on, and went back to the tab I was writing an e-mail in. The send button would no longer do anything. I thought Yahoo went down or something, until I thought about this article you wrote and turned the JS back on and tried it again. Then the send button worked. Heh.

  55. Just a quick response to the bit about Bloglines and frameworks. The real problem was and is not that Bloglines uses a popular framework, but that the firewall guys will not tell us what’s triggering the blockage. We have the ability to change the popular framework’s source and would do so happily if we knew what was being blocked. Even if we wrote all of the code ourselves, there’s a good chance we’d run into exactly the same problem and be just as hamstrung trying to fix it. Unless we know what’s causing the breakage, we’re just shooting in the dark.

  56. December 5, 2006 by Roger Johansson (Author comment)

    Ben Williams:

    As for ASP.NET, I could not do it without VS.NET and intellisense- how do you manage without that Roger?

    The .NET stuff I personally do is not a whole lot, and I do that in BBEdit or TextMate on my Mac, and then hop over to VS.NET in VPC to compile. I don’t know, I guess it’s because I’ve always created all my code by hand.

    MMI:

    Regarding noscript, here are a few articles on that:

    Sorry about the message about an email address not being required even though it is. I changed the setting recently and forgot to update the comment templates. Fixed now.

    Ben Lowery:

    We have the ability to change the popular framework’s source and would do so happily if we knew what was being blocked.

    Fair enough. Good to know that you have tried finding out what triggers the problem and are prepared to fix it :-).

  57. @Ben Williams Yes, I agree with you.

    It was poor phrasing on my part - when I talk about users without JavaScript support I’m talking about users who report false for JavaScript - for whatever reason.

    The number of users operating browsers that do not support JS is minuscule so these figures represent users with JavaScript support disabled at the user or admin level.

    Really I was trying to make a glib point about the comparative size of the two groups and it would seem, from Roger’s post about Safari numbers, that even that was somewhat erroneous!

  58. I’ve been trying to keep up with all the good discussions on web development these days, and I remember the JavaScript one keeps coming back up :)

    For me, a simple web site should not need JS, or only use it as “progressive enhancement”. A web application, however, is bigger and more complicated, and in some places, it’s just easier to use JS than to work around it’s absence. This is especially the case where there is a lot of interactivity going on. I also think this is acceptable in a limited environment, such as an intranet. Admin sections, that’s another one I think is OK to use JS, since it will likely only be for a relative few people.

  59. In the Bloglines case, I’m with Ned Baldessin - the fault is with the firewall, not the code.

    As a developer I can, and should, develop and test my code such that it works with Javascript on, and with Javascript off. Period.

    If you choose to install some software that runs some scripts and blocks some others (based on some unknown and possibly spurious criteria) it’s your problem if pages stop working. I don’t see how developers could possibly test for all possible part-on-part-off cases.

    Arguably, using a framework is a good defence against being firewalled out, as the firewall could be explicitly configured to trust the handful of established frameworks, whilst they might be less happy with custom-built code.

    Of course, I agree that it’s best not to introduce a Javascript dependency in the first place if you don’t have to.

  60. Try login to NIH (National Institutes of Health) without JavaScript.

  61. It all depends on what you mean with “advanced web application”.

    I’m spending effort in implementing a degradable architecture for my web apps, together with valid code (both the rendered and the js generated, hidden code).

    Really, it doesn’t take much more time if you:

    1) cover it from the start, as a structural detail. It’s kinda impossible to implement in a second time refactoring;

    2) use lowest-level libraries (e.g. Prototype), or avoid packed widgets and markup predefined templates in those js frameworks. Or, if you have time and resources, start developing your own framework;

    3) have at least one coder with solid experience in both sides of the equation: presentation and behaviour.

    I think an Ajax Start Page is something Dustin would name as an advanced web app. I’m trying to keep the one I’m developing degradable (and inside all other web standards), hoping (when coming out of the beta) to find a way to give users an alternative for every function when js is disabled.

    Somebody said 5% of users left behind is a normal practice today. Ok, never mind the ethical argument. In a “long tail” market I hope in a near future to be the only one capturing those users with degradable ajax products: do you really think ensuring a guaranteed 5% of feed aggregation market would be so bad?

  62. Exactly 0 people, who do not KNOW how to turn it back on when needed, disable JavaScript.

    It is installed by default, it is used. If your going to a site that is going to add value to your experience you of course will allow the javascript.

    Very nice, as stated above, to alert the customer they will of course NEED javascript.

    Obvious, NOT to use obtrusive javascript if you do not need it. AKA my personal site.

    Know your audience??, like a corporate intranet??, who gives a flip???

    This is 2006, we should not be arguing about turning javascript off!!! But how to educate and market that it is the new web and javascript is as FUNDAMENTAL and NORMAL as html and css.

    Security concerns whatsoever out there about javascript??

    Lets ADDRESS THE PROBLEM :)

  63. Oh forgot 1 comment.

    I agree, if your going to start using a framework? Commit to it and start understanding JavaScript as well as the hard-core framework users.

    I admit to being NOT at that level, so I do not WILDLY use frameworks.

  64. Exactly 0 people, who do not KNOW how to turn it back on when needed, disable JavaScript. — Dan

    The concern is actually for those who know how, but don’t want to, who will get mad and never visit your site again. Granted, if your site is something they absolutely have to use, like their bank or their email, you can get away with it…but some random site? you better make sure html forms work…unless you’re fine with your hits going down.

  65. I agree with you Roger, AJAX and the javascript frameworks are very smiliar to the DHTML hype.

    I´ve been workin with the web for over a decade now and the trend now is very similiar to the late 90´s exept for more valid code maybe…

    Even my bank (SEB) has some animation AJAX features for reloading pages!

  66. December 8, 2006 by Agrajag

    I agree with everything that’s been said about gracefully degrading scripts. This is fine when JavaScript is disabled in the browser. I’m happy (and I think everyone should be) to provide a working (if somewhat featureless) plain html version and have the script replace this if JavaScript is enabled. Or, at least to provide a link to an (eg. php) alternative. However, I think it’s rude to expect developers to provide for every different firewall system that people may have at their workplace. What if the firewall was to let through the replacement of html elements but then block the actual replacement action that the script performs? I think that is just too much to expect of developers.

  67. I work as the only front-end designer in a team that pretty much uses ASP.NET for everything. As for the javascript question. I think it should established clearly in the spec before any work has been done as to javascript dependendency. If any functionality breaks without Javacript, then the site is Javascript dependant. Which is not automatically the worst crime - it needs to be decided by the client (who will need your opinion) based on the intended audience. Generally speaking, if it is an intranet product or for a focussed well researched audience then may be no argument for making a site javascript dependant. However, if it is a site for a general public audience then in most cases all javascript behaviour should be degradeable.

  68. December 11, 2006 by Ty Gossman

    Great debate going here. I read through parts and then cut to the chase, my usual style. The javascript ajax functionality is what’s getting all of the attention by the end user in some cases. It’s the “Let’s develop this bugger with all the bells and whistles” school of developing. If it doesn’t get noticed for screaming AJAX, then it will not crack the marketplace. A back up plan would be to make it play nice and degrade by enhancement. I honestly believe if it wasn’t built that way, it’s because of A. money issues, B. Lack of knowledge to do so. Most of these JS libraries are plug and play, view the demos and rock & roll, so you are giving the designers, and possibly the developers way too much credit. There maybe are not that many honest to goodness javascript coders out there, just js code monkeys.

  69. I completely agree with alvin woon (#50).

    About the image-as-submit-button, why not simply use CSS to replace the normal [input type=”submit”] with a background-image? That’s how i always do it, and it seems to work fine in most browsers.
    It’s easier than the javascript approach, and i personally don’t like [input type=”image”] as those images are often design-related and so should not be in the HTML source, and then there’s also the problem with not being able to resize text.

    I’ve never thought about JS not loading entirely, but based on others’ comments it seems this isn’t something one really needs to be concerned about? Or?

  70. December 12, 2006 by Stevie

    Henrik

    If you are trying to make a technically advanced site you have to cut some corners to get a decent time to market. So as long as you plan to support degraded operation I think it’s resonable.

    That’s fine if you need to use scripting to achieve the basic functionality. But most of the time, you don’t. That’s what is frustrating - when some idiot has built a menu (or even just a hyperlink!) that relies on Javascript. There’s no need! If HTML can do the job, let it do the job. Javascript can enhance that function, but never let it replace it.

    Jonathan Allen

    More often than not, supporting the scriptless users will cost more in development time, let alone opportunity cost, then the lost sales.

    Again, if the script is essential to the operation of your site, that may be fair enough. But it is not an excuse for bad designers who rely on script libraries to accomplish simple tasks that could be done in HTML.

    Mark Wubben

    The idea of firewalls blocking certain parts of my code, but not others, is not something I had considered before. It’s good to keep this in mind when you write the code that should really only run if all JavaScript is there.

    Don’t forget that a number of more advanced browsers now allow users to block Javascript at an action level - ie, allow it to do certain things, but not others. No firewall needed, just Opera 9.0!

    tc

    Why does it need to degrade? Who doesn’t use have a browser that supports javascript? Last time I looked browsers were free. I always wondered who these unfortunate people are who are forced to use old browsers.

    A lot of people browse the web from work. A lot of corporate networks do block scripting, Flash and other tricks. Users can’t re-enable them, and they can’t download/install new software - they are stuck in the dark ages.

    An increasing number of people browse the web on mobile phones. Script functionality is very patchy, with many phones not supporting Javascript at all.

  71. There is no point in using an online AJAX application or web site if javascript is disabled on your browser or by your firewall. An Ajax app/site is user friendly and useful BECAUSE it is using javascript (i.e., a potentially unsafe, CLIENT-SIDE technology). “gracefull degrading” has some meaning when it’s about page layout and design, but it is meaningless when it comes to Ajax. There is no graceful degrading, just less features that make the app. worthless or painful to use. So it should just not be used if javascript is disabled. You either decide that ot is crucial to use such and such Ajax app/site (and therefore enable javascript), or you think that security is a priority, keep javascript disabled, and don’t use the app/site. I don’t see a problem here.

  72. December 19, 2006 by Morgan

    The Ma.gnolia case reminds me of one of my persistent irritations. A site which loses no functionality without javascript… except for one particular set of form submit buttons that won’t work. It seems to be set up that way to do some data verification before the form is submitted, but I know that can be done without making buttons useless without it.

    It’s the “link that does nothing a normal link can’t do, but requires javascript” that really makes me want to scream though.

  73. Well, pretend like you are coding for an older browser. I mean, there are incentives for stepping up to a newer browser but you should code for the people without such a luxury.

  74. Digg.com does not degrade gracefully without JavaScript. In particular the “digg it” buttons do not work without JavaScript. This means I cannot use Digg from my mobile phone’s browser. This would be very easy for them to fix, I can’t understand why they haven’t.

    As developers keep telling me, using .NET doesn’t mean that your application will be inaccessible or JavaScript heavy. they assure me that you can make your own components, and you can configure it to behave. But the bottom line is that by default it encourages bad habits. A vast majority of developers don’t make the extra effort to fix the code it outputs by default (or don’t know how to fix it). .NET should be leading by example (I know, I laughed at my optimism too).

  75. May 25, 2007 by Kris

    If JS is available, hide or remove it and insert the fancy-schmancy styled link instead.

    Hide it by setting it on an offscreen position with position:absolute. Without it the user is unable to submit the form with the enter key (or whatever he or she uses). If you set only the left or right property and not the top or bottom, then the page will not scroll up and down when someone uses the tab key to skip focus to it; because, yeah, the hidden button is still in the tab order, unfortunately.

  76. May 29, 2007 by Greg

    Javascript allows developers to program quicker and gives the page a more dynamic and appealling presentation. It also cuts down on server side calls. I believe the way forward is to use javascript and future browsers should not have the ability to turn JS off, it should be permenantly on. The idea when developing software is to do the most with the least amount of effort. Developing two applications one for Javascript people and one for that small minority of users who need to join us in the 21st century takes too much time and effort, and time is money!

    Javascript is the way forward and developing sites that use javascript will only help force that small amount of die hards to wake up and start seeing Javascript for what it is, a fantastic tool.

  77. I always build my webapps without javascript first, then layer it on afterwards.

Comments are disabled for this post (read why), but if you have spotted an error or have additional info that you think should be in this post, feel free to contact me.