Element and Node are second class citizens in IE land

A

Aaron Gray

In FF you can define the following ...

Element.prototype.getClass = function() { return this.className; /* or
whatever */ }
Element.prototype.setClass = function(c) { this.className = c; }

But it don't work in IE.

Basically in IE land Element and Node are second class objects with no
prototypical behaviour, unlike Object, Number, and friends.

Bad Microsoft !

Regards,

Aaron
 
R

Richard Cornford

Aaron said:
In FF you can define the following ...

Element.prototype.getClass = function() { return this.className; /*
or whatever */ }
Element.prototype.setClass = function(c) { this.className = c; }

But it don't work in IE.

Basically in IE land Element and Node are second class objects with no
prototypical behaviour, unlike Object, Number, and friends.

Bad Microsoft !

No standard says that constructors and/or prototypes should be exposed
for W3C DOM defined interfaces (indeed it could easily be argued that
interfaces should not have constructors and/or prototypes).

Richard.
 
A

Aaron Gray

Richard Cornford said:
No standard says that constructors and/or prototypes should be exposed for
W3C DOM defined interfaces (indeed it could easily be argued that
interfaces should not have constructors and/or prototypes).

My school of programming says you should not put up barriers where none are
needed, you just disempower programmers and power users.

Aaron
 
P

Peter Michaux

In FF you can define the following ...

Element.prototype.getClass = function() { return this.className; /* or
whatever */ }
Element.prototype.setClass = function(c) { this.className = c; }

But it don't work in IE.

Basically in IE land Element and Node are second class objects with no
prototypical behaviour, unlike Object, Number, and friends.

Bad Microsoft !

If you read the ECMAScript standard, you will see that Host Objects
can behave very differently than Native Objects.

Peter
 
P

Peter Michaux

Augmenting Built-in (i.e. Native or Host) prototypes is generally
considered a bad practice. It has burned many library authors (e.g.
Prototype.js authors) who have done it because it gives them a warm
fuzzy feeling to see some particular syntax. "Don't modify objects you
don't own" is commonly good advice.


[snip]
My school of programming says you should not put up barriers where none are
needed, you just disempower programmers and power users.

It is more important to deal with the reality of the current
situation. The browsers are what they are.


Peter
 
D

dhtml

Augmenting Built-in (i.e. Native or Host) prototypes is generally

built-in object and Host object have distictly different meanings.

Augmenting a built-in object is considerably safer, in that the
outcome is likely to be defined by the EcmaScript 262 spec.

For example:

Error.prototype.toString = function() {
return this.name + ": " + this.message;
};

The "toString" property of Error.prototype is not defined as
ReadOnly.

It's not the most polite thing to do, in that it may interfere with
someone else's toString, so it's a good idea to at least make sure
you've got a broken feature before fixing it.
var result = Error.prototype.toString.call({name:"test"});
if(result == "[object Error]") {
// fix.
}

Augmenting Host object, OTOH, is not really defined by any standard
and results will vary from browsers and versions.

javascript:var e =
document.body.__proto__;void(e.__defineGetter__("clientTop",
function() { return -1; }));alert(document.body.clientTop)

Safari3: alert "0"
Firefox3 alert "-1"

There is no official standard for "clientTop" or if it is present on
any element, if it should be an instance property, a getter in the
prototype, et c.
considered a bad practice. It has burned many library authors (e.g.
Prototype.js authors) who have done it because it gives them a warm
fuzzy feeling to see some particular syntax. "Don't modify objects you
don't own" is commonly good advice.

It is a very powerful technique.

It's not standardized.

"Don't modify objects you don't own" is good advice. Modifying
HTMLElement.prototype to add on extra features that can be used by
each element sort of puts the new functionality in the wrong place,
sometimes even causing a collision (like as in above, or could be with
a "document.getElementsByClassName" collision). It's not safe.

Garrett
 
G

Gregor Kofler

Aaron Gray meinte:
In FF you can define the following ...

Element.prototype.getClass = function() { return this.className; /* or
whatever */ }
Element.prototype.setClass = function(c) { this.className = c; }

But it don't work in IE.

Basically in IE land Element and Node are second class objects with no
prototypical behaviour, unlike Object, Number, and friends.

That's because they're DOM elements, and not native JS objects.
Bad Microsoft !

I'd rather say, that augmenting DOM elements is bad practice.

Gregor
 
J

Joost Diepenmaat

Gregor Kofler said:
I'd rather say, that augmenting DOM elements is bad practice.

Well, only because it's not guaranteed to work (and indeed doesn't
work in the most popular browser at this time).

Personally, I think it would be great if extending the Element
prototype would work everywhere. But then, I don't think there's
anything fundamentally wrong with extending Object.prototype and
friends either.
 
P

Peter Michaux

built-in object and Host object have distictly different meanings.

Strike what I said. "Don't modify objects which you don't own" covers
the cases I'm describing whatever the correct technical terminology
happens to be.

Peter
 
J

John G Harris

My school of programming says you should not put up barriers where none are
needed, you just disempower programmers and power users.

Another school says that rendering HTML should be fast and smooth. It's
less important if access by VBScript and javascript is slow and ugly.

John
 
A

Aaron Gray

John G Harris said:
Another school says that rendering HTML should be fast and smooth. It's
less important if access by VBScript and javascript is slow and ugly.

How come Gecko is faster then ?

Aaron
 
H

Henry

Agreed,

This bug (and the corresponding bug in IE Feedback can be tracked
here:http://webbugtrack.blogspot.com/2007/08/bug-186-cant-prototype-on-htmlelements.html

A bug would be a discrepancy between actual behaviour and required
behaviour. As there is no requirement that DOM interface prototypes be
exposed their not being exposed cannot be a bug. Correcting a
discrepancy between actual behaviour and desired behaviour would be an
enhancement.

Incidentally, the "bug" report is not particularly accurate as it
asserts that there are no workarounds, while there are many.
(Including, but not restricted to, Prototypes.js' strategy of using a
single function to retrieve all elements and having that function
directly modify the elements it retrieves).
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top