I am working on a project to convert a web site that is fully functional in Internet Explorer 8 and lower, but does not work well in Firefox or Safari.
A lot of what will need to be changed is going to be javascript-related (aka methods that exist in IE but not in other browsers).
What I want to know is whether anyone is aware of a fairly comprehensive list of common things that have to be changed to work accross all browsers.
I am starting with quirksmode.org but I don't think it will have quite everything I'm looking for. If anyone knows of a list please let me know.
Your best option here is to go with a Javascript toolkit/library like jQuery, MooTools or Prototype. Such a decision will save you a monstrous amount of work, and all three are constantly being updated which gives you a large degree of safety against future compatibility issues. Especially for DOM manipulation or AJAX, a library is the way to go.
If you absolutely mustn't use one, quirksmode is a good start. I've never found any single source that is comprehensive enough to keep me from running back to Google for each problem area.
Quite honestly, if you don't have lots of experience doing cross-browser development, I suspect the best way to fix your app is to set up a good test environment on each target browser and starting finding where it breaks. You're eventually going to have to test it on each target browser anyway, so you might as well start there. Once you find out what code is failing you for a particular bug, you can do more targeted searches for how to work around that issue in a cross browser way.
You will, over time, build up a good internal knowledge base of what is safe to use in a cross browser way and what is not. Even experienced developers still run into new issues on every project that are only found with testing. One advantage of experience though is that you start to learn when to suspect that something might or might not have cross browser issues and either avoid it (find a safer way) or explicitly test it in several browsers before you use it.
I find that http://jsfiddle.net is awesome for creating very efficient self-contained test cases to either proactively try something in other browsers or to troubleshoot something that's been giving you a problem.
As others have said, one huge advantage of the various browser libraries like jQuery or others is that they have solved a lot of these compatibility issues for you and, in general, if they document a function in the library and don't explicitly warn you about cross-browser issues, then they've already done their homework to make it safe for you.
You may also find out that using a javascript framework such as jQuery, ExtJs, Prototype, Mootols, ... would be very beneficial in writing cross browser javascript.
a web site that is fully functional in Internet Explorer 8 and lower,
but does not work well in Firefox or Safari
I would strongly recommend to develop with a browser that meets the standards (e.g. CSS3).
The process should rather be: to develop with FireFox or Chrome - and fix all IE versions later on.
Well, this is my daily bread... and ordinary it's IE b*tch which makes me loose time...
Related
I'm getting into using IndexedDB. Thought I'd grab Parashuram's jQuery wrapper for it.
However, there doesn't seem to be a whole lot of information regarding IndexedDB lying around the internet.
Does anyone know what the I/O speeds are like on IndexedDB, preferably browser-specific? Is there any way to measure it? How would using the jQuery wrapper (as well as the polyfill shim to make it work in Opera/Safari) affect these speeds?
Reason I'm asking is I thought to store snippets of HTML content in the base, but maybe I shouldn't bother if fetching it would take longer than browser cache or similar.
It depends on the browser your are using.
My experience is that IE 10 is pretty fast, compared to chrome and FireFox. Try my QUnit test I wrote for my framework, and you will really see the difference. Of course this isn't a benchmark test, only test of functionality.
I am trying to validate the JavaScript on my website. The scripts do not throw any errors and run fine on Chrome and Firefox (latest stable version). However, the animated parts absolutely do not work on IE (9)[*1][*solved]. I have used jQuery and jQueryUI for the animation and had hoped that it would be cross browser compatible.
Usually I would not have cared abut IE users, but liked the idea of folks at anybrowser.org and thought of sticking to a standard instead of using the lowest common denominator and leave the graceful degradation to the browsers / JS engines. My page is HTML5 compliant according to the w3c validator and I wanted to do the same with JavaScript, but could not find an acceptable way to do it.
Why JSLint did not work -
It will not take the page and check it like w3c validator.
So there is no way to check jQuery referenced script. (There are a few SO posts on this).
I did find an ECMA-264 test page that would check the browser, but not my JavaScript.
The question after all the preamble is: How do I validate the Javascript on my webpage? Is there an authoritative validator for JavaScript?
*1 Added: The minification has nothing to do with the script not working on IE9. Even the unminified version does not work.
*Solved: The problem with the specific page was solved by this comment.
This started as "What is Javascript?" got closed here and migrated to Programmers. Thanks to YannisRizos for helping me to split the original question to something that was acceptable between Programmers and SO.
A test suite. No really.
If you want to ensure your javascript runs perfectly in every target environment, then you write a test suite for your code and make sure it passes in all your target environments.
A test suite helps find where your code breaks when run on different platforms. And therefore helps you fix it.
But assuming you want something that is less work, http://www.jshint.com/ is your best bet.
Or http://www.jslint.com/ if you like getting yelled at.
But honestly, no validator will ever be able to ensure that your code runs without error and exactly how you expect everywhere. Simply because your code follows best practices correctly, that doesn't mean it will work in an old version of IE.
Standards evolve, but an old browser that never updates get stuck with whatever standard was out at the time that the browser maker may or may not have even implemented successfully or accurately.
Testing, automated or manual, is the only way to ensure things work universally.
as I am getting more and more into Android PhoneGap app development, I can see more and more nuances and little details between built-in Android browsers throughout the versions. I searched for some official or fan document, which would deal with these browser version differences. But I can't find anything useful.
It's a lot frustrating, because you have to test everything on all versions of Android emulator and if app grows big, it's A LOT of work to test all the features in all versions.
Everyone is excited about HTML5, I was too, but only to the point when I moved to doing the real thing. I realized that there is so many problems when dealing with different versions of Android behaving sometimes a lot differently.
If anyone has some good resource to share, I would be very happy. Thanks
EDIT: Added example of different behaviour betweeen Android browser versions ( but there is many of them):
This works in Android browser in 1.6, 2.2, 2.3 and 2.3.3. But it failes (application crashes or stops JS execution) in Android 2.1:
Object.keys(var).length
You asked a pretty general question. The general purpose answer is that any sort of cross browser development (even cross versions of the same browser) requires that you develop a familiarity with what features are safe across the targeted browsers, which features are not safe across the targeted browsers and which ones must be used only with careful testing or feature detection with fallback.
While one wouldn't exactly expect the type of difference you saw with the one example you referenced, it is clear that that is a fairly new feature in ECMAScript and it's not consistently implemented across normal browsers so I would put it in the category where it is not safe to assume that it works on all versions of Android, even if you've seen it some versions of Android. That means to me that you should only use it if you've explicitly tested that it's reliable in all the browser versions you are targeting or devise a feature test and only use it when you know it's present and reliable or develop a safer work-around.
As I think has been mentioned previously, this thread has a bunch of proposed work-arounds for the specific issue you mentioned.
I am not aware of any detailed written material that would document in advance for you the details of the differences between different Android browser versions. Since it's open source, there are probably developer checkin notes and some level of release notes, but that will probably be like looking for a needle in a haystack and may not even contain what you want. It is rare for any developers to produce such detailed information. We don't generally get that level of detail from any of the existing desktop browsers or iOS browsers and, even if you were on the development team itself, you probably would only see part of this info. I don't think you're going to find official documentation that covers what you want.
You're going to have to learn to treat is as more of an unknown and learn what areas are "safe", what areas require extensive testing before using and what areas are just too risky. Even when doing that, you'll find Android bugs in some version that trip you up. That's just the nature of building on someone else's platform. At least the Android set of browsers are a much simpler target than trying to target all desktop browsers from IE6 to IE9, Firefox 3 to 5, Safari 3 to 5, Opera 9 to 11, Chrome 9 to 12, all Android, all iOS and use HTML5 when available which is what I'm working on.
Once you've been through this wringer a couple times, you will realize that if the newer language/library feature carries any risk, you shouldn't use it at all unless it's absolutely central to what you're trying to accomplish and then you will have to test the hell out of it. If it's something like getting the length of the associative array which is just a programmer's convenience, then it's probably simpler to stick with a work-around that is guaranteed to be safe and just not spend your time dealing with any browser-support risk.
The only official documentation I am aware of is part of the Android developer documentation. If I were a betting man, I would bet that it only covers a subset of what you are seeking.
The general idea behind cross browser Javascript is inline feature testing (at least how I've come to accept it.) I don't know exactly what "features" you are specifically looking for but it's generally wise to test for the existence of a feature set then use it and have a fallback if that doesn't exist. (Even if the fallback is, "This site requires a browser that supports 'foo'")
Since you didn't give any examples, I'll pick on Ajax. It's always best to check for the existence of window.XMLHttpRequest, then act upon it. Of course, this is not performant if you are doing it for every instance of need so you could write a check procedure or a wrapper to accept your list of necessity let your wrapper cache/call the appropriate methods to perform that task.
Without examples of "features" that you are talking about being different from browser to browser though, it's hard to give any concrete advice on direction.
Let me start by saying I really appreciate the work done at QuirksMode.org but in recent experience the content seems a bit dated.
Some pages haven't been updated from anywhere between 6months and a year.
Compatibility tables still only show chrome at version 5.0 (W3C DOM Compatibility) or 1.0 (Event compatibility tables)
In cases where content seems a bit dated I generally refer to Sitepoint's References, but their HTML and Javascript Reference pages are also a bit our of date.
What compatibility reference guides do you all use?
update
I'm aware of sites like CanIUse, which are invaluable reference new feature support like new JS API libraries and CSS3 support. However I'm more interested in things like supported attributes (bad example I admit) and browser events. The more vanilla stuff.
And please, noone mention w3schools (see w3fools why you should never use this site)
http://caniuse.com is quite good and (provided you use the correct keywords) has good search functionality as well.
In addition to the above you might be interested in the ES5 compatibility tables that Kangax maintains at http://kangax.github.com/es5-compat-table/
update
In the meantime there is also the ES6 compat table. Quite red for now (9/2014) admittedly, but getting more and more useful.
I trust Quirksmode, have you any idea how many tests PPK runs? It's not that it's outdated (yet!) it's that CSS support (and Browser uptake) has reached a new level, trust me you will appreciate the experience if you have to support an older browser.
Not every FF or Opera user updates quickly anymore which is what could be relied on for a while! - so yes you're right to question the findings. personally I look for recent sites too but I don't "trust" them nearly as much as the older and even then I tend to test for myself.
There's no replacement for experience IMO often these guys can "guess" at what may be the problem based on their past experience even if the so called "bug" or unexpected display is new to them in that context.
I have a "bug" report detailed on PPK's site - yea it and me are old - but only last week I got asked about something (seemingly unrelated) which turned out to be the same thing and have the same solution, it's IE7 related so will be with us for a while yet. (I see caniuse thinks that's old eeek!) - I am completely in awe of these guys who have kept up these sites for so long, if you can reverse engineer the bugs you get to understand the browsers.. that will never fail you as long as the browsers are on the go - their render engines don't usually change all that much between versions!
but then again this is a new era of Browser wars so who knows what will happen :)
Have a look at this big javascript compatibility table
http://compatibility.shwups-cms.ch/de/home/
Its very big, but checks at the moment only for existenz of javascript properties.
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/