How to handle browsers where JavaScript may be turned off? - javascript

Suppose I'm developing a web app that is heavily dependent on JavaScript and which uses AJAX for all the POST commands to store data, etc.
How should one deal with those situations where a user may have JavaScript turned off? Is it unreasonable to require that a user's browser has it turned on? Are there any best practices for these situations?

Use <noscript> tags to let users know that they cannot use the site without Javascript. It's not the best practice, but it is common at this point and most users without it will have experience being left out in the rain.
That said, if you can provide a version of the site that doesn't require Javascript (think the degraded version of gmail), that is clearly a superior solution. Without it, you will lose mobile surfers, plus blind folks and others with accessibility needs. And people who are too stubborn to use JS, but we don't care about them.

I personally think it is not that big of a requirement to expect people to have Javascript turned on.
If you do not want to support non-javascript, it is as simple as:
<noscript>
This site works better with Javascript turned on.
</noscript>
Near the top.
If you still want to support users without Javascript, you can structure your Javascript so that if the JS isn't loaded, all of the forms still submit to the right place.
For instance, if you have a form:
<form action="" method="POST">
<input type="text" name="name">
<input type="submit">
</form>
Don't build the actual form with the idea that you are using Javascript. Instead, simply hook into the page to enhance the experience.
Regularly, the above form would submit to itself. With Javascript, you can hook in and make that Submit happen through AJAX instead of a new page load.

The key here is the concept of "graceful degradation". You want to offer the best possible experience you can despite not having javascript support. For AJAX, this usually means making full page requests rather than the lovely dynamic ones we're used to; POST will similarly have to submit through HTML and load a new page.
This obviously isn't as feature-rich, and displaying it well can be a challenge, but if you're looking for a best practice, that's the goal. It's also worth telling users via a noscript tag that they have javascript disabled (some people might have legitimately done this by accident), but turning off your entire site due to a lack of javascript is not friendly behavior.
Any site worth making is worth making accessible.

Depends on the site; something like Google Maps, for example, is clearly just not going to work without Javascript. So simply showing a noscript element politely mentioning that they will need it to view the site is fine.
Probably best to avoid any patronising "you need to get a new browser" messages; they may not be able to, for a number of reasons, or may simply have chosen to install NoScript or similar. According to Mozilla, NoScript has had nearly 70 million downloads; obviously a large proportion of those will be repeat downloads for the same person, but there could easily be 10 million people out there with it installed - that's not insignificant.
"Best practice" would, I guess, be to have a gracefully degraded version if possible. Up to you to decide whether that's worth the effort or if it's appropriate for your site.

You can send form data through action attribute. When JavaScript is turned on, remove the attribute by using removeAttribute or setAttribute. That way, when non-JS users use the browser, they can still submit the forms. However, in the backend code, you have to support non-JS as well, which is way more better than using <noscript> or no-js (Mordenizr).
Of course, there's still some drawbacks by doing this, for example you need to reload the whole page each time, which consumes a lot of time and memories.
So far, this is the best solution I can think of. Hope it helps.

Related

html form submit using javascript vs submit button

