Site Navigation

Showing posts with label ID Attribute. Show all posts
Showing posts with label ID Attribute. Show all posts

Thursday, October 29, 2009

bug 361 - Anchors collection in IE contains invalid members

Issue: #361
Affects: IE6, IE7, IE8

In the days before the DOM Methods we have today we only had access to a few special collections for things like forms, anchors, links, images, etc.

They may not be as sexy as document.getElementById(), but they worked, and still do to this day... and depending what you are trying to access may actually be much quicker and easier.

So to the point, the document.anchors collection contains an array of all the anchors defined in the page.

Anchors by definition are <a> tags with a name attribute specified.

Now for the bug.

As disclosed in (bug 152) IE has notoriously had issues with differentiating between id and name attributes, polluting IDs with NAMEs and vica versa.

Thus, if you have hyperlinks with an id attribute set in IE... you will now have a new member in the document.anchors collection even though there is no name attribute specified! Have lots of links with id attributes set? Then you have lots of extra items in your document.anchors collection.

Of course the interesting twist on this is that in modern browsers, any element (div, table, span, img) with an id attribute set can act "like" an anchor in that you can add it as a hash tag in the URL to auto-scroll to a specific spot however keep in mind that by definition only an <a> tag with a name attribute set is a valid element in the document.anchors collection.


Known Workarounds: None.



Related Issues: None.


Bug/Site Feedback |
Submit a bug

Friday, July 10, 2009

bug 167 - Flash ActionScript communication with IE fails

Issue: #167
Affects: IE6, IE7, IE8

Adobe's Flash /(SWF) uses ActionScript to interact with the browser and your HTML page. In particular you can call a JavaScript function on your page by using the ExternalInterface Object, using the .call(methodName) method.

However although the code is simple to invoke, you may drive yourself bonkers trying to figure out why it sometimes fails in IE.

Example:

//required imports
import flash.external.ExternalInterface;
//...your code...
ExternalInterface.call('yourPagesJSFunction');//Fails in IE (sometimes)


So how can this simple code work in Firefox and Safari yet fail in IE?


Known Workarounds: One.

The trick is in the unknown requirement... in IE, your <object> tag REQUIRES an ID attribute! The value doesn't matter, but it must be unique (all your IDs are unique aren't they?)


Example Workaround Code:

<object id="anyvalue">



Related Issues: None.

Bug/Site Feedback |
Submit a bug

Saturday, June 7, 2008

Bug or Feature? - Round Three

Round Three - If more than one ID, which one matches?

Other rounds: [One|Two|Three|Four|Five]

We're back again with another round of "Bug or Feature?" (see round one) highlighting a particular behavior in one or more browsers, that, well, could be a Bug, or it could be a Feature... we'll open up the comments for your vote and opinion.

Alright, what's todays "Bug or Feature"?

Synopsis:
The HTML id attribute is designed to uniquely identify a particular element.

However, what if you accidentally end up with 2 or more elements with the same ID?
Obviously this is a bug, but how different browsers handle it, is what makes it interesting.

All browsers tend to return the first matching element in the DOM order with the same id when using .getElementById(id). However if you have an HTML Label element, with a for attribute that points to the id attribute of a field, things aren't quite so clear.

Firefox, Safari & Opera all link to the first form element with the matching id.
Internet Explorer links to the last form element with the matching id.

Question is, is IE's different behavior a bug? or a feature?

Example HTML snippet:

<label for="obj1_prop1">Size:</label>
<input id="obj1_prop1" type="text" size="5">
<label for="obj1_prop1">Quantity:</label>
<input id="obj1_prop1" type="text" size="5">


Question:
Does linking to the last element vs. the first element expose a feature? or is it a bug?

Test it for yourself, click on the labels Size and Quantity:





Is this a Bug? Or a Feature?

Vote "Bug" or "Feature", and add your thoughts.

Tuesday, May 13, 2008

bug 326 - field names in IE that break with Mootools

Issue: #326
Affects: IE6, IE7, IE8 Beta 1?
JS Library: Mootools
Mootools Trac#:798

The following fields (name or id) will cause issues in Mootools:

"addEvent", "match", "position", "search"

Due to conflicts when the name exists in Element.Prototype, it will cause issues.

Example:
These will fail when you try to iterate using .each (for example) over a form element array.

<input id="addEvent"/>
<input id="match"/>
<input id="position"/>
<input id="search"/>

<input name="addEvent"/>
<input name="match"/>
<input name="position"/>
<input name="search"/>



Known Workarounds: None. (other than to be careful not to use these field identifiers)


Related Issues: None.

