I have this code:
container = document.getElementById("menuContainer");
and later on:
container.document.open("text/html");
container.document.writeln(content);
container.document.close();
In IE8 works but in IE11 warns me:
What can I do?
The recommended standard reference from the node to a document has been node.ownerDocument since DOM Level 2. According to MDN: ownerDocument is supported since IE6. In IEs node.document was also supported until IE10.
The fix for your code would hence be:
container.ownerDocument.open(...);
document.write was used in the example only to demonstrate the output, not as real code, hence I'm not handling its use in this answer.
Related
I need help figuring out why Internet Explorer won't fire my 'paste' event.
I'm using IE 11. Here is my code:
$(document).on('paste', '.pasteTarget', handlePaste);
When trying this in IE, the function never gets called. It works in chrome.
Different browsers treat onpaste differently, or not at all. For IE 11, the latter seems to be the case.
From MDN:
Non-Standard
This feature is non-standard and is not on a standards track. Do not use it on production sites facing the Web: it will not work for every user. There may also be large incompatibilities between implementations and the behavior may change in the future.
Source
Edit: As pointed out in the comments, IE 11 does indeed support onpaste to some extent. However, as this is a non-standard feature, you should be careful about using it in production.
You could use beforepaste event instead and access clipboardData from window, not from the event.
But, indeed as pointed out already, Clipboard API doesn't seem to be supported in IE: https://developer.microsoft.com/en-us/microsoft-edge/platform/status/clipboardapi/
Is there anyone that can explain the note on section 5.2.2 of the W3C DOM4 specification?
Relevant Quote:
Note: The getElementById() method is not on elements for compatibility with older versions of jQuery. If a time comes where that version of jQuery has disappeared, we might be able to support it.
I'm curious how this interface would explicitly cause a problem with jQuery and what versions, does anyone have an example?
To expand on #Nan answer, it probably has something to do with jQuery using getElementById to validate a step in an iteration. Adding this method to HTMLElement would make some conditions validate when part of jQuery code depends on it not validating.
Hard to say exactly which version causes the problem and in exactly which situations, but a quick look to old jQuery versions, you can see that find() in older version isn't compatible with Elements having getElementById method.
Going back to version 1.3, you can try to add the method to HTMLElement and you'll see that it messes the result. More recent version handle this correctly. See snippet:
alert('Without getElementById method on HTMLElement, length of $("div").find("#test") is ' + $('div').find('#test').length);
window.HTMLElement.prototype.getElementById = function(str){
console.log(str);
return str;
}
alert('With getElementById method on HTMLElement, length of $("div").find("#test") is ' + $('div').find('#test').length);
<script src="https://code.jquery.com/jquery-1.3.js"></script>
<div id="container"><div id="test"></div></div>
It looks like the getElementById method is only present on document global object, and it's not part of the DOM4 Element object yet.
This is due to compatibility issues with an older version of jQuery as you can read on DOM4 specification.
But, what does all this means? it means that W3C tried to add this method into the Element object and also means that once this "version of jQuery" disapear we "might" be able to chain getElementById() calls like this:
var myElement = document.getElementById("header").getElementById("slogan");
Nothing special, they didn't want the most popular DOM manipulation wrapper to crash or jQuery as a member of the W3C has had some influence over this decision
Is there any simple way to capture an event when an element disabled property (or other css properties) is changed? I know there is MutationObservers, but it seems is not supported by IE8-IE9. I need to use a plugin?
Actual MutationObservers compatibility:
Chrome: 18-16
Firefox: 14
IE: 11
Opera: 15
Fafari 6
According to the DOM L3 Event specification, MutationOberservers were introduced with DOM4 Events to replace MutationEvents originally defined by DOM L3 events. (It appears there were inconsistences in the way different browsers implemented support.)
The IE Compatibility Cookbook has more details on this change, including migration details.
So you might be able to use MutationEvents for IE9 and IE10; however, they were not supported in IE8. Caniuse suggests the HTML Web Components polyfill as a possible alternative.
Hope this helps...
-- Lance
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.
I've found a strange bug in Internet Explorer 8. Maybe someone can help me move around it.
When I try to grab the background position of an element, using background-position-x all versions of Internet Explorer work as excepted except for IE8 that crashes.
When I run el.getStyle('background-position') all browsers give me the correct values except from IE (6, 7 and 8) that return undefined.
I therefore use el.getStyle('background-position-x') for all IE versions.
IE8, however, crashes on the above code.
Anyone had similar problems?
Thanks for the help everyone. This really is a bug and works only on the following scenario.
css must be loaded on an external stylesheet
element has no inline styling
The way to fix it, even tough dirty, is to add inline styling to the element. Makes IE8 happy and all other browsers work.
I did not test but, according to this ticket, FF2 also suffers from the same behavior.
Side notes:
#marcgg - I was going to downvote your answer as it really is not helpful (and bound to start a flame war) but, all truth said, jQuery does not manifest this problem. Even though, as you probably already knew, it is NOT an option! ;)
#Fabien - IE does support background-position-x and lacks support for background-position the W3C approved construction.
Why not use jquery's css function that works fine crossbrowser ?
Try using:
el.getStyle('backgroundPositionX')
and
el.getStyle('backgroundPositionX')
yes, older thread, but figured I'd post another solution that I bumped into # mootools lighthouse....
if (Browser.Engine.trident){
var xy = el.getStyle('background-position-x')+" "+el.getStyle('background-position-y');
} else {
var xy = el.getStyle("backgroundPosition");
}
works well for me so far.