I have been using javascript to submit HTML forms at times for some convinence. I would like to know wheather there is any drawbacks of this approach compared to using classic form submit using a submit button
Using plain HTML is better for many reasons:
If your user does not have JavaScript enabled, or you havea JavaScript bug in your code, your form still works.
Plain HTML forms are simpler to write, and harder to screw up
An actual button is better semantically than a magic link or div that submits the form for you. This helps with things like tab ordering, OS integration, screen readers, and is clearer to programmers who work on the code after you.
The browser already has battle tested code to submit forms. Why would you rewrite that code for no point? It increases risk, complexity and time.
Not writing the JavaScript code means you have more time for other things, like not working on the code anymore.
If something already exists and works for your use case, don't reinvent the wheel!
The only drawback I can think of is if you need to have the page reloaded because you're integrating with an older site that regenerates HTML each time... But if you're building a new system, or it already does that, in my opinion it's better. Saves bandwidth, computing time, re-rendering time, etc..
If you're talking about just submitting an HTML form, there's really no difference.
No there are no drawbacks really. You might have more code the way you are doing it as opposed to just wrapping everything in a form and submit button but you can still take advantage of https of course and everything else the web may have to offer these days.
The most predominate disadvantage is the inability to provide functionality for visitors who have Javascript disabled. You can support both simultaneously by providing a different page to redirect to when javascript is disabled.
The following is a list of methods used to detect and react to disabled javascript:
<noscript> The HTML noscript tag.
Using jQuery or Javascript to set a cookie
Using Javascript to hide an area using CSS.
Personally, I'm not a fan of HTML forms. HTML is a layout language, and a poor one at that. Keeping layout and functionality separate is a central tenet of object-oriented programming. Whether you perceive HTML and JavaScript as representing these functions in that manner is probably a personal choice. You could argue CSS is the layout.
If you're writing a simple page with little else going on, then using HTML forms isn't a bad idea.
If you are planning to write a good-sized application, with lots of nice features, then, for me at least, it would make sense to have that in one place.
If you start introducing JSON or any kind of client/server relationship beyond "here is my text or drop-down choice" then take a programmer's approach rather than a web designer. JavaScript gives you more flexibility. You can chat with the server without anything happening on the page.
If you use a library like jQuery, the coding overhead is very minimal.

Website doesn't work with Javascript turned off

