if (document.all)
document.body.style.behavior='url(#default#homepage)';
if (window.sidebar)
What's those lines meaning in javascript? thank you.
Don’t use document.all:
if (document.all) {
element = document.all[id];
else {
element = document.getElementById(id);
}
document.all was introduced in Internet Explorer 4, because the W3C DOM hadn’t yet standardised a way of grabbing references to elements using their ID.
By the time IE 5 came out, document.getElementById() had been standardised and as a result, IE 5 included support for it.
More info here..
document.body.style.behavior='url(#default#homepage)' is used to set current page as home page in the IE.
if (window.sidebar) is a check for firefox
document.all is used to check if the browser is IE
if (document.all): used to check if the brower is IE, but note this is bad practice because it is no longer a good method of doing the test.
if (window.sidebar): test if the browser is Firefox.
EDIT: document.body.style.behavior='url(#default#homepage)'; is most likely used to set the homepage when the browser is IE. However, it does not seem to work well with Firefox and the others.
Statement 1 tries to detect if the browser is IE and statement 2 uses an IE-only API: behavior property.
However, document.all is not IE-only feature. It also exists on Chromium/Chrome and other WebKit based browsers.
Therefore, statement 1 get passed on IE & Chrome, but statement 2 only works on IE.
Related
I'm having a hard time figuring out what those lines do. I'm following the tutorial below. My guess is that window.oper is mistyped and would be window.open. Open, addEventListener and attachEvent as far as I know are functions or methods not properties. Although I use Javascript a lot, I know very little.
if (window.oper || (!window.addEventListener && !window.attachEvent)) {
return false;
}
http://www.script-tutorials.com/custom-scrollbars-cross-browser-solution/
.
My guess would be that window.oper should be window.opera, which is an object that only exists (by default) in the Opera browser. The other clause is checking for the existence of either an addEventListener or attachEvent method of window and bailing out if neither exists. All major browsers released in the last 15 years support one or the other so that is intended to weed out really old browsers such as IE 4.
guys,
Just upgrade from jQuery 1.8.3 to 1.11, the browser object is removed from 1.9 and judgement with user-agent is not recommended. But I still need to detect if browser is IE or not at a certain point of my code.
The conditional stylesheet is only supported from IE6-IE9, I search and search and it seems only user-agent is the ultimate way.
Is there a way to do that? Which could detect the browser is IE, not using user-agent and work from IE8 to IE11?
Thanks a lot.
The most reliable way for IE 5-9 is using conditional comments:
var div = document.createElement("div"), ie;
div.innerHTML = "<!--[if IE 5]>5<![endif]--><!--[if IE 5.0]>5<![endif]-->"
+ "<!--[if IE 5.5]>5.5<![endif]--><!--[if IE 6]>6<![endif]-->"
+ "<!--[if IE 7]>7<![endif]--><!--[if IE 8]>8<![endif]-->"
+ "<!--[if IE 9]>9<![endif]-->";
if (div.firstChild && div.firstChild.nodeType === 3) ie = +div.innerHTML;
But this doesn't work for IE10-11, as those don't support conditional comments, and IE11 not even when in compatibility mode (and that kind of sucks - conditional comments have been used a lot). Edit: fortunately, that has been fixed the exact same day I gave this answer. Ah!
You can still check if it's IE10-11 if you manage to detect its vendor prefix, for example:
var prop, isIE = false;
for (prop in div.style)
if (/^ms[A-Z]/.test(prop)) {
isIE = true;
break;
}
This works but you won't be able to tell IE10 from IE11, unless you check the UA string or some recent features.
But honestly, IE10+ is fine, and should also get automatic updates. You should go for feature detection for those, and forget about the version.
There are at least two solutions to solve your problem:
Detect browser features (recommended) Dokumentation for modernizr here
Use jQuery Migrate Plugin Download here
Modernizr aims to bring an end to the UA sniffing practice. Using feature detection is a more reliable mechanic to establish what you can and cannot do in the current browser - Taken from modernizr.com
According to this website calling removeChild() in JavaScript causes an Internet Explorer Specific leak called a pseudo-leak.
Sometimes Internet Explorer keeps items in memory after the page is done using them. Although these pseudo-leaks are freed after the user leaves the page, some web pages may be open for long periods of time. To avoid pseudo-leaks, do not use removeChild to remove elements. Instead, set the parent's innerHTML to ""
Does deleteCell() cause pseudo-leaks the same way that removeChild() does?
Edit: I was able to reproduce this error on IE8. Believe it or not, Microsoft claims to have fixed this problem in IE7.
I don't have the benefit of being able to look at IE's source code and confirm, but I imagine if it's anything like how Chrome implements deleteCell, it uses removeChild internally, which could trigger IE's pseudo leak. I know older versions of IE had this issue, but I'm not sure if the current versions do.
From chromium source:
void HTMLTableRowElement::deleteCell(int index, ExceptionCode& ec)
{
...
HTMLElement::removeChild(cell.get(), ec);
}
I'm programming my own Ajax history library in JS. I ran into problems with IE6 and IE7. Can someone elaborate on why the following is happening?
IE6 & 7
I am able to set the hash values without refreshing the page.
window.location = 'site.com/index.html#' + pageNumber;
I can go to page 1, page 2, page 3, and so on. When I'm on page 3 and hit the back button, I'm not transported back to page 2. Rather, I get completely taken out of index.html! It seems like IE does not think that different hash values are different points in history.
IE7
IE8 in IE7 backwards compatibility mode claims that it has the onhashchange listener.
if ('onhashchange' in window) {
// true in IE7
window.onhashchange = someFunction();
}
However, IE7 never executes someFunction() when the URL changes. This implies that it lies about having onhashchange but never implemented it.
Have you try this: http://tkyk.github.com/jquery-history-plugin/
IE6 and IE7 are known to not support the hashchange event; it looks like you found a bug (?) in the IE7 compatibility mode of IE8.
You need to use a library, like the one in Phong Nguyen's answer, to emulate hashchange support via hidden iframes if you want to use this capability in those browsers. In many cases such libraries will also fix your back button problem; I know the one he linked to does.
I'm trying to call a function, test(), of an iframe from the parent document using the code
subframe.test();
subframe refers correctly to the iframe, alert(subframe) returns [object HTMLIFrameElement], and the function runs in both IE7 and opera (9.23), but not firefox (3.0), chrome (3.0) or safari (3.03 beta windows). I assume these browsers support the functionality, so wondering if perhaps I'm using an incorrect call which IE and Opera support anyway, which wouldn't surprise me.
Thought I should answer for posterity - I solved the problem using subframe.contentWindow.test() .
Is the domain of the parent document's source the same as that of the child iframe's? I believe FireFox requires that they are in order to do something like this.