Bug/Site Feedback |
Submit a bug

Friday, August 24, 2007

bug 152 - getElementById returns incorrect objects in IE and Opera

Issue: #152
Affects: IE5, IE5.5, IE6, IE7, Opera 8.2, Opera 9.2
Fixed in: Opera 9.50 alpha 1 build 9500
Almost Fixed in: IE8 Beta 1
Fixed in: IE8 Beta 2

MSIE Feedback ID: 333979

Example:
<script type="text/javascript">
var descField = document.getElementById( 'description' );
alert( descField.nodeName );
</script>

The above code works perfectly, in all browsers returning the element with the id "description". Well almost. IE will return the element with that id, but it will also return any element with a name set to "description". At first glance this may not seem such an issue, but consider this; Do you have a meta tag on any of your pages? Do any of them have a name attribute with the value description? If so, you will get a reference to the meta tag, not the form element (or whatever you thought you were getting, as indicated in the spec for getElementById).

When you think for a moment, about where the name attribute is set, this becomes rather scary. Any named anchor, can now conflict with your well defined element ids.

Notes:
So you might ask, why is this broken in Opera? Opera is usually pretty good at supporting the specs! Well, it seems that for maximum compatibility with IE, even though it is implemented wrong, they mimicked the broken behavior.


Known Workarounds: No direct methods, using Option #3 below is suggested.

Workaround Option: 1
If you rely heavily on getElementById, and you suspect that you may have name conflicts, or that user specific content added to a page may cause conflicts you can use getElementsByTagName( tagName ) then iterate over the results and compare the value returned by getAttribute( 'id' ).

Example Workaround Code:
var inputs = document.getElementsByTagName( 'textarea' );
var descField = null;
for(var i=0;i<inputs.length;i++){
if(inputs.item(i).getAttribute( 'id' ) == 'description' ){
descField = inputs.item(i);
break;
}
}




Workaround Option: 2
If you have the ability to globally apply fixes for IE and Opera, the following code will make both of them follow the spec to a 'T', with a very tiny performance hit.

In this example, we redifine the getElementById method, to work as it was intended.
Example Workaround Code:
//use browser sniffing to determine if IE or Opera (ugly, but required)
var isOpera, isIE = false;
if(typeof(window.opera) != 'undefined'){isOpera = true;}
if(!isOpera && navigator.userAgent.indexOf('Internet Explorer')){isIE = true;}

//fix both IE and Opera (adjust when they implement this method properly)
if(isOpera || isIE){
document.nativeGetElementById = document.getElementById;
//redefine it!
document.getElementById = function(id){
var elem = document.nativeGetElementById(id);
if(elem){
//verify it is a valid match!
if(elem.id == id){
//valid match!
return elem;
} else {
//not a valid match!
//the non-standard, document.all array has keys for all name'd, and id'd elements
//start at one, because we know the first match, is wrong!
for(var i=1;i<document.all[id].length;i++){
if(document.all[id][i].id == id){
return document.all[id][i];
}
}
}
}
return null;
};
}



Oh my! this just gets better and better! (after posting and using this I noted (as did J. Max Wilson) that the second workaround, actually exposes another bug in IE!

Third time's a charm (we hope!)

Workaround Option: 3

Same as workaround 2 above, but rather than test elem.id or elem.getAttribute('id') we'll use the much safer elem.attributes collection. Unfortunately if the element you are looking for, in turn has a child element with a name or id attribute, that is set to "id", it will not test the attribute, but rather the child element. (bug 162 - global namespace pollution)

Example Workaround Code:
//use browser sniffing to determine if IE or Opera (ugly, but required)
var isOpera, isIE = false;
if(typeof(window.opera) != 'undefined'){isOpera = true;}
if(!isOpera && navigator.userAgent.indexOf('Internet Explorer')){isIE = true;}

//fix both IE and Opera (adjust when they implement this method properly)
if(isOpera || isIE){
document.nativeGetElementById = document.getElementById;
//redefine it!
document.getElementById = function(id){
var elem = document.nativeGetElementById(id);
if(elem){
//verify it is a valid match!
if(elem.attributes['id'] && elem.attributes['id'].value == id){
//valid match!
return elem;
} else {
//not a valid match!
//the non-standard, document.all array has keys for all name'd, and id'd elements
//start at one, because we know the first match, is wrong!
for(var i=1;i<document.all[id].length;i++){
if(document.all[id][i].attributes['id'] && document.all[id][i].attributes['id'].value == id){
return document.all[id][i];
}
}
}
}
return null;
};
}




Related Issues: (bug 154), (bug 411), (bug 162).