running different JavaScript based on browser - javascript

Canvas clearing gets vastly different perfomance on different browsers. See http://jsperf.com/canvas-clearing2 .
I need to clear a canvas every frame and how I do it has a huge impact on mobile safari vs Desktop safari performance. Desktop Safari likes canvas.width = width but mobile safari prefers canvas.drawRect() .
Is there a way to detect what browser is what an run different JavaScript based on it? I would prefer to do this through JavaScript rather than server side.
Also, I've found that jQuery's $.browser doesn't help because it doesn't distinguish between mobile safari and desktop safari. the navigator object has similar problems.

Targeting specific browsers is always a bit of a problem. While there are certainly ways to do it, it's not a particularly maintainable way to do it because there are lots of different browsers and versions of each browser and those browsers change over time, thus which browsers are optimized by which code can be changing all the time. This creates quite a maintenance headache. For example, mobile Safari on an iPod Touch has very different performance characteristics than mobile Safari on each different generation of iPhone or iPad.
So ... instead of trying to detect the type of browser, it's much better to either do feature detection or performance detection and dynamically adjust based on how any given browser reacts. Done right, this can work equally well for all browsers, even browsers you've never seen or that aren't even released yet.
In your case, you could devise a quick performance test that tests the performance of each of your two methods. If there's really a big performance difference between the two methods, then you could probably tell the difference in a matter of a few hundred milliseconds, set a cookie on the local browser indicating the method that works best and then just use the preferred method in that browser from then on. If you wanted to, you could let the cookie expire every few months (so it would get retested every once in a while) or you could put the exact browser version into the cookie too and reruns the tests and set a new cookie if the browser version every changed (software upgrades).
In this way, your code would always be using the fastest version of your code in all browsers, now and forever without you ever having to maintain/test zillions of browsers to know which should be used for each.

I'm with jfriend00 on this if you're looking at longer-lasting, closer-to-sure-proof solutions. However, you can still pull quite a bit of information with certain functions in Javascript and use that to your advantage.
Check this out:
http://notnotmobile.appspot.com/
Other Resources
Navigator Object: http://www.w3schools.com/js/js_browser.asp
Browser Detect: http://www.quirksmode.org/js/detect.html

Related

How do browsers know where a user begins and ends text selection?

According to an answer to this question, it is technically very difficult to create selection ranges from the user's mouse position. Why is this? How is it that selections can be created from the mouse position in the browser normally, but creating the same range using JavaScript is difficult?
Because the browser can use whatever native OS methods it wants because it only has to work within it's own environment. Your Javascript code on the other hand is constrained by the functionality the browser decided to expose to external (i.e. your) code. This is usually constrained to what's in the published standards (give or take a little...or sometimes a lot). Your code needs to run everywhere, all browsers, all OS's, all devices. The browser code only needs to run on one OS, and often on a small subset of devices.
But - you might say - I can run Chrome, or Safari, or Firefox on different OS's and different devices. Yes, you can, but it's not the same code. They are different versions of the browser optimized for each environment. They may share a lot of code, but they also have significant differences, especially the parts that interact directly with the underlying OS.

How to debug web page rendering compatibility issues across browsers?

