Element and Node are second class citizens in IE land

Discussion in 'Javascript' started by Aaron Gray, Jul 13, 2008.

  1. Aaron Gray

    Aaron Gray Guest

    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
     
    Aaron Gray, Jul 13, 2008
    #1
    1. Advertising

  2. 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.
     
    Richard Cornford, Jul 13, 2008
    #2
    1. Advertising

  3. Aaron Gray

    Aaron Gray Guest

    "Richard Cornford" <> wrote in message
    news:g5bl8c$sap$1$...
    > 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
     
    Aaron Gray, Jul 13, 2008
    #3
  4. On Jul 12, 5:49 pm, "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 !


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

    Peter
     
    Peter Michaux, Jul 13, 2008
    #4
  5. On Jul 12, 6:44 pm, "Aaron Gray" <> wrote:
    > "Richard Cornford" <> wrote in message
    >
    > news:g5bl8c$sap$1$...
    >
    > > 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
     
    Peter Michaux, Jul 13, 2008
    #5
  6. Aaron Gray

    dhtml Guest

    On Jul 12, 8:50 pm, Peter Michaux <> wrote:
    > On Jul 12, 6:44 pm, "Aaron Gray" <> wrote:
    >
    > > "Richard Cornford" <> wrote in message

    >
    > >news:g5bl8c$sap$1$...

    >
    > > > 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__("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

    >
    > Peter
     
    dhtml, Jul 13, 2008
    #6
  7. 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
     
    Gregor Kofler, Jul 13, 2008
    #7
  8. Gregor Kofler <> writes:

    > 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/
     
    Joost Diepenmaat, Jul 13, 2008
    #8
  9. On Jul 13, 1:20 am, dhtml <> wrote:
    > On Jul 12, 8:50 pm, Peter Michaux <> wrote:
    >
    > > On Jul 12, 6:44 pm, "Aaron Gray" <> wrote:

    >
    > > > "Richard Cornford" <> wrote in message

    >
    > > >news:g5bl8c$sap$1$...

    >
    > > > > 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
     
    Peter Michaux, Jul 13, 2008
    #9
  10. On Sun, 13 Jul 2008 at 02:44:12, in comp.lang.javascript, Aaron Gray
    wrote:
    >"Richard Cornford" <> wrote in message
    >news:g5bl8c$sap$1$...


    <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
     
    John G Harris, Jul 13, 2008
    #10
  11. Aaron Gray

    Aaron Gray Guest

    "John G Harris" <> wrote in message
    news:830F0FF37FB96852AD08924D9443D28E23ED5CD...
    > On Sun, 13 Jul 2008 at 02:44:12, in comp.lang.javascript, Aaron Gray
    > wrote:
    >>"Richard Cornford" <> wrote in message
    >>news:g5bl8c$sap$1$...

    >
    > <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
     
    Aaron Gray, Jul 13, 2008
    #11
  12. Aaron Gray

    Guest

    , Jul 15, 2008
    #12
  13. Aaron Gray

    Henry Guest

    On Jul 15, 4:10 am, 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/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).
     
    Henry, Jul 15, 2008
    #13
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    0
    Views:
    1,649
  2. Tjerk Wolterink
    Replies:
    2
    Views:
    1,508
    Dimitre Novatchev
    Aug 24, 2006
  3. Tejal

    JAVA DEVELOPERS GC/CITIZENS

    Tejal, Feb 16, 2007, in forum: Java
    Replies:
    1
    Views:
    286
    Andrew Thompson
    Feb 16, 2007
  4. Imran
    Replies:
    0
    Views:
    335
    Imran
    May 30, 2007
  5. DG
    Replies:
    4
    Views:
    309
    Tomás Ó hÉilidhe
    Nov 25, 2007
Loading...

Share This Page