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
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.
In internet explorer 8, emit strange jquery attributes that sometimes can cause problem and when I need to select them, the selector won't work.
I don't know if this is related to my rendering problem, but I've never noticed it before, in IE8 or any other browser. Can someone explain what these attributes are?
sizzle-1377765392290 ="[object Object]"
also it creates unique id for each element
i.e: jQuery110201441698622493836
https://www.dropbox.com/s/e5l0r9weht23mhn/Ie8.PNG
Thanks You
See the answer here, jQuery uses it to attach event handlers etc in IE.: https://stackoverflow.com/a/16341470/1371408
As i can see in this bugs.jquery.com/ticket/8539 that sizzle cache bug was fixed in 1.7 version of jquery .
And as per your comment you included older version of jquery 1.1.0 so updating it to latest release of jquery will solve your issue .
You can remove this by,
var re = /\s*(sizset|sizcache)\d*="[^"]*"/gi;
source = source.replace(re,'');
http://jsfiddle.net/mblase75/fMdVc/
Alternatively, jQuery has a .removeAttr() method, but you'll have to apply it to specific tags:
jQobj.removeAttr('sizset').removeAttr('sizcache');
Have a look
How can I find an id based on its class just using javascript. I know this is easy with jQuery what is the solution.. using getElementsByTagName ?
document.getElementsByClassName('myClassName')[0].id
or
document.querySelector('.myClassName').id
First step would be find the element(s) with the given class name. There are currently some functions supported by modern browsers like getElementsByClassName and querySelector functions. but they are not cross browser solutions.
That is, getElementsByClassName is not supported by IE 6-8 and querySelector is not supported by IE6-7 & FF3
source: http://www.quirksmode.org/dom/w3c_core.html
Therefore if you are not supporting these browsers then you can use them else you would need a wrapper js function like one mentioned in this blog post originally found on justswell.org.
Problem occurs in IE6 (probably all browsers pre-dating document.getElementsByClassName).
Using jQuery 1.6 with Prototype 1.5
<script src="../js/jquery-1.6.js" language="javascript" type="text/javascript"> </script>
<script language="javascript" type="text/javascript">
// Prototype will claim the '$' namespace so give jQuery '$j' instead.
$j = jQuery.noConflict();
</script>
<script src="../js/prototype.js" language="javascript" type="text/javascript"> </script>
The problem is discussed here: http://randomous.com/forum/topic.php?id=916 (see 2nd post) and here: http://ejohn.org/blog/getelementsbyclassname-pre-prototype-16
Essentially Prototype creates document.getElementsByClassName in browsers the predate that function (it is natively supported by most browsers nowadays).
However jQuery also checks for the existence of document.getElementsByClassName, and when it finds it, it assumes it's getting the native implementation; but really it's getting Prototypes implementation which doesn't behave as jQuery expects.
I have tried A LOT of tricks to resolve this but none work. [ trying to tell jQuery document.getElementsByClassName is undefined, trying to stop prototype from claiming document.getElementsByClassName, etc. ]
The application is old (hence old prototype) and unfortunately will run mainly on IE6 & IE7 (yes, FML). I'm trying to use the latest jQuery since that's where I'm comfortable and I need to add lots of crazy UI controls to the app - combobox autocomplete dragdroppy madness.... basically I do need jQuery.
The end result here is I get errors anytime I use jQuery's class selector - $('.someClass')
Any thoughts here? I thought I was decent with javascript but this is killing me.
I had the same problem when class selector without any tag was called, e.g. $('.myClass')
resulted error while $('div.myClass') worked well. I replaced $('.myClass') with $('*.myClass') and it started working
This answer may seem a bit simple, but, update prototype to latest. They abandoned that awful decision: http://www.prototypejs.org/api/utility/getElementsByClassName
And I realize you may be supporting an app you yourself didn't build, but I'd also say that if you have the option in the future, never choose a framework that screws with the ability of other frameworks to do feature detection.
Faking native functionality should be considered harmful. I'm looking at you, prototype.
I came across some javascript at work today that used jQuery to fetch two elements. It then used elem.nodeIndex to determine the position in the elements parent for each element. Nothing is setting this property anywhere and I do now see a reference to it in the msdn, mdc, or anywhere else.
I stepped through this javascript in FireFox with FireBug and tested the code in chrome and opera. I am sure nothing was trying to set this property. However, I can't find any information on this nodeIndex property anywhere.
Does nodeIndex exist as a DOM property in IE, or did I miss something while debugging my code?
UPDATE: I asked the same question on the jQuery list and they confirmed the property is for internal use only.:
It looks like it's jQuery that's adding nodeIndex to nodes in some cases.
Well, the easy answer is: If it isn't documentated anywhere like MDC, MSDN or W3, then it isn't a 'real' DOM property.
The idea of using nodeIndex, is also wrong, why would you want to do that?