This is working fine in firefox but only closes the first page and then breaks in IE8. Firebug in IE8 says that x.item(o) is null. I can't figure out why this works in firefox but not IE. Thanks for any help.
pager(x=document.getElementsByName("pg1"));
function pager( x ) {
var curr = document.getElementById('showing');
$(curr).fadeOut('fast');
curr.id = 'hide';
$(x).fadeIn('slow');
x.item(0).id ='showing';
}
if(x.item(0).id = NULL )
That's an assignment. You wanted == for comparison.
(What's NULL in capital letters? An element's id property won't be null; if it's not set, it'll be an empty string.)
It seems to me you'd be better off using jQuery's toggle method.
Related
I am having an issue with currentStyle which I have read is the fix before IE9 for getComputedStyle support.
I recently made this other thread regarding getting a reference to the top level LI list of a multi level navigation menu:
Selecting <li> child node but not grandchildren with vanilla JavaScript
Now I need to be able to measure the width or height of the LI's I am not able to reference with the help I received. It works, but not below IE9.
Here is what I've tried for getting the width:
this.w =function( elm ){
var s = (window.getComputedStyle) ? window.getComputedStyle(elm, "") : elm.currentStyle;
return parseInt(s.width);
}
the width comes back as NaN
SCRIPT5007: Unable to get property 'innerHTML' of undefined or null reference
I really appreciate everyone's help
elm.currentStyle.width returns "auto" when no width has been specified.
This correctly reflects the current style setting, but doesn't give you the value that you are looking for (as you might have expected getComputedStyle to do).
Instead, use elm.clientWidth
So in your example, you might use...
this.w =function( elm ){
var s = (window.getComputedStyle) ? window.getComputedStyle(elm, "") : elm.clientWidth;
return parseInt(s.width);
}
(tested in IE8 but not IE7)
i am getting the above error in ie 10 please give me a suggestion.it is working fine in
function getSelectedIndex(element, value) {
var selectedIndex = 0;
for(i = 0; i < element.options.length; i++) {
if(element.options[i].value == value) {
selectedIndex = i;
break;
}
}
return selectedIndex;
}
element.options.length is giving Unable to get property 'options' of undefined or null reference.please suggest me a sample code.
Edit : It was working for me when I was using IE11 with compatibility mode, but when I removed it and ran it in normal mode, the above issue occurred.
Use elements.options.indexOf(value) (assuming element is defined, which it doesn't seem to be). By the way, your current design will return zero if the first element matches or there is no match at all. If you really want to write your own version of indexOf, better to return -1 in the case of no match as it does.
actually the message gives you exactly what you need to know.
you are trying to read a property of something that does not have a value, and here it is "element" or "element.options", check the place where they are set before the function call.
for IE10 it's a strict one, it doesn't support the use of
element.options.length
instead you should use:
document.getElementById("optionsID").value
I hope this helps
I'm currently writing an accordion and running into the same problem as described in nextSibling difference between IE and FF? - specifically differences between Microsoft's nextSibling / nextElementSibling and that implemented by everyone else.
For various reasons, using jquery is not an option. Nor is getting all my MS users to upgrade to MSIE9
Currently I'm using the following code to work around the problem:
// tr is a TR doc element at entry....
while (nthRow--) {
// for Chrome, FF tr=tr.nextElementSibling; for MSIE...tr=tr.nextSibling;
tr=tr.nextElementSibling ? tr.nextElementSibling : tr=tr.nextSibling;
if (!tr || tr.nodeName != "TR") {
break;
}
tr.style.display="";
}
Which seems to do what I expect in MSIE6, FF and Chrome - i.e. the nthRow TR elements below the initial TR are made visible (previously style.display="none").
But is this likely to have unexpected side effects?
(I'm a bit of a newbie with Javascript ;)
nextSibling will see HTML code comments, so be sure to keep them out.
Other than that you should be alright since you won't have any text nodes between your tr elements.
The only other issue I could think of would be in Firefox 3 where nextElementSibling hadn't yet been implemented. So if you're supporting that browser, you'll need to manually emulate nextElementSibling. (Pretty sure they had it implemented in FF3.5 though.)
You'll be safer to create a nextElementSibling() function:
tr = tr.nextElementSibling || nextElementSibling(tr);
function nextElementSibling( el ) {
do { el = el.nextSibling } while ( el && el.nodeType !== 1 );
return el;
}
Considering previous answers, I am currently implementing it this way to grant cross-browser compatibilty:
function nextElementSibling(el) {
if (el.nextElementSibling) return el.nextElementSibling;
do { el = el.nextSibling } while (el && el.nodeType !== 1);
return el;
}
This way, I can avoid the do/while loop for browsers that support nextElementSibling.
Maybe I'm too scared of WHILE loops in JS :)
One advantage of this solution is recursability:
//this will always works:
var e = nextElementSibling(nextElementSibling(this));
//this will crash on IE, as looking for a property of an undefined obj:
var e = this.nextElementSibling.nextElementSibling || nextElementSibling(nextElementSibling(this));
Firefox nextSibling returns whitespace \n while Internet Explorer does not.
Before nextElementSibling was introduced, we had to do something like this:
var element2 = document.getElementById("xxx").nextSibling;
while (element2.nodeType !=1)
{
element2 = element2.nextSibling;
}
The code is here:
http://jsfiddle.net/jf7t2/1/
Please run it on the latest versions of all browsers, and see for yourself. When the button is clicked, on:
on Chrome (and Safari of course) it just doesn't select anything, instead creates some ghostly empty option
on Firefox and Opera, it works the way I expect and want it to work, de-selects all options
on Internet Explorer, it does nothing
So, which one is the expected behaviour?
If you look at the jQuery 1.5.1 source code line 1970 you'll see this:
// Treat null/undefined as ""; convert numbers to string
if ( val == null ) {
val = "";
So the expected behavior is the same as if you gave the empty string as argument.
If you continue to line 1984 you'll see this:
} else if ( jQuery.nodeName( this, "select" ) ) {
var values = jQuery.makeArray(val);
jQuery( "option", this ).each(function() {
this.selected = jQuery.inArray( jQuery(this).val(), values ) >= 0;
});
if ( !values.length ) {
this.selectedIndex = -1;
}
So the expected behaviour is:
if there is an option with an empty string value, choose that.
if not set selectedIndex = -1
From here on it is up to the browser to determine what to do if selectedIndex is set to -1
Looking at the msdn library it says:
The selectedIndex property returns -1
if a select object does not contain
any selected items. Setting the
selectedIndex property clears any
existing selected items.
So in ie the expected behavior seems to be that it will de-select all options
The same goes for the MDC documentation and thus firefox, where theya re very explicit about it
Returns the index of the currently
selected item. You may select an item
by assigning its index to this
property. By assigning -1 to this
property, all items will be
deselected.
It seems webkit based browsers have a different take on things.
If you google "webkit selectedIndex" you will see quite a few bug report regarding the select tag, so maybe it's just funky ;)
Come to think of it, this is a bug in jQuery since it is a library that should be able to behave the same across browsers - it should be reported ;)
which one is expected behaviour?
jQuery's val() function is documented to take a string value or an array of string values, so there is no defined behaviour.
Try val([]) to select nothing, or to restore the original value use the defaultSelected property:
$('#select option').each(function() {
this.selected= this.defaultSelected;
});
I forked your jsfiddle with one that I think can help you:
http://jsfiddle.net/marcosfromero/AYLrT/
I tested it in IE, Firefox and Chrome
jQuery("#button").click(function(event){
var select = jQuery("#select");
// Button click will try to find a "none" option (with no value)
if(select.find('option.none').length===0) {
// If it's not found, it creates the option
select.prepend('<option value="" class="none"></option>');
}
// And then it selects it
select.val('');
});
// When select value is changed...
jQuery('#select').change(function() {
var me = $(this);
// ... to something different than empty ("")...
if(me.val() !== '') {
//... it removes that option
me.find('option.none').remove();
}
});
None of those behaviors are unreasonable.
In Chrome, it makes sense because you are setting the value to nothing, so it displays nothing.
In IE, it makes sense because you are not changing to a valid value, so it changes nothing.
If you want all the browsers to behave like Firefox, just set the value to 1.
why is if (element.innerHTML == "") not working in firefox
but works fine in IE , any ideas please ?
Hard to say without seeing your HTML, but I'd say probably because you have some empty white space in the element, and IE doesn't treat that as a text node, while FF does.
I believe it is actually a more strict standards compliance to treat any empty white space between tags as a text node, but IE doesn't comply.
You could do:
var htmlstring = element.innerHTML;
// use the native .trim() if it exists
// otherwise use a regular expression
htmlstring = (htmlstring.trim) ? htmlstring.trim() : htmlstring.replace(/^\s+/,'');
if(htmlstring == '') {...
Or just get rid of the whitespace in your HTML markup manually.
An alternative method to check for the empty string is to check the length:
element.innerHTML.length == 0
But, you'd still have to trim() if you had a whitespace string you wanted to match.
You could check if element.innerHTML.trim() == "" for the best results. However, then you have to extend the string prototype with a trim() method:
if (!String.prototype.trim) {
String.prototype.trim = function() { return this.replace(/^\s+|\s+$/, ''); };
}
if (element.innerHTML.trim() == "") {
//do something
}
For me, it seemed like setting my innerHTML was not working in Firefox nor Chrome but it did work in IE because of my error. It turned out that I was never getting the element using getElementById in the first place. IE seems to do just fine with elements which are defined with name= with getElementById but Firefox and Chrome was more stringent and accepts only id= elements. (More correctly in my view)
I hope this saves somebody some frustration.
Why does IE do these sorts of things and confuse people...