So head to www.jabsy.com, with Javascript turned off.
Basically, I use some JQuery UI Dialogs, I use Javascript for all the bindings on the page...I pretty much use it for everything. Is that really a bad thing though?
Nothing really works without Javascript. Not even the Google Maps API.
Should I go out of my way to try and make the entire page work without Javascript? Is that even possible with my site? I wouldn't even know where to begin as I use Javascript for everything, so could I get some points? How many users actually turn off their Javascript these days?
Would it help to let the user know if they have Javascript turned off and make them turn it on before accessing it and provide them with directions how?
Yes, if your site requires JavaScript you need to let the user know that it is required.
For example:
<noscript>
<div>
You need to have JavaScript enabled to use this site.
</div>
</noscript>
You can provide more description as appropriate. A savvy user that sees this text is going to be able to then go in and turn on JavaScript for your site. A non-technical user might have trouble, but I would think most of them would be running with JavaScript enabled anyway (?).
According to data collected in 2007, about 3% of users in the US have JavaScript off. I'm sure that number is lower today.
It really depends on how critical the sections of your page that require JavaScript are. If there is a form that is mission critical, but controlled completely by JavaScript, you probably want to engineer a way for that form to do the same thing with JS on and off.
However, you have animated snowflakes on your background (for the love of God, don't really do this), it's not going to negatively affect someone visiting your site with JavaScript off.
Really, it all comes down to how important the information or actions are to your site. Turn off JavaScript and note all the things you can't do that are absolutely vital, then make them work.
Keep in mind there are several audiences that will not render your JavaScript:
Screen readers/accessible browsers
Console-based browsers (Text based browsers)
Search Engines (Google)
Your specific service (location-based messages) will be way too cumbersome to use without JavaScript (and its content is dynamic). Therefore, I see no problem requiring it. You should, however, point out that JavaScript is necessary to use your site (Preferably at the top, in really large letters). You can do that by including the alternative no-JavaScript content in noscript tags, i.e.
<noscript>
<div style="font-size: 200%;">You need JavaScript!</div>
</noscript>
However, most websites are content-based, like a company's homepage, stackoverflow or Wikipedia. These websites should be usable without JavaScript. Nowadays, even smartphones have excellent JavaScript support, but Kindle and regular phones are still too slow for JavaScript.
There is a line of argument that says sites should work without JS. Personally, I think that is tosh, unless you have a clientelle for whom this is liable to be an issue. JS is a reasonable thing to expect for many sites.
However, it is polite to let people know that this is a requirement, and inform them rather than just letting it not work. If your site is heavily JS dependent, then you may have made some mistaken design decisions, but it is probably not worth re-working it. If you monitor the number of people who get the "you need js" message, you will identify if it is proving a turn-off. I suspect it will not be an issue.
So build based on what you need, BUT tell people if they need to have things set.
You can use the <noscript><!-- html here if no Javascript --></noscript> tags and place content to be rendered in between if javascript is turned off.
I don't think there are many sites that will work with these days without it. It's more or less mandatory.

Is it sometimes ok NOT to Degrade Gracefully?

I am in the process of building a video sharing CMS that uses lots of jQuery and ajax for everything from rich UI effects to submitting and retrieving data to and from the database. When JavaScript is disabled it everything falls apart and 90% of the functionality doesn't work.
I am beginning to think its ok to not degrade gracefully for certain types of sites like this one which uses a flash player to stream the main content - the videos. So what would be the point of going to great lengths to enable dual support on everything else if the main content of the site can't be viewed. Even YouTube breaks with JS disabled.
I'm planning to release the CMS under open source license, so the question is:
For mass distribution (and for this type of site) is not degrading gracefully a good idea?
As long as you make it clear to the users that they need JS enabled, it is ok for it to "fall apart" without JS. However, if you give no indication that it shouldn't work without JS, then people will get angry. Most people nowadays expect sites to require JS in some aspect of their functionality.
For something as complex as a CMS with videos, it is the users fault if they don't enable JS. They shouldn't expect something like that work without JS, and even if they do, it's probably not worth your time maintaining two versions of your site: JS and non-JS, especially for something that is open source.
Seeing as your application relies on javascript for its entire purpose, it is impossible for you to degrade gracefully. As long as your site clearly tells the user to enable javascript to get all of your awesome functionality, and maybe some links as to how to do so in different browsers, you should be fine. :D
You are essentially choosing an audience. It's not unlike deciding whether to support IE6. It's not right-vs-wrong, it's simply a question of what percentage of your audience you are willing to lose, in exchange for ease of development on your end.
That said, I find progressive enhancement (of which graceful degradation is an outcome) to be an efficient and safer way to develop. Do the HTML first, make it work, then add JS as sugar on top.
It's not likely that one of your users is not running Javascript. What is likely, speaking for my humble self, is that you will have some small JS error which kills everything. (JS tends to just stop on exceptions, you may have noticed.)
It's nice to know that, in the event of such an error, your users can still use the site. That's what graceful degradation is for, in my opinion.
Graceful degradation doesn't mean "everything works fully in every browser", it means "if your browser can't handle something, you see something sensible instead of broken junk".
In your case, simply detecting that the site will not work and displaying a nice error page explaining what is required would be an acceptable form of graceful degradation.
If you're a perfectionist, there's nothing wrong in letting people w/o JS know what's going on, as opposed to just letting the website break. Here's a quick how-to: How to detect if JavaScript is disabled? .

Is graceful degradation in the absence of JavaScript still useful?

When even mobile browsers have JavaScript, is it really necessary to consider potential script-free users?
Yes. Your web pages aren't just consumed by people: they're consumed by search engines, and crawlers, and screenscrapers. Most of those automatic tools don't support Javascript, and essentially none are going to generate UI events or look at deeply nested AJAX data. You want to have a simple static HTML fallback, if nothing else then so that your web pages are well indexed by the search engines.
Forget the crazies who disable Javascript; think of the robots!
Yes.
People can (and do) browse with javascript disabled. If your site will work without users having to explicitly enable javascript for you, that makes them happy.
Exactly how relevant depends on your target audience, of course.
I would argue that you shouldn't go significantly out of your way to accommodate for non-JS users for the following reasons:
All Modern Browsers Support JS
This is a snapshot of browser usage
today:
http://www.w3schools.com/browsers/browsers_stats.asp
Even the oldest common browser, IE6,
supports basic JavaScript and AJAX.
If you decide not to integrate
certain features b/c of a JS
dependence, this proves that you are
essentially doing it for people who
started with JavaScript enabled and
explicitly chose to disable it. I
think these people should expect for
some features, and perhaps even
entire sites, not to work as a
consequence.
Few People Willingly Disable JS
Building on my point above, average
web users don't know or don't care
that JS can be disabled in browsers.
It's largely a tech savvy crowd who
knows how to do this (myself
included), and as tech savvy users we should know when to
turn it back on as well.
Cost of Support
In light of the above, consider that
choosing to accomodate users who have
primarily willingly disabled JS comes
with a very real cost. If you are
managing a large project with heavy
UI requirements, you can easily burn
a lot of developer hours
accommodating for what is a very
small user preference. Check your
budget. If it is going to take 2 devs
working 40 extra hours each on the project
to accomplish this feat, you are
easily going to burn a few thousand
dollars on what is essentially a
non-issue for the vast majority of
your users. How about using that time
and investment to further buff up
your core competency?
Precedence
I may very well be wrong on this, but
I think it would be difficult to find
major media or social sites that
don't rely on JavaScript for some
portion of their functionality to
work. If major businesses that rely
on the operation and accessibility of
their site to stay in business aren't
doing it, there's a good chance it's
because it isn't needed.
CAVEATS:
Know your market. Continue to build XHTML/CSS that is semantic (preferably by using the RDFa W3C recommendation). Still strive to make your sites accessible to the visually impaired. Don't believe everything you read. ;)
DISCLAIMER:
My argument above is largely dependent on how you define "graceful degradation." If you mean all the links still work, that's one thing, but if you mean all the links still work and so does the wombats game, that's another. I'm not trying to argue for making your site so JS dependent that non-JS users can't access any portion of it. I am trying to make an argument for the acceptability of certain features, even some core features, being reliant on JS.
It is relevant and it will be relevant even after 10-20 years when javascript might be supported everywhere. making things work without javascript is important development technique because it forces you to keep things simple and declarative. ideally javascript should be used only to enhance experience but your website shouldn't depend on it.
there is clear advantage from maintenance point of view to have most of the code in declarative format (html+css) and as little as possible in imperative (javascript).
My position:
I browse with NoScript, so if I come on your site it will be without benefit of Javascript. I don't expect the full user experience.
What I want, before turning on JS, is to be assured that you're reasonably competent and not malicious, and that I actually want what you're using JS for.
This means that, if you actually want me to use your site, you should allow me to look around, using links. (If I see a site that's totally useless without Javascript, I generally think the designers were incompetent.) You should let me know what sort of functionality I'll get from enabling Javascript, and you should present the site in a legitimate-seeming way.
I don't think that's too much to ask.
graceful degadation / progressive enhancement / unobstusive javascript is absolutely relevant!
as with all accessability issues: just imagine for one second what it's like to be the one on the outside who can't use the page.
imagine you're travelling around the world, you're in some hotel or internet café with really old computers, old software, old browsers, you want to look up your flight and you realize you can't because of some javascript incompatability in the old browser you're using.
(try 'old mobile phone' or 'stuck behind a corporate firewall' for different scenarios)
image what a world of possibilities opend up to blind people with screen readers and the web, and image what it's like to find these possibilties closed again because of javascript.
so much for appealing to your better nature.
you might also want to do it
to keep your site accessibly for search engines.
Yes, it's relevant. Mobile browsers in use today do not all have Javascript enabled. It's available on new phones, sure. But there are millions and millions of people like me, who have phones running older browsers, and for all of us, a JS-required browsing experience is just plain broken.
I don't even bother visiting sites that didn't have progressive enhancement in mind when they coded. I'm not technically behind the times. My phone is a year old. But I'm not going to re-up my contract and buy a new phone because of a crippled web experience.
It depends on who your target audience is. I have JavaScript turned off by default and turn it on when I know what the site's intent is.
It's generally much faster to browse with Javascript disabled (digg.com is lightning without JS), which is why it's popular.
In Opera it's really easy: you simply press F12 and untick the javascript option. I always browse without Flash, Java (not javascript), animated images and sound. I enable Flash on a per-site basis, eg YouTube. Sometimes I turn off JS temporarily if my system is slowing down.
And don't forget about:
Screen readers (I think they mostly have JS disabled)
Text browsers or other very old systems
Ad blockers (if your filename happens lands under their radar)
Any old browser that either doesn't support JS at all or the JS breaks (e.g. IE6 doesn't support some modern JS stuff).
The solution is to use progressive enhancement rather than graceful degradation, i.e. start with the basic HTML and add CSS. Then add Javascript and/or AJAX to parts of the site.
For example, if you had a site like Stack Overflow, voting up an answer could submit a form normally. If JS is enabled, it would do an AJAX request, update the vote count and cancel the form submission, without leaving the page. SO doesn't do this though...
I for one always have NoScript turned on unless I trust the site for a number of reasons including cross-site-scripting, click jacking, and HTML injection. It's not me being paranoid, it's because I know a lot of developers, and know most of them have no idea what web security is, never mind how to avoid vulnerabilities.
So until I trust a site there's no chance I'd let it do anything fancy.
For the unfamiliar, there are some interesting blog entries on the subject:
Protecting Your Cookies: HttpOnly
Cross-Site Request Forgeries and You
Sins of Software Security
Top 25 Most Dangerous Programming Mistakes
I'm going to have to make a case for the other side here. Peoples reasons for designing sites without javascript are largely idealistic. Given an enough time and money and the goal is achievable and will certainly open your website to the largest possible number of people. However in reality doing this will slow your development, increase the number of test cases that you have to deal with, and ultimately affect the quality of your application for those users that do use javascript.
In my opinion it is perfectly reasonable to choose to make your site only compatible with js enabled browsers and tell those users that dont have it that they are missing out. This allows you to concentrate on creating rich content that the majority of users will be able to view.
There are of course exceptions to this rule, but if you are looking to create a good website for the majority of users, or have a client who is after a flashy website with limited time or money then taking the decision that it is js enabled browsers only is a reasonable thing to do.
The real question is not whether it is relevant, but whether to use Graceful Degradation, or Progressive Enhancement as your scripting strategy.
I'm actually in an interesting position when it comes to graceful degradation of JS. I'm working on a web application that bots and crawlers have absolutely no business looking into. There's nothing they can gleam that should be indexed.
The informational site accompanying the web application, however, should be indexed, and therefore JS degrades gracefully there.
In the web application, if you don't have JavaScript enabled, you're probably not supposed to be there. It's intended to be a rich interactive experience. The web application actually requires JS to be enabled, and for you not to be sitting behind a corporate firewall.
We're not serving anything malicious, its just our intent and purpose for the web application that's different. The goals of our web application and those of our informational site are completely different.
I use JavaScript. I always keep my browser up-to-date. But sometimes, my Internet connection is so bad that scripts just don't load.
There are also cases when:
Some scripts load, but others fail, in which case parts of a website stop functioning
Scripts are loading, but I want to hit "submit" without waiting for that fancy frilly menu
A script malfunctions because it was partially loaded and then cached at that half-stage
I'm in such a hurry that I just decide to use Lynx.
Now, I'm not saying my Internet is bad all the time, or even most of the time, but it does happen. With the Internet expanding rapidly to many rural areas across the world, I'm sure I'm not the only one. So apart from bots as Nelson mentioned above, it's another thing to keep in mind. (Hint: check your demographics).
If you don't want the page to work when Javascript is off then just have that be the message in html, and if javascript is on, by using unobtrusive javascript you can get rid of that message and make visible the rest of the application.
Depending on what you write for, in terms of javascript version, you may need to degrade if the browser the user has doesn't not have the latest version, so gracefully handling that is also important.

Is it safe to assume Javascript is always turned on? [duplicate]

This question already has answers here:
Closed 13 years ago.
Duplicate:
Do web sites really need to cater for browsers that don’t have Javascript enabled?
Only supporting users who have Javascript enabled.
How common is it for Javascript to be disabled
How many people disable Javascript?
I've been doing web applications on and off for a few years now and each application I write seems to have more javascript than the previous one.
A frequent comment is: "But what if the user turns off Javascript?".
I take the point, but I've never actually seen a user do this. Not once.
Have you?
This comes up about every other week or so. Did you search first?
See these:
https://stackoverflow.com/questions/121108/how-many-people-disable-javascript
https://stackoverflow.com/questions/379735/how-common-is-it-for-javascript-to-be-disabled
Only supporting users who have Javascript enabled
Do web sites really need to cater for browsers that don't have Javascript enabled?
The main points are:
Google doesn't use javascript when indexing
Mobile browsers (smart phones like the iPhone) sometimes have bad or non-existent javascript
Screen readers don't do javascript well, if at all, and many developers are legally required to support them.
Thanks to filters like NoScript, the number of people browsing with javascript disabled (at least initially) may actually be going up.
So yes, you still need to worry about it.
It depends entirely on what sort of coverage you require.
Do you need 80% 90% 100% of users to be able to use your site / application?
People DO turn off Javascript. The question is, does your site need to work for those people? Can it just tell them to turn it on if they want to continue?
Yes, it happens.
NoScript is a Firefox add-on - downloaded by plenty of people.
No Script
You should always make sure your site works without javascript.
People turn javascript off for security reasons. Companys sometimes have javascript forced off at their inhouse computers. Also spiders don't have javascript so your site not working without javascript is bad SEO practice.
5% of users have JavaScript turned off.
It has become a standard at my office (for better or for worse) to assume that the user has JS installed and turned on. The number of people who have it turned off is getting smaller and smaller every day, but this still doesn't mean that you should forgo performing the necessary validation for submission on the server side as well just in case (as well as some other scenarios).
I would say that it is not safe to assume javascript is always on, but it is safe to REQUIRE javascript be turned on.
In other words, you don't need to jump through hoops to make something work without it, just display a message or redirect.
Javascript is an essential technology, and it's not unreasonable to require it.
It's rare, but it's possible. If you are launching an application for "everyone" to use on the internet, then yes, you'll have to prepare for such an event. It really depends on your target audience, but the safest assumption is that someone will have it turned off.
From a security perspective, you definitely need to handle this situation, as turning off JavaScript (or worse yet hijacking the scripts you wrote) is an easy to bypass business logic and validation, if it isn't double checked on the server. Requiring it to be turned on is not a good enough defense for stopping people in this situation. Remember you're requesting that the browser tells you what it enabled and disabled. The user (or attacker in this case) is in control of the browser, and you can't trust what it says as it's easy to modify the HTTP headers.
Depends on who your target audience is. Some users turn off JS for various reasons. Usually, they will enable it for individual sites that need it, but they might not do that if you don't tell them they need it.
If your site just fails to load correctly, they'll assume it's broken. If it shows a "you need JS to view this page" message, then at least they'll know what to do.
Some will then enable Javascript for your site specifically, but some won't, and they simply won't be able to use your site, unless it is functional without Javascript.
It's rare, but it happens. It really depends on who your user base is. If it's for corporate users, a lot of them have default security settings with javascript disabled. If it's for... pretty much anyone else, odds are they'll have it turned on.
I run by default with javascript off for new sites (NoScript) plugin. I think many tech-savvy users do the same. At least the ones who are paranoid about XSS attacks.
It is best practice to code for users that have JavaScript turned off.
As web developer your goal should be to provide the core basic functionality (without JavaScript). This enables all users to fully use your site. Then through the use of JavaScript, in a process known as "progressive enhancement", spruce up elements of the site for users that have JavaScript turned on.
And in the case where JavaScript is off...your site should gracefully degrade.
Web development is one of those arenas where you can't expect anything. Code for all users to maximise your site's accessibility.

Categories