Related
I was looking at a "best practices" guide in relation to the inclusion of javascript in web pages (dynamic and static) which suggested that developers should always comment out javascript due to older browsers being unable to support the scripting language.
Is this true?
I tried searching for issues surrounding compatibility but could find nothing - I'm wondering if the information is out of date, as I've never heard of browsers having no idea what scripting is; a separate issue from javascript being deliberately disabled.
By "any" I obviously mean any non-discontinued browser.
Partial duplicate: What web browsers do not support Javascript? and how to identify which browser is client using?
Javascript is widely available, but there are some cases where you cannot rely on its presence.
First of all, the NoScript extension has been pretty successful - I'm not sure if it is still widely used, but you can except that at least a small portion of your users will use it (even if they whitelist your website later).
Another thing to keep in mind is that some browser just cannot implement a good Javascript engine. The best example which comes to mind is TTY-related browsers such as lynx.
Finally, don't forget that some people here are disabled, such as blind peoples, and have to use very specific browsers, which probably cannot work very well along Javascript.
[edit] About the specific "developers should always comment out javascript due to older browsers being unable to support the scripting language" question, I assume you're referencing the following pattern :
<script>//<!--
Actual source code here
//--></script>
Afaik, every modern browser knows what a script tag is, even if they ignore it. I'm not aware of any browser which prints script tag contents.
One of the major requirements for accessibility standards such as WCAG is that the web site or application displays without the use of javascript or provides some sort of non JS alternative. I did some initial research and couldn't find much information on this in regard to websockets. Should I assume websockets are treated similar to AJAX?
Since Websockets require JavaScript to do anything useful, if you have a standard that requires you provide a non-JavaScript alternative, you will need to provide a non-JavaScript alternative that doesn't use Websockets. Yes, Websockets are just like AJAX; they're really just a way to create a persistent, 2-way connection rather than a one-time, request-response that AJAX provides. You should treat them just like you treat AJAX.
While WCAG 1.0 requires that you provide alternatives to JavaScript, WCAG 2.0 is more technology neutral; instead of requiring an alternative to JavaScript, it provides a set of techniques for making web pages involving client-side scripting more accessible. You should keep in mind that not all of your users will have JavaScript enabled; there are still some users who prefer to browse with it disabled entirely or by default. But accessibility technologies today are able to deal with certain uses of JavaScript, so you can write accessible sites even when there is no non-JavaScript fallback.
Brian's answer is good, but I figured I'd add some additional insights.
There's really two issues here: technology, and compliance.
As far as compliance goes, if for some reason you need WCAG 1.0, then you need a non-JS version. Because WCAG 1.0 says so. It used to be the case that some screenreader users would disable JS because it caused problems for screenreaders, but that's several generations of technology ago. A recent survey of screenreader users on the web showed 98.6% with Javascript enabled.
As far as the technology goes, the issues with Javascript and accessibility really have nothing to do with Javascript itself: the accessibility issues have to do with the fact that something (usually Javascript) is manipulating the UI via the DOM. It's that manipulation of the UI that's at issue with accessibility; care must be taken to ensure that the resulting DOM is accessible, and that screenreaders handle the changes appropriately - eg using ARIA live regions to ensure that a screenreader will read out new content if that is appropriate, or that keyboard focus doesn't disappear and end up somewhere unexpected.
Any javascript that doesn't change the UI pretty much by definition will itself not have accessibility issues: so web sockets, web workers, local storage and so on do not in and of themselves have accessibility issues; what matters is if and when you update the DOM later on.
Is there any way to recognise pen pressure using javascript.
Preferably I don't want to make any use of Flash and try get this done as pure JS.
EDIT: okay I realised that it is kind of possible for Wacom tablets as they come with software that can work with their javascript api to make it possible (demos). But it's no good for people with Trust tablets or any other brand... So no good really.
Any body know how to do it in C# if not JS?
Yes - if the user has a Wacom tablet installed, then their browser will have a plugin for it that you can access. http://www.wacomeng.com/web/index.html
edit from author: I wrote this a very long time ago. Please see the comments below
Microsoft implemented something called Pointer Events in IE 11. It allows you to access pressure property along with stuff like pen tilt and size of contact geometry.
So far it only works on IE11 (and IE10 with vendor prefixes) but there is a W3C candidate recommendation so maybe it will be standard in future.
Javascript as a programming language in itself has no more ability or lack of ability to read this kind of data than any other language.
The language isn't important. What is important are the APIs available to you from within the language.
Javascript can be run in a number of different environments, some of which may possibly have access to APIs for this kind of hardware. However most Javascript is run in a web browser environment, and this is clearly what you mean.
The web browser environment provides a number of APIs. The most obvious is the DOM, which gives you the ability to manipulate the page, etc. There are other APIs available in the browser as well though. For example, the Geolocation API.
All these are standard APIs which have been defined by the W3C (or in some cases are in the process of being defined by the W3C), meaning that all browsers that support them should make them work the same way.
Unfortunately for you there isn't a standard API for working with pressure pads, so the direct answer to your question is no, it can't be done.
Whether one will become available in the future remains to be seen, but I have my doubts.
There is one way that you can do it though: ActiveX.
ActiveX is an API provided by Microsoft in older versions of IE. It basically provides a way of accessing virtually any Windows DLL code from within the browser.
Since the pressure pen device driver for Windows will be provided as a DLL, this means you should theoretically be able to access it in the browser via an ActiveX control. So therefore yes, you would be able to program it using Javascript.
The bad news, though, is that this is not something I'd recommend. ActiveX as a browser-based technology has long since been abandoned, due to the massive security holes it caused. I don't think the latest versions of IE even support it (I hope not, anyway), which means you'd be forced to use old versions of IE (and only IE - no other browser ever supported it) in order to run your code. Not ideal.
No, that's not possible. Probably not even with Flash.
You can only do so in an Native app. Javascript does not have access to pen pressure information
I want to program my xhtml Web Applications without javascript.
What are the alternatives for creating interactive xhtml web applications?
Perhaps java applets which do the tasks of javascript?
Or is there another way?
Thanks for any help!
Javascript is hard to debug, is dynamically typed, strange OOP, could be replaced by any other language when that language will be cut to work at a browser.
I would also like some typesafety in my code what can discover many bugs before running the code.
--EDIT 2--
Have a look at http://www.scala-js.org/.
---EDIT---
So for now there is no real alternative to javascript what is as flexible, widespread and applicable.
What i think is applicable are frameworks/tools who compile one language to another like GWT or coffescript.
Thank you for the detailed answers. The reason for my question was, that web development is getting more complex every day. I prefer languages like Java for stable error outlining and type safety. JavaScript on the other hand is (in my opinion) mysterious in its ways and hard to debug (browser incompatibilities, silent errors, unintuitive operands, dynamic typing,....). I developed Websites with JS for years now and it feels horrible to me due to such debugging problems and code management. Yet the libraries are quite powerful and ease much of the work.
To have an interactive site you need something that can execute code on the client machine.
This is (at the moment) usually JavaScript. In the past this would have also included Flash or Silverlight (both of which are now on the wane).
JavaScript has a big advantage in that it can easily manipulate the HTML elements directly. While it is possible to do that with Silverlight it's not as easy as Silverlight is designed primarily to build self-contained objects.
Google Web Toolkit GWT lets you write java code which compiles to client-side xhtml+javascript. It relinquishes the page-based standard web approach for a more desktop-like interaction (if I remember correctly the API is somewhat similar to many desktop windowing toolkits).
You may (but don't have to) also develop the (java) server logic and have some client-server communication baked in for you by the compiler.
Have a look at http://code.google.com/intl/it-IT/webtoolkit/
Some JavaScript alternatives:
Flash
Silverlight
Java applets
This is not a recommendation, just a list.
If you're really that allergic to JavaScript, there are a number of frameworks that let you write server-side code which generates the JS for you, as other answers mention.
Check out Google Dart - it has reached 1.0 recently, and has started standardization process few days ago (ECMA TC52). It also compatible with currently available browser via highly optimizing dart2js translator, so you can start using it right now :). Much more sane language than JavaScript, IMO.
More can find more information on the official page here: https://www.dartlang.org/ (tools, documentation, sample code, tutorials), and there is also nice introductory video on the YouTube: http://www.youtube.com/watch?v=FqsU3TbUw_s.
As well as applets you have Adobe Flash, Microsoft Silverlight, shortly Chrome NACL. None of these interact with the HTML DOM as seamlessly as JavaScript though.
One thing you can do is simply have the server-side code do all of the processing. You limit yourself to having only CSS available for interactivity, but you can still do just about everything by loading a new page.
If you're considering java applets, then I guess it's necessary to mention Flash and Silverlight (*).
Of course, there are "interactive" web applications that don't use javascript... they use postback. But I don't think this is what you mean.
If you want to target just Internet Explorer, you can use VBScript (Microsoft's proprietary javascript) or even ActiveX. But I doubt that's what you mean, too.
So the onus is on you to answer — why not javascript?
(*) I guess.
I'd be very interested to know what your reasons are for not wanting to use Javascript? The answer to that question will make a big difference to how your question should be answered.
The Javascript language is actually quite powerful. Yes, it does have some quirks, but so do all other languages. A lot of the perceived "problems" with Javascript development in the browser are actually people having issues with the DOM rather than Javascript itself. The DOM, on the other hand is where a lot of the shortcomings and the cross browser issues crop up.
If this is where your problems lie, then you may be better off using a Javascript library such as JQuery, which abstracts away a lot of the direct access to the DOM, and resolves a lot of the cross-browser issues.
If you're using the latest browsers, a lot of the simple effects that previously required Javascript can now be done using CSS. drop-down menus, tabsets, fading, rotation and transition effects. All of this can be done with CSS. However most of them are quite new, and not available in all browsers currently in common use, so you would be better off sticking to Javascript for at least some of them for the time being. Even when they are ready for mainstream use, you'll still need some Javascript to hook them all together.
If you do really have a burning desire to develop using a language other than Javascript, then as you already pointed out, there are other options for programming on the web, such as Java applets. There's also ActiveX controls, Flash and Silverlight, and a few others. However none of them are universally available to all users in the way that Javascript is.
All of them require browser plug-ins of one sort or another, and all of them have issues with users who don't want to install them or corporate environments that don't allow them to be installed. In the case of technologies like ActiveX, they may only be available on certain browsers and operating systems, and (again like ActiveX) they often have security issues.
The only real reason that most of these other technologies existed in the first place was to fill a gap in the capabilities of the browsers at the time. All of these capability issues have now been resolved -- with HTML5 and related technologies driven by Javascript, Flash and Silverlight have been rendered obsolete; ActiveX controls were considered obsolete long ago; and when was the last time you saw a Java applet in mainstream use?
The bottom line is that the browser world is moving very rapidly away from any client-side code other than Javascript, and there are very good reasons for that.
Use pyjamas (google it), you can write normal python code and have it compiled as javascript so you get the best of both worlds, the power and expressiveness of python and the ubiquity of javascript.
Also keep an eye on the Falcon project by Adobe, it's an experimental compiler which translates actionscript 3 (a very powerful language compared to plain javascript) and the flex framework to javascript.
You can also try GWT by Google, where java is used as the client side building code (and yes, it also gets compiled to native javascript).
If it runs on the client's computer and can modify the DOM, it can work. JavaScript is the most widely supported so it'll work out-of-the-box for many people.
Basically, anything which functions like JavaScript can replace it.
Flash can perform basically everything that JavaScript can (graphically, but it can't modify the DOM), but if the user doesn't have Flash Player installed, you're out of luck.
Java can also work, but the same concept applies: if the user doesn't have JRE (or a similar machine)
Silverlight is similar to Flash, but much less supported (I can barely get it to work on my Linux box)
Just curious: why are you looking to replace JavaScript with something else?
This may seem inane, but I actually like using jQuery much better than JavaScript. It makes event handling and Ajax very simple.
I'm not a JavaScript wiz, but is it possible to create a single embeddable JavaScript file that makes all browsers standards compliant? Like a collection of all known JavaScript hacks that force each browser to interpret the code properly?
For example, IE6 does not recognize the :hover pseudo-class in CSS for anything except links, but there exists a JavaScript file that finds all references to :hover and applies a hack that forces IE6 to do it right, allowing me to use the hover command as I should.
There is an unbelievable amount of time (and thus money) that every webmaster has to spend on learning all these hacks. Imagine if there was an open source project where all one has to do is add one line to the header embedding the code and then they'd be free to code their site per accepted web standards (XHTML Strict, CSS3).
Plus, this would give an incentive for web browsers to follow the standards or be stuck with a slower browser due to all the JavaScript code being executed.
So, is this possible?
Plus, this would give an incentive for web browsers to follow the standards or be stuck with a slower browser due to all the JavaScript code being executed.
Well... That's kind of the issue. Not every incompatibility can be smoothed out using JS tricks, and others will become too slow to be usable, or retain subtle incompatibilities. A classic example are the many scripts to fake support for translucency in PNG files on IE6: they worked for simple situations, but fell apart or became prohibitively slow for pages that used such images creatively and extensively.
There's no free lunch.
Others have pointed out specific situations where you can use a script to fake features that aren't supported, or a library to abstract away differences. My advice is to approach this problem piecemeal: write your code for a decent browser, restricting yourself as much as possible to the common set of supported functionality for critical features. Then bring in the hacks to patch up the browsers that fail, allowing yourself to drop functionality or degrade gracefully when possible on older / lesser browsers.
Don't expect it to be too easy. If it was that simple, you wouldn't be getting paid for it... ;-)
Check out jQuery it does a good job of standardizing browser javascript
Along those same lines explorercanvas brings support for the HTML5 canvas tag to IE browsers.
You can't get full standards compliance, but you can use a framework that smooths over some of the worst breaches. You can also use something called a reset style sheet.
There's a library for IE to make it act more like a standards-compliant browser: Dean Edwards' IE7.
Like a collection of all known
javascript hacks that force each
browser to interpret the code properly
You have two choices: read browser compatibility tables and learn each exception a browser has and create one yourself, or use avaiable libraries.
If you want a javascript correction abstraction, you can use jQuery.
If you want a css correction abstraction, you can check /IE7/.
I usually don't like to use css corrections made by javascript. It's another complexity to my code, another library that can insert bugs to already bugged browsers. I prefer creating conditional statements to ie6, ie7 and such and create separate stylesheets for each of them. This approach works and doesn't generate a lot of overhead.
EDIT: (I know that we have problems in other browsers, but since IE is the major browser out there and usually we need really strange hacks to make it work, css conditional statements is a good approach IMO).
Actually you can,there are lots of libraries to handle this issue. From the start of the time, javascript compliance issue always was a problem for developers and thanks to innovative ones who developed libraries to get over this problem...
One of them and my favorite is JQuery.
Before JavaScript 1.4 there was no global arguments Array, and it is impossible to implement the arguments array yourself without a highly advanced source filter. This means it is going to be impossible for the language to maintain backwards-compatibility with Netscape 4.0 and Internet Explorer 4.0. So right out I can say that no, you cannot make all browser standards compliant.
Post-netscape, you can implement nearly all of the features in the core of the language in JavaScript itself. For example, I coded all methods of the Array object in 100% JavaScript code.
http://openjsan.org/doc/j/jh/jhuni/StandardLibrary/1.81/index.html
You can see my implementation of Array here if you go to the link and then go down to Array and then "source."
What most of you are probably referring to is implementing the DOM objects yourself, which is much more problematic. Using VML you can implement the Canvas tag across all the modern browsers, however, you will get a buggy/barely-working performance in Internet Explorer because VML is markup which is not a good format for implementing the Canvas tag...
http://code.google.com/p/explorercanvas/
Flash/Silverlight: Using either of these you can implement the Canvas tag and it will work quite well, you can also implement sound. However, if the user doesn't have any browser plugins there is nothing you can do.
http://www.schillmania.com/projects/soundmanager2/
DOM Abstractions: On the issue of the DOM, you can abstract away from the DOM by implementing your own Event object such as in the case of QEvent, or even implementing your own Node object like in the case of YAHOO.util.Element, however, these usually have some subtle changes to the standard API, so people are usually just abstracting away from the standard, and there is hundreds of cases of libraries that abstract away.
http://code.google.com/p/qevent/
This is probably the best answer to your question. It makes browsers as standards-compliant as possible.
http://dean.edwards.name/weblog/2007/03/yet-another/