I am developing a web page primarily using Firefox. Often I encounter that my web page renders properly in Firefox but has some unexpected behavior in Chrome and IE.
Generally if its related to javascript, I usually open Developer Console in Chrome and see if there were any errors and that gives me a clue as to what might be wrong.
Unfortunately, I am generally lost if its a CSS related or HTML element issue.
In one particular case, I have placed a div inside a <td> and I am lost as to why the chrome cannot render it properly irrespective of the fact that firefox is happy and does not complain.
So my question is, how to debug issues related to rendering of HTML pages in Chrome and CSS and determine what might be offending.
My related question is, is there a guidelines to make my web page work in almost all the popular browsers with little effort? I am particularly thinking in terms of tool or process which will warn me of compatibility issues with my web page.
IE (Internet Explorer) and little effort doesn't match to each other, you have to invest more of your time and effort only for IE, illuminate IE and be happy, as a suggestion, use Twitter Bootstrap if possible, it's a ready and tested css framework (maybe framework is not perfect name).
Basically, as far as I know, only a css reset could be used to gain some consistency but still you have to test over different browsers because each has different rendering engine. If you want to keep IE in the list then test the layout for IE at first.
Only for the IE or Inconsistent Exposer (IMO) there is a developer tool available (IE Tester) to test layout (HTML/CSS) over different versions of IE and only works on Windows so it may help you a bit if you are Windows user. There is also an online tester available and sometimes helpful, it's browsershots.org.
Also IE has a debugger/developer tool and pressing F12 will bring it so you may see something like this:
Google Chrome has it's built in debugger/inspector (CTRL + SHIFT + I) and on Firefox you may use Firebug extension and these browsers are not dumb like IE and there are lots of debugging extensions available for these browsers for free, not worried about these good guys.
Generally speaking, IE users are dumb and used to see dumb things on their screen so I don't think too much about them because they really don't know the difference but as a developer you may need to think about it and in this case I would demand extra charge from my clients if they want me to make a site compatible for IE < 10 because it requires extra effort.
You dunno me ? Leh--hoo-zehar (Looser) IE am a legendhhh. Smooky...!
I am not aware of any tool that will warn you because there is no way for a tool to validate the result of what you desire.
As far as how to test HTML/CSS. Chrome supports the most HTML-5 and FF is a close second. If you develop in chrome it normally works in FF and via verse. IE is where the pain is. IE does not support all HTML tags and often will render things wonky. I normally create my webpage and focus on FF and chrome once I like the results I open IE and debug. 98% of the time it is CSS changes that need to be made. I debug CSS first and if I am not able to resolve it with CSS after a decent amount of work I will look into changing the HTML. I try to avoid changing HTML because you have to debug all other browsers again.
Styles and code developed in Chrome will generally work in Safari, Opera(same engine), and IE 10+ with few inconsistencies. You'll get a few rare positioning issues with some CSS3 specs in Firefox, specifically in background positioning. You'll also find some javascript issues unique to Firefox.
IE9 is generally a good sport and usually doesn't have too many issues. IE8 will have a few and they'll be significantly different based on the OS (as there are multiple versions of each IE and they all support different specs for Javascript and HTML) specifically you'll find lots of issues with XP IE8 and really shouldn't support it (Microsoft doesn't even want to).
For the most part you'll be developing to IE inconsistencies unless it's a CSS3 spec with the occasional javascript strangeness (which js frameworks generally can help with since a few of them were made with that goal in mind).
As far as tools, browserstack is nice but doesn't give you a lot of time. If what you're trying to use is modern caniuse is a good place to visit first. Almost all issues between non-IE browsers will be HTML5 or CSS3 specific though.

Force Employee To Use Firefox + Specified Version For Company Intranet

Please not not turn this into a discussion about which browser is better and the ethics of forcing a browser. It's an intranet, and it's what I am required to do so everyone calm down =o)
I need to prevent employees from trying to bypass the check to not use their preferred browser instead of the company mandated one + version. The decision was made based on security, compatibility, costs, and the use of company made Firefox extensions.
I came across this Force users to use Chrome/FireFox instead of IE which I can do easily in PHP to force use of Firefox, however it relies on the useragent which can easily be changed in numerous browsers and with the use of plugins.
Is there a JavaScript solution that I can use that DOES NOT check the useragent or any value that can be 'easily' modified by a user/plugin? It would need to detect if the browser is Firefox and what version it is. Site uses jQuery so if it can be done using that, however not required then by all means yes. I just am not aware of what ways to detect a browser and it's version that there are without checking useragent.
I remember way back in the day for detecting Netscape or some browser checking for document.all was used instead of useragent, so I'm guessing something similar, which only Firefox will have.
Thank you very much in advance!
Try this: http://jsfiddle.net/DerekL/62exH/
Because Firefox handles onpopstate differently than other browsers, you can then use this to detect if it is Firefox or not. This can not be changed by user or script. But the disadvantage is you can only get the version number by doing navigator.appVersion.
You can only try but cannot succeed in forcing a browser. That being said you can strip down the CSS in other browsers which may completely make your site close to unusable in other browsers.
To make your CSS only work with Firefox you can try approaches given # Targeting only Firefox with CSS

Best way to display warning message to "untested" browsers?

