By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
437,636 Members | 1,213 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 437,636 IT Pros & Developers. It's quick & easy.

Element and Node are second class citizens in IE land

P: n/a
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
Jul 13 '08 #1
Share this Question
Share on Google+
12 Replies


P: n/a
Aaron Gray wrote:
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.

Jul 13 '08 #2

P: n/a
"Richard Cornford" <Ri*****@litotes.demon.co.ukwrote in message
news:g5*******************@news.demon.co.uk...
Aaron Gray wrote:
>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).
My school of programming says you should not put up barriers where none are
needed, you just disempower programmers and power users.

Aaron
Jul 13 '08 #3

P: n/a
On Jul 12, 5:49 pm, "Aaron Gray" <ang.use...@gmail.comwrote:
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
Jul 13 '08 #4

P: n/a
On Jul 12, 6:44 pm, "Aaron Gray" <ang.use...@gmail.comwrote:
"Richard Cornford" <Rich...@litotes.demon.co.ukwrote in message

news:g5*******************@news.demon.co.uk...
Aaron Gray wrote:
In FF you can define the following ...
Element.prototype.getClass = function() { return this.className; /* or
whatever */ }
Element.prototype.setClass = function(c) { this.className = c; }
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
Jul 13 '08 #5

P: n/a
On Jul 12, 8:50*pm, Peter Michaux <petermich...@gmail.comwrote:
On Jul 12, 6:44 pm, "Aaron Gray" <ang.use...@gmail.comwrote:
"Richard Cornford" <Rich...@litotes.demon.co.ukwrote in message
news:g5*******************@news.demon.co.uk...
Aaron Gray wrote:
>In FF you can define the following ...
>* *Element.prototype.getClass = function() { return this.className; /* or
>whatever */ }
>* *Element.prototype.setClass = function(c) { this.className = c; }

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__("c lientTop",
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
>
Peter
Jul 13 '08 #6

P: n/a
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
--
http://photo.gregorkofler.at ::: Landschafts- und Reisefotografie
http://web.gregorkofler.com ::: meine JS-Spielwiese
http://www.image2d.com ::: Bildagentur für den alpinen Raum
Jul 13 '08 #7

P: n/a
Gregor Kofler <us****@gregorkofler.atwrites:
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.

--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
Jul 13 '08 #8

P: n/a
On Jul 13, 1:20 am, dhtml <dhtmlkitc...@gmail.comwrote:
On Jul 12, 8:50 pm, Peter Michaux <petermich...@gmail.comwrote:
On Jul 12, 6:44 pm, "Aaron Gray" <ang.use...@gmail.comwrote:
"Richard Cornford" <Rich...@litotes.demon.co.ukwrote in message
>news:g5*******************@news.demon.co.uk...
Aaron Gray wrote:
In FF you can define the following ...
Element.prototype.getClass = function() { return this.className; /* or
whatever */ }
Element.prototype.setClass = function(c) { this.className = c; }
Augmenting Built-in (i.e. Native or Host) prototypes is generally

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

Jul 13 '08 #9

P: n/a
On Sun, 13 Jul 2008 at 02:44:12, in comp.lang.javascript, Aaron Gray
wrote:
>"Richard Cornford" <Ri*****@litotes.demon.co.ukwrote in message
news:g5*******************@news.demon.co.uk...
<snip>
>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.
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
--
John Harris
Jul 13 '08 #10

P: n/a
"John G Harris" <jo**@nospam.demon.co.ukwrote in message
news:V2**************@J.A830F0FF37FB96852AD08924D9 443D28E23ED5CD...
On Sun, 13 Jul 2008 at 02:44:12, in comp.lang.javascript, Aaron Gray
wrote:
>>"Richard Cornford" <Ri*****@litotes.demon.co.ukwrote in message
news:g5*******************@news.demon.co.uk...

<snip>
>>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.

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
Jul 13 '08 #11

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

Aaron
Agreed,

This bug (and the corresponding bug in IE Feedback can be tracked
here:
http://webbugtrack.blogspot.com/2007...lelements.html

Max
Jul 15 '08 #12

P: n/a
On Jul 15, 4:10*am, webbugtr...@gmail.com wrote:
>My school of programming says you should not put up barriers where none
are needed, you just disempower programmers and power users.
>Aaron

Agreed,

This bug (and the corresponding bug in IE Feedback can be tracked
here:http://webbugtrack.blogspot.com/2007...lelements.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).

Jul 15 '08 #13

This discussion thread is closed

Replies have been disabled for this discussion.