FF & IE: css class problem

[fazfazzi]

Hi
I have a set of javascript functions that has to operate on class
attribute form some elements via DOM
I heard that .className works on IE, instead then .setAttribute
("class","miaclasse");
The problem is that .className doesn't work on FF, so, how can i do? I
thougth that if i could have two
separate .js file, one for FF the other for IE the issue will solve,
but can i do such a thing?
Thanks

 

[Henry]

Hi
I have a set of javascript functions that has to operate
on class attribute form some elements via DOM
I heard that .className works on IE, instead then .setAttribute
("class","miaclasse");
The problem is that .className doesn't work on FF, ...

<snip>

".className" "works on" FF in exactly the same way as it "works on" IE.

 

[David Mark]

Hi
I have a set of javascript functions that has to operate on class
attribute form some elements via DOM
I heard that .className works on IE, instead then .setAttribute
("class","miaclasse");

You virtually never need setAttribute (in any browser.) This is a
good thing as IE's implementation is broken as designed. In this
case, use the className property (it is not IE-specific.)

[snip]

 

[fazfazzi]

You virtually never need setAttribute (in any browser.)  This is a
good thing as IE's implementation is broken as designed.  In this
case, use the className property (it is not IE-specific.)

[snip]

Thanks, i resolved the problem.
..setAttribute isn't browser-independant?

 

[Thomas 'PointedEars' Lahn]

..setAttribute isn't browser-independant?

Yes.


PointedEars

 

[David Mark]

You virtually never need setAttribute (in any browser.) �This is a
good thing as IE's implementation is broken as designed. �In this
case, use the className property (it is not IE-specific.)

[snip]

Thanks, i resolved the problem.
.setAttribute isn't browser-independant?

It has always been broken as designed in IE.

For example:

el.setAttribute('class', 'test'); // Would work if IE were not broken

is treated as:

el.class = 'test';

This doesn't do anything useful as the property name is "className"
not "class."

Same problem for "for" and a few others. Then there are properties
that are not strings (e.g. "style"):

el.style = 'test'; // No good

Same problem with getAttribute, where - for example - "src", "href",
"longDesc", etc. are transformed by the DOM, rendering IE's results
absolute, even when the attributes contain relative paths.

So don't use get/setAttribute unless you absolutely have to (and you
almost never have to.)

 

[fazfazzi]

(e-mail address removed) wrote:

Same problem with getAttribute, where - for example - "src", "href",
"longDesc", etc. are transformed by the DOM, rendering IE's results
absolute, even when the attributes contain relative paths.

So don't use get/setAttribute unless you absolutely have to (and you
almost never have to.)

uhm i dont' know i can avoid using it.. i have to create a form
dinamically with jscript...

 

[David Mark]

uhm i dont' know i can avoid using it.. i have to create a form
dinamically with jscript...

Um, now you do.

 

[dhtml]

(e-mail address removed) wrote:

Same problem with getAttribute, where - for example - "src", "href",
"longDesc", etc. are transformed by the DOM, rendering IE's results
absolute, even when the attributes contain relative paths.

These properties are designed to return a URI (as properties). In the
HTML DOM spec[1], the href is designed to return a URI, and refers to
HTML 4.01 for this[2].

SInce IE treats getAttribute(s), as if - s - were a property, the
property value is returned instead of the actual attribute value. It is,
as you said, "broken by design" in IE.

IE will also return the "checked" property with getAttribute("checked")
- on a checkbox.

[1]http://www.w3.org/TR/REC-DOM-Level-1/level-one-html.html
[2]http://www.w3.org/TR/REC-html40/struct/objects.html#adef-longdesc-IMG