I have an app that I have fully tested in Safari 5, IE 9, FF6, and Chrome 14. I'm not looking to block or exclude any browsers from the experience. But I want to warn/inform users that there may be a better experience in another browser, and if they choose to continue, there may be features not working or broken.
I have looked at jQuery browser detection, but it seems to be a bit quirky. I know the best solution would be to warn based on feature detection, but we are currently in beta and I am not completely sure what features make or break. Such as web workers, its known that web workers not working breaks our app, but it works in IE lower versions. But then there is an issue with Opera that web workers is available, but not functioning correctly.
Ultimately I am looking for an easy way to say Browser X Version y and up don't show warning, and those and under show warning.
What is the best way to approach this?
Browser detection is indeed "a bit quirky", in pretty much any scenario. The jQuery route is probably as good as you're going to get, but as you say it's not great.
A better solution is generally to do feature detection, especially in cases like the one you describe where your site relies on specific features.
The best feature detection library is Modernizr. This will give you an bunch of Javascript flags which are set to true or false according to whether the browser supports a given feature. It detects support for a whole bunch of stuff, including Web Workers.
Check out this: http://www.w3schools.com/js/js_browser.asp
-Easy way of detecting the user's browser with javascript. From there I'd just use a switch statement or something to display the messages for browsers that aren't tested yet. If you want the exact browser version you'll have to parse it from the "navigator.userAgent" field.
If the goal is full validation, you need to be even more specific about versions. Keep in mind that some browser upgrades are not 100% backwards compatible with previous versions. (Look at how IE8 mode in IE9 is not the same as native IE8 rendering, for instance.) You're going to have to retest with every new browser version, and sooner or later there's going to be a "Fully tested with browser version X, not tested with version X+1 that was released yesterday" problem. Feature detection, graceful degradation, and a warning non-intrusively displayed to the user if their experience is being significantly downgraded is a better way to go.
To directly answer your question, if you must implement what you are asking for just parse the user agent. This could be useful specifically watching out for a browser you know doesn't work right and warning, or as a bandaid for a badly written intranet app that is very picky about the exact browser version it will run on. For a newly developed app where you have control over the requirements, I would not recommend warning on browser version since there are better ways to do it.

Design order: Firefox, IE, or both?

