Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I have heard that browser sniffing is bad , i have seen the below method used to detect if a browser is IE or not:
var isIe = !!window.ActiveXObject,
is it a reliable way to detect ie ?
I have seen this method used in plugins like HERE
Except in very rare cases (usually dealing with implementation bugs for which feature detection is not practical), making programming decisions based on the brand or version of the browser is considered a poor practice that leads to code that breaks as browsers change.
Creating a variable like isIE and then using that for programming decisions makes an assumption that all browsers for which isIE would be true or false all have the same behavior and this is exactly where browser detection breaks down. It's just wrong.
For example, IE8 didn't support .addEventListener(), but IE9 and beyond does. And then in IE11, .attachEvent() was removed.
So, if awhile ago, you used browser detection and wrote code like this:
if (isIE) {
elem.attachEvent(...);
} else {
elem.addEventListener(...);
}
Then, when IE started supporting .addEventListener() in IE9 your code would continue to use the old way. Then, when IE11 came out when .attachEvent() was removed, your code would break entirely because you'd still be detecting IE and trying to use the old way. So, your code was brittle because it assumes that detecting a browser type means a specific behavior which is just simply not true. Instead, you should detect the behavior itself, not the type of browser.
So, using feature detection:
if (elem.addEventListener) {
elem.addEventListener(...);
} else {
elem.attachEvent(...);
}
Then, your code just merrily continues to work in IE8, IE9, IE10, IE11, etc... Your code doesn't have to be "fixed" as the browser changes.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I learnt that the JavaScript syntax document.<a_form_name> is IE proprietary syntax (instead of document.forms.<a_form_name>). (reference: https://developer.mozilla.org/en-US/docs/Archive/Using_Web_Standards_in_your_Web_Pages/Using_the_W3C_DOM)
There are more other proprietary or dialect syntax, methods or functions on JavaScript/CSS/HTML.
Most of the dialects are works fine in latest browsers, but I think clean code is better for future maintenance.
I could not find the lint checker to notice the problems like that.
Do you have some tools or methodology to avoid or minimize the dialect from the JavaScript code?
You can use libraries such as jquery to manage browser compatibility.
Checkout more details on this website: https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/JavaScript
Some snippet from aforementioned website:
Historically, JavaScript was plagued with cross-browser compatibility
problems — back in the 1990s, the main browser choices back then
(Internet Explorer and Netscape) had scripting implemented in
different language flavours (Netscape had JavaScript, IE had JScript
and also offered VBScript as an option), and while at least JavaScript
and JScript were compatible to some degree (both based on the
ECMAScript specification), things were often implemented in
conflicting, incompatible ways, causing developers many nightmares.
Such incompatibility problems persisted well into the early 2000s, as
old browsers were still being used and still needed supporting. This
is one of the main reasons why libraries like jQuery came into
existence — to abstract away differences in browser implementations
(e.g. see the code snippet in How to make an HTTP request) so
developers only have to write one simple bit of code (see
jQuery.ajax()). jQuery (or whatever library you are using) will then
handle the differences in the background, so you don't have to.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I am confused I thought that cancelBubble is IE-only Boolean property but found it in Chrome.
From early on, the Chrome folks took the approach of trying to be broadly compatible with existing code, which in some cases meant being compatible with code written using IE-only features. Another example of this is the global event variable, an IE-specific variable set to the current event during event callbacks (so callbacks use the global rather than an argument as they do with addEventListener). Chrome has supported that since the beginning for IE-specific code that relied on it; Firefox has only recently started supporting the global event variable. Supporting cancelBubble is in that same category.
They don't support every IE-specific thing (for instance, not attachEvent), so as to avoid messing with code trying to detect IE event handling and branch. But they support a lot of IE-isms.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
My html generated pages is working wrong with IE and correct with Safari. I found out https://github.com/trevorlinton/webkit.js project but it still in development and does not support IE. Does exist another ways to turn IE engine to WebKit using JavaScript?
I know about Chrome Frame plugin for IE but it is not what I want
My aim to change engine - my pages generated from another program and that program is anonced as partaly support of IE and full support of Chrome and Safari
So, i think - the easist way to solve problem of IE to turn IE engine to WebKit engine by Javascript
UPDATE
I found out a solution for IE - I made a patch to update my genenerated pages after reverse enginiring of generated pages and scripts - but I like more complex solution
Is it possible to change browser engine by javascript?
Replacing a browser engine from a webpage is a ridiculously dangerous thing even if it was possible. This would open up various security risks because it would allow the engine to be changed to a modified one that contains malicious code, for example, or outdated security technologies.
It is recommended that you actually bother to code with standards rather than just for a specific browser to avoid compatibility issues or broken pages on other browsers.
Providing all the vendor-specific prefixes as well as the standardized version in CSS instead of just one vendor-specific prefix in CSS will ensure greater compatibility across a wider range of web browser engines.
For HTML, ensure that your code is validated properly and closes all tags. Doing this will help improve compatibility on other browsers, as every browser engine uses a slightly different way of interpreting the code.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
Everytime I think about using JavaScript (or any JS library) I see this red light in front of me. My only concern as usual is IE. So here is what I want to know:
1) Is JavaScript disabled by default in IE8 or IE9?
2) What about you, do you feel safe when including a JavaScript code in a site that may be viewed using IE 8 or 9?
3) I found so many problems when applying CSS rules to html5 tags in IE8 so I used Modernizr. However it depends on JavaScript to enable html5 tags so I could apply CSS rules to them in IE. Am I risking to lose CSS styling as well, by using Modernizr?
No JavaScript is not disabled by default in IE8/IE9
Yes I feel safe, because I code defensively with those browsers in mind if they're mentioned as requirements in the project spec.
Again, code for your requirements. If you have a real reason to believe that modernizr isn't going to cover your requirements, don't use it and style accordingly.
1) No, it is enabled by default
2) Safety is not a concern for you in that case. Nowadays, modern Javscript libraries even support IE quite well. They often implement workarounds for features not supported by IE, so that users just can't use all features the libraries has, but the scripts shouldn't crash any more.
That said, you still need to test your sites in IE.
Javascript has become a widely accepted standard finally.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
Javascript : What are the different conditions when javascript work in IE but not in Firefox or some other browser?
one that i know of is that while using certain window events..
What other scenarios can cause javascript to not work properly?
The answer is too complex to fully list here. Use sites like http://caniuse.com that will tell you which JavaScript is available in which browser.
Generally speaking, all browsers implement JavaScript differently. Microsoft have long been stuck in their own world, implementing their own ways to do things, whereas everyone else seems to try and conform to the standards as much as possible. Microsoft are coming around to the "standards" way of doing things, and from what I hear, IE11 will be a massive step in this direction.
As already mentioned, you can use http://caniuse.com/ to find what you can and can't do in different browsers, but then you'll likely end up doing what many others have done...write your own API which works around these to achieve a task...which is a bit unnecessary, unless you can find a ground-breaking way to implement your API that will be beneficial to other developers.
APIs like jQuery already work around these differences. The aim with these libraries is to provide clean JavaScript, whilst being completely transparent from the underlying JavaScript implementation.
Also, look into "shim"/"polyfill" implementations. These are used when a core feature that is recognised as part of an ECMAScript version has not been implemented in the browser. These provide the implementation for you, if it is not natively supported.