I just want to make sure, that I haven't missed something in the past years.
Today a customer pleaded me to find an autosaving solution, which works even if the user has disabled JavaScript in her browser.
I answered: "This is impossible", because afaik it is not possible at all, to periodically submit form input to a server using only XHTML, i.e. without the help of some scripting (e.g. using setInterval() and/or the onunload event).
Is it still impossible? Or is there s/t, I'm not aware of yet?
If you want to get the data to the server, then having the user manually submit the form or using JavaScript is the only way (discounting less well supported scripting languages, or replacing the entire form with something that depends on a plug-in).
If you want protection against a browser crash without using JS, then you have to depend on the browser having the feature built in. You can't add it yourself.
In short: You are correct.
I'm working in a web mobile application to support a mimimal subset of operations for an existing website.
My base tools are, asp.net 4.0 with simple css to try to archive a more extensive range of devices.
My questions are:
- I'm in a good direction? ... or ther's a better way to do it? (other kind of controls, etc..)
- My device (mobile) is a Nokia e71 and i'm starting to see some glitches:
- autopostback properties dont work
- clientvalidationscripts dont work
Please give me some hints and advices. Thank u all.
Are you using the Mobile controls in ASP.NET, or just the regular ones? There is a separate set that are intended to support and adjust to various mobile devices somewhat better.
For a first-effort mobile site, I would look either at a well-established mobile framework (to be honest, I've never extensively used the ASP.NET Mobile Webforms controls), or to do something where I'm building my own HTML much more directly, to be sure to keep things mobile-safe.
That's one of the reasons I use ASP.NET MVC more myself, now... but that is a bit of a leap to make, and especially if it would just be for mobile use.
So anyway, if you are already using the ASP.NET Mobile controls, my answer is irrelevant!
Always, regardless of the type of website, design for "Progressive enhancement".
In other words, get everything working using the minimum (no javascript, very simple CSS). Then progressively enhance it so that additional functionality is available to those with browsers that can support it.
Many ASP.NET controls have javascript behind them. Ensure that you design so that they continue to work without javascript, or use other controls that don't require javascript at all.
WRT your client validation - You should always validate on the server side as well. In that case the fact that on some devices the client validation isn't running makes no real difference.
Do not use any asp.net control on a mobile site, .net rendering by device usually screws things up.
Do not use .net server forms.
If you can use MVC
Simple javascripts should work most of the modern devices.
Ajax works too but don't use jQuery, write simple ajax post/get functons
This question already has answers here:
Closed 13 years ago.
Possible Duplicate:
Is it worth it to code different functionality for users with javascript disabled?
I've just learned in this question that an ASP.NET webforms application will have issues to run properly in a browser with disabled Javascript (unless I don't use certain controls and features).
So this is a kind of a follow-up question. For my current web application which will only have a small number of users I can postulate to enable Javascript.
But how to deal with this question in general? As I can see (with my rather small knowledge about web development until now) Javascript is all around, especially the more a web site is "dynamic" or "RIA" like.
Is it worth at all to take care about the few users during web app development who disable Javascript in their browsers?
Are they really "few"? (I actually have no clue, I just don't know anyone who has Javascript disabled.)
I'm a bit inclined to tell them: "If you want a nice interactive page, don't disable Javascript." or "You cannot enter this website without Javascript. Go away!" Because I don't want to double code and development time for some mavericks (if they are mavericks). Does it indeed add a lot more time to get a website working with Javascript and without Javascript as well?
For what reason does someone disable Javascript at all in his/her browser? Well, I've heard: "Security!" How unsecure is Javascript actually? And does that mean in the end that millions of pages are unsecure and almost every website I am using is a risk for me? Are there other reasons except security?
Are there any branches or environments where it is usual or even mandatory to disable Javascript for security (or other) reasons? (For instance I have security services, offices in defense ministries or a bank in mind.)
Are there any trends in development to see to add more Javascript to web sites, thus making it more and more necessary to let Javascript enabled in the browser? Or is there rather a counter motion?
Thank you for some feedback in advance!
Whether or not to care about users who turn off javascript should be done on a case by case basis. If you believe that it is ok to turn away users that do not have it enabled then that is a decision that you can make and is made by many apps.
Keep in mind that it is not necessarily a conscious decision to have javascript disabled or at a limited capacity. Screen readers, for example have a very stripped version of javascript and a site that uses it throughout will often be inaccessible. Depending on the website, this may actually be illegal.
If a website is properly constructed with progressive enhancement from the beginning, then creating versions that work without javascript should not be too much additional work. Therein lies one of the major issues with webforms - it is difficult to gain control over markup and javascript tends to be very tightly coupled.
My personal view is the number of people who completely disable javascript to the extent that .net web sites stop functioning is very small - For some government sites I have been responsible for, I don't recall getting any complaints from "non-javascript" users.
My concern would be more about making sure your site was xhtml compliant, with valid markup (which earlier versions of Visual Studio did not generate), valid css, and intelligent use of javascript.
Having a disclaimer somewhere on your site - that is accessible to those few with javascript disabled telling people that javascript is required for the site to function correctly would be a good thing.
Depends on your audience. For one thing, if the site is completely nonfunctional without JavaScript, accessibility (e.g. to those who must use a screen reader) may be an issue, so if you expect any blind users, you might need to consider that.
In most situations, I'd say, you're probably fine just using <noscript> tags to drop in a quick disclaimer along the lines of "JavaScript is required to use this web site."
While I have no solid numbers -- and I presume I'm in the distinct minority -- I, and many of the more savvy users I know, disable JavaScript by default (a la NoScript). I enable it on websites on a case by case basis. Most novice users (I'm ignoring the 25% in the upper/middle of experience) don't even know what "JavaScript" means.
As a developer I see the cost/benefit of supporting JS-less users
as boiling down to one question:
Do your users need the site more, or do you need your users more?
One of my current projects makes heavy use of JavaScript and Flash and does not function at all without it. But as it's installed at the employer's site and the visitors are the employees using it for their job, that requirement is completely reasonable.
However, if I were working on a revenue-generating site where losing users meant losing money, I'd seriously think about crafting the site to work w/o JS -- albeit less quickly with more page reloads. (Perhaps by asking advice here.)
As a random thought -- you could probably devise a special method to determine how many of your current users do and don't have JS enabled.
I'm using some ASP.net controls in my project especially WEbcombo,Grid(for inline editing) and i face t working good in firefox and IE6 but not in Safari(throwing exceptions).
so i just wanna know or want a list of ASP.net controls which could not work(if any) in safari(not compatible)
Can u help me in this?
Or do u have anything like which can be included in the ASP code so that i dont have browser compatibility problems (like any code to be included in web.config file OR sumthin )
Do i make sense ?
Here is a good link for debugging in the Safari browser. If you are dead set on setting compatibility, you might need this. It focuses more on javascript but people around the campfire say it's good general knowledge. I do not pretend to be an expert in anything Safari, but might be a step in the right direction. Also this article handles a few more asp .net Safari issues.
ASP.Net is a server side technology. This means that controls are rendered to HTML by the server before being sent to the browser. So in most cases, you shouldn't have to worry about what the browser is doing when it comes to ASP.Net controls. Instead you only have to worry about differences in HTML rendering.
When does it become unavoidable and when would you want to choose JavaScript over server side when you have a choice?
When you need to change something on your page without reloading it.
Designer perspective:
When you want to give more interactivity to your web page
When you want to load stuff without reloading (i.e.: ajax for example)
When you shouldn't use:
When You don't want to spend 1000 hours in pointless tries to disable the back arrow of your browser :)
Google maps would not have been possible without JavaScript. At least not in the form we know (and love) it today. So, depending on your ambition (and requirements) clearly: sometimes JavaScript is unavoidable, even though there exist technologies that take another approach that might have worked equally well (Java Applets, RIA technologies, etc).
If I had the choice I would probably chose JavaScript over a server-side implementation for a large number of applications, but then again, it is not a black or white picture. The server will remain important for web applications for a very long time to come.
Yes, you do. Now take out your textbook and turn to Chapter One. ;)
Honestly, though, to answer your question, I don't think it's ever "unavoidable," no; you can always code for the absence of JavaScript. (Indeed, usability best practices dictate you at least try to "gracefully degrade" the user experience for browsers that don't support it, or for users who choose not to.) In the beginning, of course, there was no JavaScript -- but there was still the Web. It just, well, kinda sucked.
There's no simple answer, but if you absolutely must have one, the most straight-ahead one I can think of is to use JavaScript to improve the user experience. Secondarily, use it to shift the workload from your server toward the browser (Hello, Ajax!) -- validation, state, etc. Those are two big reasons, broadly stated, IMO.
At a stretch, you could do everything via server-side programming. Some things will be painfully slow and difficult to pull off right, but it is possible. If you want to see something clever done with nothing more than CSS, try out the search feature on lxr.mozilla.org with scripting disabled.
Practically though, the best places to use javascript are where it'd otherwise disrupt the flow of what the user's doing - the AJAXy things on here are all pretty good examples, as is the realtime preview (everyone should have one of these!)
If it provides significant benefit, then it's completely fine to use it. But please, don't make it required unless the server-only equivalent is needlessly complicated.
I never want to choose JavaScript, but it becomes unavoidable when clients want a decent web app. JavaScript has the unique feature of low latency feedback in a browser - server side code doesn't.
Also, there are a (rather limited) number of times when it's actually easier to bust out some JQuery for formatting rather than dealing with ASP.NET's event model to manipulate client elements. But, I'd say those are relatively few.
If you are looking for a responsive UI and want to avoid JavaScript, consider some of the RIA technologies such as Flex, Silverlight or JavaFX. I've been developing with Flex since v1.5 and find it very capable and productive. Silverlight is getting significantly better with each release, too.
GWT is a nice system that compiles java code into javascript which becomes kind of like a "Machine language" for the browser--you never have to consider it.
I believe most google apps are written using GWT. It's pretty slick.
All your source code is pretty much straight Java using a library somewhat like Swing.
JavaScript is not a necessity but, coupled with the DOM API, it provides a very useful medium for gradually improving the user experience of your site. Obviously the extent to which this is true is dependent on how well you execute these enhancements, don't just use JavaScript for the sake of it; it's a design decision, and should not be taken lightly.
Sharing the load between client and server.
Try to keep it natural. Use it to enhance little things, do not built your whole application on JS.
A good way to measure the breadth of your skills is when "Do I have to use ..." starts disappearing from your conversation. Hopefully you get to the point where a language is just a language, and you develop a feel for what the right tool is for the job, and can use it as comfortably as any other language.
If it's any consolation, there's increasing evidence that there's enough conventional wisdom and available toolsets that developers are increasingly preferring javascript. I personally like it for its conciseness and easy exensibility - once you get to know it.
You don't have to.
But if you want to provide UI extras like autocomplete, drag and drop, richer form entry fields, etc.…, Javascript is your only answer.
Of course you can abstract that Javascript generation out to the server side but you'd still be tussling with Javascript, albeit via programmatic code generation.
When you create a Rich Internet Application which gets loaded into a browser and which communicate to a Web Server with an Open API (like SOAP, JSON etc)
"Javascript over server side " JavaScript is client side, not server side.
You would still need to run server side stuff to get the data from the server. Javascript just gives you more control on how the client receives the data from the server.
JavaScript is unavoidable when you want a certain dynamic feature on your website which is not supported by default.
Dynamic feature
- without JavaScript: you can use CSS to change background of an element when the mouse is over the element. You can do the same thing with using JavaScript.
- Only in JavaScript: When you click the element with your mouse, the element disappears. Don't think it is possible in CSS(maybe you be able to use :active in CSS on some elements. Never tested it myself).