During the past few months, I've been working on a large web application. Repeatedly, we've written code that, according to DOM & JS specifications, should work perfectly, but still manages to completely kill one or more of our test browsers -- recently, we produced pure JavaScript code that should have been harmless but causes General Protection Faults in IE8, other pieces of code that completely freeze Safari, etc.
Well, we'll solve each issue, item by item, with as much blood, sweat and code as it takes. But the question I have in mind is the following: is there a knowledge base on such browser frailties? Something comparable to quirksmode.org, but with guidelines on how to code stuff to avoid killing our browsers?
Thanks.
edit Precision: not that it changes anything to the question, but we're using jQuery.
You've probably already been down this road, but most of the major libraries like jQuery, Prototype, YUI, Closure, or any of several others are going to have run into most of these issues and coded around them for you already.
If you are writing manual DOM/JS, please use a library as T.J. Crowder mentioned. These libraries solve nearly all the common inconsistencies between DOM libraries and make a usable sugar sweet API layer on top.
I have listed a bunch of websites that document cross-browser bugs in a previous answer.
Related
A rookie here.
Messing with my google scripts projects I have found a strange thing, a method that I was using was strike-through in the editor and it looked like this --> substr . Researching, I found that it is because this method is being deprecated. And for people looking how to solve it look the documentation in developer.mozilla.org.
At first, I had no problem with this, but, if it was not there before, and it is now, that means that the version of javascript that my project is using is changing and I do not want that. And there is my question
Is there a way to make the version of V8 JavaScript that my google script uses constant?
Looking in to the app-scripts documentation I have found that it uses V8 and that it is defined in the manifest but the way of freezing to a certain version is nowhere to be found. Maybe there is an easy answer, but I have no clue where else to look. Any help will be welcomed.
No, there is no way to select a particular V8 version for your GAS.
That said, JavaScript engines are generally very conscious of backwards compatibility. It is extremely rare that features are removed -- there are a good number of "legacy"/"deprecated" things in JS that won't be removed for the foreseeable future, because there's too much old and unmaintained (but still used) code out there that depends on them, and browser makers don't want to break that code.
Regarding the specific case at hand, I personally would be quite surprised if String.prototype.substr ever got removed. I see its deprecation as more of a "pro tip: how not to confuse substr and substring: only ever use one of them".
FWIW, V8 itself has no notion of deprecated JavaScript features. The strike-through you see is just an editor feature. Updating or not updating the V8 version underneath wouldn't affect it.
Taking a step back: writing software once and then expecting it to work without maintenance or monitoring for decades is, unfortunately, generally not a thing. For instance, if you developed a game for Windows 95, you'd have to expect that it won't run well (or not at all) on modern Windows versions. There are countless more examples of operating systems, SDKs/toolkits, compilers/engines, and programming languages themselves evolving over time in ways that guarantee backwards-compatibility for a couple of years but not forever. This is the flip side of technological progress. Pinning yourself to certain outdated versions is generally not a viable solution, for a variety of reasons.
So actually, in comparison, when you write an app or script in JavaScript, you have a very high chance of it still working fine 20 years later. So I wouldn't worry about it too much.
Though 99% of the code on our site is the work of 1 programmer, recently for the first time (and probably last) a programmer was hired to work on our site, he was given remote access to log in via ftp.
Background: He is located in a continent unknown to us, speaks a mothertongue that I cannot guesse from the English mails, and works in ways that are bit different than ours. It seems, this common workflow in long distant small projects where the original programmer is essential to update/customise their code.
Problem: The genius writes like a hacker, good quality but very poorly documented, some bugs occuring here or there. Now we are stuck with almost brilliant code with some bugs. Its Javascript mainly.
Question: First of all 1. What ways/utilities/websites are there to find bugs in freshly delivered JavaScript code, when its difficult to understand parts of thes code to begin with? 2. What are good code comparison programs/utilities/websites sothat one can vew in parallel side by side comparison differences between two versions of code?
Obviously both are very related so hopefully there is one great tool on this planet that aims to combine bug finding as well as shows you the differences between versions.
Any suggestions are good answers to me as I have no clue where to start from here.
I agree with the posts above, Firebug for Firefox and Google Chrome/Chromium's Web Developer tools are great for most JavaScript debugging purposes. IE8 has an o-k set of Developer Tools. I'd only recommend using them if you're having issues in IE-only, otherwise, the previously mentioned tools will perform much, much better. If you really want to run the JavaScript through the error-checking and code-quality gauntlet, take a look at Douglas Crockford's JSLint.
It's also worth mentioning community-driven JSHint as a resource for testing JavaScript code. It's not as strict as JSLint and has better support for commonly-used JavaScript libraries.
The Windows applications listed above should work great for comparing files. If you're on OS X though, Kaleidoscope is a wonderful comparison app. It costs a little money, but it integrates very nicely with most versioning systems.
I agrre with #BiAiB, about the need for a code management/versioning tool - this will save you hours of heartache.
Another excellent file comparison tool is Beyond Compare - it truly is worth every penny that it costs (which is not much)
Probably the best tool to help in the discovery of what is happening in your JavaScript code is Firebug, a plug-in to Firefox. Google Chrome and IE have similar functionality, although each solution may lack feature (or have extra features) that the others don't.
And, I agree with everybody else - you need source control in a big way.
For file comparison tools, there is also the excellent and free WinMerge
Eclipse can do compare.
JsTestDriver is a wonderful testing tool.
But you will need to write unit tests for it.
A great tool is using firebug and the Webdeveloper toolbar plugins for mozilla firefox.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 12 years ago.
Improve this question
I am working on my first project that requires me to worry about cross browser compatibility. Since this is my first time doing so, I dont know how to go about completing the project. I am specifically worried about IE. Should I complete my project in a more graceful browser then hack it to work in IE, or should I simultaneously build my program up in both environments?
Design your site to work in standards complaint browsers first. I always start with Firefox, even when developing on my company Intranet (where everyone uses IE). Doing so will let you focus on getting your markup and CSS correct. This is what is most important.
The important thing to note is that you'll want to "future proof" your site, and concentrating on a standards compliant browser will help you do that.
Then, once you're confident your site is looking correct (validators are your friend!), try it out in the versions of IE you want to support. In order to get your layout to look OK in IE, I strongly suggest using different stylesheets for each version of IE, using conditional comments.
Also, you should note that many others have been in the same scenario as yourself, and there is quite a bit of help available. One popular method of forcing IE to behave is the ie-7.js project.
Lastly, be mindful of the top IE bugs, such as:
IE6 Box Model Bug
IE6 transparent PNG images (I have used this fix in the past)
A few tips:
Code to Standards — Start by ensuring that what you've just developed works in Firefox and Chrome, and then verify it in IE. I'll usually then check it out in Safari. It's always better to make sure your markup/code works in a more standards compliant browser first.
Validate Early, Validate Often — You don't want your design to look perfect in one browser, find out that it's broken in another, discover that to fix the broken layout you needed to correct some invalid HTML/CSS, only to find that now the first browser looks wrong.
Progressive enhancement — will be your friend. Start basic, with simple HTML and simple CSS, and no JavaScript whatsoever. Repeat tips #1 and #2, then move on to more complex styles and layout. Contiue this iterative process until you are happy with the design in all browsers. Only then should you consider JavaScript to polish the site.
Check each browser often — Don't develop the entire website in a single, compliant browser like Firefox, and then decide to "see what's broken" in IE. If you've got a complex, dynamic website, there could be MANY problems in Internet Explorer. Trying to decipher each one when they are compounding on each other is a nightmare.
Reset Stylesheet — As #Eir mentioned in the comments, find a good reset stylesheet. Although, they have fallen out of favor for some people, I find putting every browser on the same footing from the start helps tremendously.
Use a Framework — I find CSS Frameworks to be excessive, but some people swear by them, so to each his own. On the other hand, as soon as you have made it to the JavaScript phase of development, I highly recommended using jQuery or MooTools. They are very focused on circumventing cross-browser inconsistencies.
Let JSLint hurt your feelings — Even when using a JavaScript framework, there are certain standards of coding to which JSLint will help you conform. Some of the options are a bit overly strict, but I promise that if you clean your scripts through this tool often enough during development, you will almost never encounter those strange times when everything seems to work in all browsers except IE.
And some great tools! Everything in the above list you should consider mandatory practice. The following can spice it up for you in a pinch, but is optional:
CSS Browser Selector — it is rare that you will need this, but if all else fails, it's way cooler than using a separate stylesheet just for one browser (I despise conditional comments). It basically adds classes to your <html> tag, so you can do things like the following in your main stylesheet: .ie7 #header {/*stylese here for IE7 only*/}. It supports a lot of browsers on many operating systems. And it's fast.
Browsershots — Nothing beats the real thing, but if you can't install a suite of browsers, this and other tools like it can help.
IE6 CSS Fixer — I outright refuse to debug my designs in IE6. I coerced my company (via many chagrin-filled meetings with IT and management) to drop support for it (thank god). It's just counter-productive to waste so much time forcing this pile-of-ahem... Anyway, if you aren't like me and need to support IE6, this tool can help.
Also you should focus on resetting css like this
OOoooo, good question:
here's my take:
Decide which browsers you are supporting. I suggest IE 7 + 8, FF, Chrome and Safari as in order of importance. (only support IE6 if you absolutely have to!). It helps if you know your userbase here.
Use a css reset. Different browsers have different default styles. a css reset gives you a consistent base.
Keep your markup as simple as possible. Follow Standards (and see progressive enhancement on Stephen's answer).
Test every step of the way on your target browsers. That way you can correct problems right away. http://crossbrowsertesting.com/ is the best resource for this, but there are free ones for screenshots as well.
Avoid Hacks as much as possible. Most cross-browser issues these days can be solved without resorting to hacks.
Ask questions here when you get stuck. If this is your first project dealing with browsers, you will get bewildered by inconsistencies. We all face these issues, and are glad to help.
Be ok with the fact that webpages are not going to look exactly the same in all browsers. (once again, see progressive enhancement).
Good luck coding!
I develop for Firefox first, and then work out the IE buggery. Rarely do I "hack" it, rather find something that works in both, or at worst use IE conditional comments. Just one coder's preference. Always a good idea to test with Safari, too.
Two big advantages of Firefox are: the Error Console, and the Firebug plugin.
there is alot of greate tools that makes life alot easier for you there is for example a
css framework called blueprint you could use, it has already everything set for every specific browser so that you get the same outcome in all browsers. And using jquery as your javascript framework does add an extra insurance that you'll have it working in most browser.
but remeber there is no such thing as 100% cross browser compatibility for all the browsers and all the versions in world.
In theory would be best to develop for all browsers at once, always testing for every browser...
Realistically, that rarely happens... I typically develop/test with firefox. when I introduce complex javascript or css, I check in ie... this tool is incredibly handy for checking all versions at once... google ie tester.
By checking all browsers at regular intervals, and when you make complex changes, you ensure that major features are compatable :)
Also, ensuring that all of your code is valid is not only good practice, but helps identify cross browser issues.. google w3schools validator :)
Using javascript libraries such as jquery also aid in cross browser compatability, and some even come with css libraries as well. These libraries are purpose built for quick, reliable features that are typically cross browser guaranteed.
Finally, before launching, use launchlist to check that all works: http://lite.launchlist.net/
Hope all that makes sense and helps with your first project :)
what basic tips should we observe in design web pages(html/css/javascript) for having highest compatibility with most browsers(IE-firefox-opera-chrome-safari)?
thanks
Validate often and squash all validation errors by the time you make a public release. The purpose of validation, after all, is to parse the html as a standards-compliant browser would and then avoid the errors that a browser's parser would find.
Apply progressive-enhancement techniques. Often that means moving some of the complexity of dynamic pages to the back-end (e.g. php, django, what have you) so that you can have complex functionality that doesn't break in one of the thousands of different client environments in which a page's javascript will run. jQuery is excellent for narrowing the focus of your javascript development towards feature enhancement instead of open-ended features-in-javascript, and it'll help with cross-browser compatibility as well.
IE - Test in at least one live version of IE 7 or 8. Unfortunately, there really isn't any way around this, because even IE8 misbehaves like no other browser. If possible, limit your goal of support for IE6 to html/css (i.e. don't promise support for user-enhancement-features via javascript in ie6). If possible, drop support for IE 5.5 and below.
For Javascript, use libraries that are intended on being platform-independent (ie: JQuery, Prototype). Not everything will be, but it'll make your life much easier.
For CSS, I'd say follow standards, but IE tends to cause problems across the board.
Which means, you need to test, and test often. Selenium is awesome for automated functional testing, and it works with pretty much every browser. We use a Selenium RC server on a Windows machine to test IE and Firefox, which are then controlled from our standard Java JUnit tests.
Keep things simple.
The simpler your markup, CSS, and JavaScript, the easier it will be to track down incompatibilities. Try to limit yourself to CSS1 for as much as possible. Only use more modern CSS2/3 features when there is no easier way to accomplish your task.
Don't use tables, they just add extra complexity. Using semantic markup not only makes things maintainable, but also gets you the best cross browser support if done properly.
Keep in mind that floats are evil, but are also very powerful. Use them generously, but avoid trying to clear floats. Use overflow instead.
Use a JavaScript framework. Framework developers have smoothed out most of the cross-browser bugs for you. I recommend jQuery, but you can choose any framework your developers feel comfortable with. My advice is to:
Use a JavaScript framework that doesn't alter the prototypes of native objects (like Prototype JS does)
Doesn't introduce many global variables. Most frameworks follow this rule.
Aside from those 2 rules for JavaScript, try using closures to encapsulate code so you don't introduce your own global variables.
One strategy I use is to start my CSS with a set of rules that blank everything out. Each browser may have different values for element attributes so ensuring that everything is consistent from the get-go can be handy. Here is an example reset.css
http://meyerweb.com/eric/tools/css/reset/
Take a look at this great article: Browser Compatibility Tutorial
Remember: something won't just work for a specific browser (mayble a left dotted border won't show in Chrome). Do not be upset about that if you can! :) Cross-compatibility is an art that takes a lot of time.
I am currently half-decided to use Kohana + Zend as needed for the PHP part. What I would need next is an excellent base for JavaScript code. There are a bazillion of contenders here and choosing isn't exactly as easy as with PHP.
I would need practically everything from form posting and retrieving results to skinnable widgets and animations. For this reason using multiple libraries will probably be a must, as no one framework can do it all. The requirements I have would be this (initial list):
Good browser support. WebKit-based is hardly an issue and Firefox 3+ is good. However, I'm looking at you Internet Explorer. IE 6 can be ditched, seriously, but 7+ support is needed.
Good performance. While WebKit has had a stupidly fast JS implementation for quite a while (and Chrome even before), Firefox has only recently got TraceMonkey and don't even get me started on Internet Explorer. While it is true that you can't do much about IE as anything will be slow, I don't want to try running Chrome Experiments in the others either.
Excellent support. This is a total must. The better the support, the more inclined will I be towards a library.
I am currently looking into jQuery as it is a very neat library, but the quality of plugins is questioned by some. Processing.js looks extremely promising, but IE does not support canvas, thus something has to be done about that and I am not sure how it could be replaced.
Go with a known library that is used by many sites. This will ensure all 3 of the points you have mentioned.
Personally, I would go with jQuery for these above reasons:
Great cross browser support
Good performance, as it is a thin api layer
Excellent support. Good documentation, loads of other devs
Although jQuery seems to be the most used library these days, there are other very good candidates as well.
One of them are YUI Library.
YUI has excellent documentation, and support. And the source code is really good.
YUI is developed by Yahoo!, where Douglas Crocford is architect (the author of JavaScript: The Good Parts, and the man behind JSON). Yahoo! is well known for their focus on JavaScript development.
YUI has good browser support and is fast and robust.
If it's war simulation and you have custom objects that you want to animate beyond the simple CSS effects and animations, then canvas tag is your best bet. It's as close as you can get to Flash but much more smoother. Processing.js looks really good for manipulating the canvas.
If that's the core component of your game, then I see the other libraries as adjunct to Processing.js that can be scrapped out without any deep commitments. That said, jQuery is great if you're dealing heavily with the DOM. It has really good support and community. MooTools is highly modular and has been traditionally strong with animations. YUI is a great library too, but a little verbose for my taste. Thought, Yahoo has made heavy changes with v3 to fix that. And a bunch of other libraries, that I don't use at all.
Dojo is a great library for writing web applications; however, never having written a game, I'm not sure if it is well suited for that sort of application. I must warn you though that the Dojo documentation is crap. Absolute crap. On the other hand, things like dojo.hitch, dojo.require, and dojo.partial are absolute joys.
I would try to avoid using cross-cutting libraries (like Dojo+jQuery) as much as possible. There's not really a good reason to do it and will create bloat and confusion in your application from day one.
That said, using multiple, non-overlapping libraries does make sense for a project like this. You might want to look into using Processing.js for visual needs and either Dojo or jQuery for your core.
Some other things to consider. Targeting IE, even IE8, for JavaScript game development is a bit ridiculous because of its slow performance and lack of canvas support. Also, according to John Resig, developing games in JavaScript is hard.
Have you considered being a pioneer (wink) and trying something out in 03D?