Can anyone tell me if IE9 is fully DOM level 2 compliant? For example, that it now supports .stopPropagation()?
Yes, events in IE 9 are fully DOM 2 compliant and support stopPropagation() and preventDefault() methods.
Here's a test case that proves it: http://jsfiddle.net/pke26/
Related
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.
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
I need to write a piece of code that will attach a listener to selected event, and that will work in any popular browser, in any version of it. After doing some searching I came out with following function:
function addListener(event, thefunction)
{
if(window.addEventListener)
{
//All browsers, except IE before version 9.
window.addEventListener(event, thefunction, false);
}
else if(window.attachEvent)
{
//IE before version 9.
window.attachEvent(event, thefunction);
}
}
Quite simple and seems to be self-explanatory.
There might be some problem with DOMContentLoaded event, as none version of IE (AFAIK) does recognizes it, and developers are obligated to use onreadystatechange instead. Solving this problem also seems to be fairly simple, until Internet Explorer 9. You had to write only an extra line in else if(window.attachEvent):
event = (event == 'DOMContentLoaded') ? 'onreadystatechange' : "on" + event;
This part was always fired in any version of Internet Explorer and this line provided a simple translation of event name, so a correct one was always used.
But what about Internet Explorer 9 (and above)? In which Microsoft decided that it will drop attachEvent in favor of addEventListener. But doesn't changed onreadystatechange into DOMContentLoaded.
I can't use above line in window.addEventListener part, because this will rewrite DOMContentLoaded into onreadystatechange event even for other browsers and fail there, as they use DOMContentLoaded.
So, does the only way to solve this problem, is to add browser detection (type and version) to window.addEventListener part and if it detects that script is dealing with IE 9 or above, it will rewrite event name from DOMContentLoaded to onreadystatechange (and supplement other events name with on, required for IE), and in case of other browsers, will leave event name not changed?
Or maybe I'm wrong, because as I just tested, neither DOMContentLoaded nor onreadystatechange is being fired in my IE 8 (first one fires correctly in Firefox / Chrome).
And what about jQuery's .on() function (or similar)? Does anyone knows, if it supports cross-browser attaching of DOMContentLoaded, so I can be sure that this specific kind of event will be catch by my script, no matter, in which browser or it's version I'm using?
IE9 supports DOMContentLoaded. See here.
With this in mind, you can pretty much* work on the assumption that, if addEventListener is supported, so is DOMContentLoaded.
(* unless someone lands on your page using Opera 8 or Safari 3.0, probably unlikely).
As for jQuery, it defers to DOMContentLoaded where this is supported but otherwise falls back to its historic means of detecting DOM-ready, which involves repeatedly checking the DOM tree to see if document.body exists yet. So you can just use its DOM-ready handler:
$(function() {
without having to use on().
More info on how jQuery does it in this answer.
DOMContentLoaded is natively supported in IE9 and above and can be attached through the W3C-standard addEventListener method which was also implemented in IE9:
document.addEventListener('DOMContentLoaded', function() {
console.log('DOM ready');
}, false);
That will work in all modern browsers and IE from version 9 and up.
jQuery 1.x is compatible with IE6+ and any other update-to-date browser. jQuery can hook a DOM ready event cross-browser by shimming support for IE6-8 through the DOM ready handler:
$(function() {
//DOM has loaded, put your code here
});
.on() provides event delegation, but that's rather unrelated to the question.
I'm developing a Chrome plugin. It injects a class name to every tag.
I have some problems with webpages such as facebook in which content is loaded afterwards when you scroll down.
I'd like to know if there a way to check if new content is loaded.
By now the only solution I could find is a
setInterval(function() {
Thanks.
There is a DOMSubtreeModified event (source) that Chrome supports - see this answer for details. Your code should look something like this:
document.addEventListener('DOMSubtreeModified', function() {
$("*:not(.my_class)").addClass('my_class');
}, true);
As Konrad Dzwinel said, you can use some Mutation Event listener
document.addEventListener("DOMSubtreeModified", methodToRun);
But note that the Mutation Events are performance hogs which can't really be tamed well (they fire too often and slow down the page a lot). Therefore, they have been deprecated over a year ago and should be used only when really needed. However, they work.
If you want this for a Chrome extension, you could use the new and shiny Mutation Observers from DOM Level 4 (follow the links there, they explain a lot!). Where DOMSubtreeModified fired a thousand times, MutationObserver fires only once with all the modifications contained and accessible.
Works for (as of 2012/06):
Chrome 18+ (prefixed, window.WebKitMutationObserver)
Firefox 14+ (unprefixed)
WebKit nightlies
I had some event code which failed in Opera and I have stripped it down to this small testcase.
Basically the problem is that the event handler doesn't run in Opera if the third parameter of addEventListener is not set. The value in the testcase increments in both Firefox and Chrome when the "useCapture not set"-button is clicked, but not in Opera.
This (old) article indicates that Opera is different than webkit & gecko browsers:
http://my.opera.com/hallvors/blog/2006/10/12/2006-10-12-event-capture-explained. I'm not sure what to make out of it though. MDN says useCapture should default to false.
is the default true in Opera, is the parameter simply not optional, or what am I missing? What is the correct behaviour?
If in doubt, refer to the spec. The original and still current spec is W3C's DOM Level 2 Events. Looking at the ECMASCript binding page, it looks as though the useCapture parameter is required, since there is no mention of it being optional.
DOM Level 3 Events explicitly mentions useCapture as being optional, although I don't think this draft spec has ever reached widespread adoption in browsers.
The relevant MDN page also has a note on this:
Note: useCapture became optional only in more recent versions of the
major browsers; for example, it was not optional prior to Firefox 6.
You should provide that parameter for broadest compatibility.
Bottom line: it's safest to always pass in all three parameters, and Opera is well within its rights to insist on it.
The disparity compared with DOM Level 3 Events is a bug, and will be fixed in Opera 12.