When coding new javascript heavy websites, which order or web browser do you code for?
I can see these possible orders, but I am not sure which I like best:
Code for one first and get it working well, then start testing with other and fix errors as I go.
This will allow for the most rapid development (with Firefox at least) but I've learned from experience that debugging IE with so much going on at once can be a pain!
Code for both at the same time. In other words, for each new feature, ensure it works with both browsers before moving on.
This seems like it will actually take more time, so maybe do several features in Firefox then move to IE to patch them up.
What do you all do?
Edit 1: To respond to a couple of answers here.:
#JQuery usage: For some reason I was not expecting this kind of a response, however, now that this seems to be the overwhelming accepted answer, I guess I should tell everyone a few more things about the specifics of my app. This is actually the DynWeb that I started another question for, and as I'm developing, a lot of the important code seems to require that I use document.whatever() instead of any JQuery or Prototype functions that I could find. Specifically, when dynamically importing changing CSS, I have to use some similar to:
var cssid = document.all ? 'rules' : 'cssRules'; //found this to take care of IE and Firefox
document.styleSheets[sheetIndex][cssid][cssRule].style[element] = value;
And I expect that I will have to continue to use this kind of raw coding currently unsupported by either JQuery or Prototype in the future. So while I would normally accept JQuery as an answer, I cannot as it is not a solution for this particular webapp.
#Wedge and bigmattyh: As the webapp is supposed to build other webapps, part of the criteria is that anything it builds look and work functionally the same in whatever browsers I support (right now I'm thinking Firefox and IE7/8 atm, maybe more later on). So as this is a more interesting (and much more complicated) problem; are there any sites, references, or insights you may have for specific trouble areas (css entities, specific javascript pitfalls and differences, etc.) and how to avoid them? I'm almost certain that I am going to have to have some sort of isIE variable and simply perform different actions based on that, but I would like to avoid it as much as possible.
Thanks for your input so far! I will keep this open for the rest of the day to see what others may have to say, and will accept an answer sometime tonight.
This is sort of a trick question. In my opinion you need to work in this order:
1: Conform to Standards
This gets you closest to working in every browser without having to test against every browser. Additionally, you gain the huge benefit that your site should work with any new browser that comes along (Chrome is a good example) so long as it's well made and standards compliant. It also makes it easier to tweak your site to work in specific browsers because the way that the popular browsers deviate from standards compliance is well known.
2: Support the Most Used Browsers (For Your Site)
Note carefully the distinction between the breakdown of browser usage on the internet vs. browser usage on your site. On the internet as a whole IE is the most popular browser with Firefox a close second and Safari, Opera, and Chrome taking up most of the remainder. However, the demographics of your site's visitors can turn these numbers upside down. On sites that cater to a more technically savvy crowd it's common for firefox to be the dominant browser with IE in the distinct minority.
3: Support Other Browsers as Needed
You need to be very explicit about the fact that browser compatibility is an operating cost for your site, and you need to decide where you draw the line. Depending on your site's purpose and business model it may be fine to support only the most popular browsers, or even a subset of them. On the other hand, it may be a vital business concern to support everything under the Sun, including IE5. It's ok to make a conscious decision to not fully support every browser if you think the cost/benefit ratio is too high to justify it. Indeed, many of the most popular sites on the internet do not work well in older and niche browsers. Though you should strive to make your site still functional in the least popular browsers, even if there are serious appearance or usability problems.
FireFox first then IE. If it works in FireFox, it is more likely to work in the other non-IE browsers, IE sometimes requires special magic.
Use jQuery and do them all at once.
Code for Firefox first, but test with IE as you go. This lets you fix any quirks as they arise. It's important to test with Firefox first because it's more standards-compliant. You should learn how to write HTML/JS the right way. Fix things as you go to get a better idea of how IE renders things differently.
You may not need to test with IE for every feature you add, but test often enough so that issues don't pile on top of each other. Repeat with other browsers/browser versions to get the overall picture of your site's compatibility.
I always test on both FireFox and IE7. And then fix and botch for IE6 and other browsers.
If it works on FireFox it will almost certainly work on Opera, Safari, Chrome, etc with only a few minor tweaks
Same thing goes for IE7 and IE6, If it works on 7 it won't take too much to get a reasonable rendering on IE6
I normally use Firefox as my main development browser because of its superior debugging tools and I code very incrementally, write a few lines and test several times an hour. But at least every hour or two I make sure that what I am doing will work on IE7 as well.
As soon as I get into an area where IE7 causes problems I start to rethink the way I'm doing it, In my experience fixes tend to multiply and get out of control very rapidly. It's often better to accept defeat and move on with a simpler design.
I've been bitten too often in the past by developing something that works perfectly on FireFox only to find that it needs a complete rethink to get it working in IE7 as well - and vice versa. It can take days to sort out and can be very disheartening.
are there any sites, references, or insights you may have for specific trouble areas (css entities, specific javascript pitfalls and differences, etc.) and how to avoid them?
A good resource for this is quirksmode. The author (Peter-Paul Koch, or PPK) has lots of compatibility tables for CSS and JavaScript support. He also has articles dealing with specific issues and how to write cross-browser code.
They don't deal with JavaScript, but Position is Everything is a valuable resource for CSS issues (mostly IE6).
Like others have mentioned, I just use jQuery to avoid these issues. If there's something it doesn't support, it's pretty easy to write custom plugins.
I do IE first, and then add Firefox.
My experience is that once it works in IE, it continues to work in IE, and the question why something not work in Firefox is usually easy to answer.
If you have to code for IE6, the most frustrating part is coding the CSS and HTML. jQuery and other libraries make it easier to code the behavior -- but you generally can't get around the fact that IE6 has so many weird rendering issues that you'll be frequently banging your head on the keys trying to make it do what Firefox, Safari and Opera do right the first time.
So Javascript isn't the hardest part. Dealing with HTML and CSS is. In my experience, if you're working with any reasonably interesting design, you're better off coding for IE first and then testing on Firefox. You probably won't have to make many adjustments if you do IE first, but you definitely will have to spend some time refitting your code to make IE do what you wanted it to, if you only code in Firefox. It's like repeating yourself. It's a pain. So it's better to get it done first so you don't end up wasting too much time.
I code for both, and write (or use) abstraction layers where there are differences between the browsers. IMHO, it's much easier in the long run to be continuously testing in a cross-platform setting. This keeps me from doing something that's tuned to one browser that simply won't work well in the other: I find out very early in the development cycle what the compatibility issues will be.
When I'm making a small change, I might first do it for one browser, but before I consider that feature or change to be complete, it must work at least in firefox and IE.
To minimize your issues now, and downstream, work with the worst to the best, in size of their existence.
Edit: If you can do the below keeping in mind of "how could this degrade gracefully down to ie6 via modified jQuery elements, etc... it might be a bit clearer.."
So, today based on Market Share, it is:
1) IE 6
2) IE 7
3) Firefox
4) Safari..etc.
Coincidentally enough, the major issues with browsers occur in that order too.
This means the majority of the issues your users will face will be in that order, and in those proportions.
On our team I have banned initial-development testing in Firefox. It has to survive the weakest link, not the strongest. Inhumane, I know, but we have cut down going back and fixing bugs related to browsers by 80%, because 80% of browser bugs are IE. Yeah, there's a ton of debugging tools in Firefox that can be used ONCE we find a problem in IE.
On the flip side we put in extra-features that are Firefox only to reward the firefox users. A simple browser type check and it takes care of the rest.
If you have look at Web Browsers market share, you will find that IE and Firefox are on the top and so close to each other so,
You should put both of them in your consideration either using cross-browser Javascritp like JQuery or go on your way by testing both of them.
I think its best to design for Firefox but like others have mentioned the JavaScript isn't the hardest part, its the CSS that is the hard part. Personally I used to code for both FF and IE at once, but I find that it takes longer because your likely to make major changes during a development cycle so don't even bother coding for both at once, it could be wasted effort.
Another thing to consider when choosing which browser to start development under is if you are more familiar with W3C standards or the IE "standard" imposed by its majority user base. Its kind of a funny thing about web standards, many if not most web developers are not happy with IE's standards support, but at the same time any code IE supports is the real standard of the web.

Categories