storing temporary variables in dom nodes

Discussion in 'Javascript' started by yawnmoth, Sep 26, 2009.

  1. yawnmoth

    yawnmoth Guest

    I'm trying to make a function that'll change the CSS class (className)
    of an HTML element while preserving the old class. The problem is
    that the old class can be one of any number of classes. As such, I
    was wondering what the best way to go about saving the old className
    is. I could do something like "element.oldClassName =
    element.className; element.className = 'whatever';", but that would
    kinda result in invalid (X)HTML. ie.

    <img src="." alt="" class="whatever" /> is valid XHTML but <img
    src="." alt="" oldclassname="whatever" /> isn't because the specs
    don't define for an attribute called oldclassname for the img element.

    So what other alternatives are out there? I could assign each element
    a unique id and then associate the unique id to the old class name via
    an object / associative array, but that seems excessive.
     
    yawnmoth, Sep 26, 2009
    #1
    1. Advertising

  2. yawnmoth

    JR Guest

    On Sep 26, 3:08 pm, yawnmoth <> wrote:
    > I'm trying to make a function that'll change the CSS class (className)
    > of an HTML element while preserving the old class.  The problem is
    > that the old class can be one of any number of classes.  As such, I
    > was wondering what the best way to go about saving the old className
    > is.  I could do something like "element.oldClassName =
    > element.className; element.className = 'whatever';", but that would
    > kinda result in invalid (X)HTML.  ie.


    Not if you do so via Javascript. E.g:

    function addClass (el, newClassName) {
    var oldClassName = el.className;
    el.className = (!oldClassName) ? newClassName : (oldClassName +" " +
    newClassName);
    };

    Or suppose a function to change an element's display:

    function hideElement(el, val) {
    var curCSSDisplay = getStyle(el, 'display'); // getStyle is not
    supplied here.
    if (curCSSDisplay !== 'none') {
    el.oldDisplayStyle = curCSSDisplay; // saves for later use.
    el.style.display = 'none';
    }
    }

    In the above example, we can store the old display style as a property
    for later use

    It's just an example...


    > <img src="." alt="" class="whatever" /> is valid XHTML but <img
    > src="." alt="" oldclassname="whatever" /> isn't because the specs
    > don't define for an attribute called oldclassname for the img element.


    You should go that with Javascript not with HTML directly.


    Cheers,
    JR
     
    JR, Sep 26, 2009
    #2
    1. Advertising

  3. yawnmoth

    Jorge Guest

    On Sep 26, 8:34 pm, JR <> wrote:
    > (...)
    > function addClass (el, newClassName) {
    >   var oldClassName = el.className;
    >   el.className = (!oldClassName) ? newClassName : (oldClassName +" " +
    > newClassName);
    >
    > };
    > (...)


    Beware :)

    If "el" had className === "clickable visible active" and you did
    addClass(el, "visible") it would yield el.className === "clickable
    visible active visible" which is wrong behaviour... :-(

    Cheers,
    --
    Jorge.
     
    Jorge, Sep 26, 2009
    #3
  4. yawnmoth

    JR Guest

    On Sep 26, 7:43 pm, Jorge <> wrote:
    > On Sep 26, 8:34 pm, JR <> wrote:
    >
    > > (...)
    > > function addClass (el, newClassName) {
    > >   var oldClassName = el.className;
    > >   el.className = (!oldClassName) ? newClassName : (oldClassName +" " +
    > > newClassName);

    >
    > > };
    > > (...)

    >
    > Beware :)


    Just a typo because of 'copy and paste' from another code of mine ...
    Thanks.


    > If "el" had className === "clickable visible active" and you did
    > addClass(el, "visible") it would yield el.className === "clickable
    > visible active visible" which is wrong behaviour... :-(


    Okay, thanks for the advice, although that kind of various classnames
    would be unlikely to happen in my pages.

    Cheers,
    JR
     
    JR, Sep 27, 2009
    #4
  5. yawnmoth wrote:
    > I'm trying to make a function that'll change the CSS class (className)
    > of an HTML element while preserving the old class. The problem is
    > that the old class can be one of any number of classes. As such, I
    > was wondering what the best way to go about saving the old className
    > is. I could do something like "element.oldClassName =
    > element.className; element.className = 'whatever';", but that would
    > kinda result in invalid (X)HTML. ie.
    >
    > <img src="." alt="" class="whatever" /> is valid XHTML but <img
    > src="." alt="" oldclassname="whatever" /> isn't because the specs
    > don't define for an attribute called oldclassname for the img element.


    If you set
    element.oldClassName
    then you are not setting an attribute of the element node, only a
    property of the element object. Unless you test in IE's broken DOM
    implementation that does not distinguish between properties and attributes.
    So I don't see how setting that property results in any HTML or XHTML
    attribute being present.

    On the other hand setting previously undefined properties on host
    objects is not required to work.

    --

    Martin Honnen
    http://msmvps.com/blogs/martin_honnen/
     
    Martin Honnen, Sep 27, 2009
    #5
  6. yawnmoth

    Jorge Guest

    On Sep 27, 2:23 am, JR <> wrote:
    > On Sep 26, 7:43 pm, Jorge <> wrote:
    >
    > > If "el" had className === "clickable visible active" and you did
    > > addClass(el, "visible") it would yield el.className === "clickable
    > > visible active visible" which is wrong behaviour... :-(

    >
    > Okay, thanks for the advice, although that kind of various classnames
    > would be unlikely to happen in my pages.


    In any case, ISTM that before appending a className you should check
    first that the element does not have it already.

    Cheers,
    --
    Jorge
     
    Jorge, Sep 27, 2009
    #6
  7. yawnmoth

    Jorge Guest

    On Sep 27, 12:11 pm, Martin Honnen <> wrote:
    > (...)
    > On the other hand setting previously undefined properties on host
    > objects is not required to work.


    Might not be required "by the spec", but de-facto it's a requisite, at
    least for DOM Node(s), istm.

    --
    Jorge.
     
    Jorge, Sep 27, 2009
    #7
  8. On 27 ÓÅÎ, 14:11, Martin Honnen <> wrote:

    > If you set
    > š šelement.oldClassName
    > then you are not setting an attribute of the element node, only a
    > property of the element object. Unless you test in IE's broken DOM
    > implementation that does not distinguish between properties and attributes.


    Better to say "between properties that *should updated related
    attributes* and all the other properties", 'cause in first place
    getter and setter of the property set (in one of the code actions)
    that attribute (e.g. id-property, id-attribute). This approach is good
    seen in Mozilla's XUL-system: when creating own XML-bindings (own
    widgets), some of the properties are described as:

    <property name="disabled">
    <getter>
    return (this.getAttribute('disabled') === 'true')
    </getter>
    <setter>
    this.setAttribute('disabled', val); // val - is formal parameter
    of the wrapped created function
    </setter>
    </property>

    This XML-markup after that is build into JS host objects (inherited
    e.g. from the XULElement/HTMLElemet), and that objects has property
    "disabled" which handles related attributes. But e.g. property
    "myOwnProperty" will not set related attribute (if only you don't do
    it yourself in setter). This principle is very useful in case of CSS-
    design, where e.g. we can use attributes as selectors:

    dwdiget {
    color: #000;
    }

    dwidget[disabled="true"] {
    color: #999;
    }

    and to manage this attributes via related properties.
     
    Dmitry A. Soshnikov, Sep 27, 2009
    #8
  9. yawnmoth

    David Mark Guest

    On Sep 27, 7:07 am, Jorge <> wrote:
    > On Sep 27, 12:11 pm, Martin Honnen <> wrote:
    >
    > > (...)
    > > On the other hand setting previously undefined properties on host
    > > objects is not required to work.

    >
    > Might not be required "by the spec", but de-facto it's a requisite, at
    > least for DOM Node(s), istm.


    ISTM, you have jumped to a wild conclusion. DOM node expando
    properties are neither required nor advisable. Not only do some
    browsers (and configurations) throw exceptions, they are also a good
    way to create memory leaks (e.g. augmenting event objects).

    You've got enough to worry about. Don't design things that rely on
    big if's like expando properties, ActiveX, deferred scripts, MS
    hotfixes, etc. Or you can go all-out in the opposite direction and
    use something like jQuery, which gleefully exploits any fleeting bug/
    feature/happenstance until it seems to stop working (then a rewrite
    appears claiming to fix those buggy browsers once and for all). It's
    programming for failure for all involved. The only (technical) people
    who can't see that are those who see failure as the only option (e.g.
    ten years later, these browsers are just too darn buggy).

    Like it or not, software design is not a matter of taste. The results
    of poor designs are not "good enough" and all it takes is a quick spin
    around the Web (in any browser) to see this is the case.
     
    David Mark, Sep 28, 2009
    #9
  10. yawnmoth

    Jorge Guest

    On Sep 28, 1:13 am, David Mark <> wrote:
    > On Sep 27, 7:07 am, Jorge <> wrote:
    >
    > > On Sep 27, 12:11 pm, Martin Honnen <> wrote:

    >
    > > > (...)
    > > > On the other hand setting previously undefined properties on host
    > > > objects is not required to work.

    >
    > > Might not be required "by the spec", but de-facto it's a requisite, at
    > > least for DOM Node(s), istm.

    >
    > ISTM, you have jumped to a wild conclusion.  DOM node expando
    > properties are neither required nor advisable.  Not only do some
    > browsers (and configurations) throw exceptions, they are also a good
    > way to create memory leaks (e.g. augmenting event objects).
    >
    > You've got enough to worry about.  Don't design things that rely on
    > big if's like expando properties, ActiveX, deferred scripts, MS
    > hotfixes, etc.  Or you can go all-out in the opposite direction and
    > use something like jQuery, which gleefully exploits any fleeting bug/
    > feature/happenstance until it seems to stop working (then a rewrite
    > appears claiming to fix those buggy browsers once and for all).  It's
    > programming for failure for all involved.  The only (technical) people
    > who can't see that are those who see failure as the only option (e.g.
    > ten years later, these browsers are just too darn buggy).
    >
    > Like it or not, software design is not a matter of taste.  The results
    > of poor designs are not "good enough" and all it takes is a quick spin
    > around the Web (in any browser) to see this is the case.


    Yeah, in the real life there are 4 pretty good browsers and crap like
    [the whole set of IEs], nearly 50-50. I live in the real life and I
    program just for the 4 pretty good ones. It's a luxury that was not
    possible just 3 years ago. I'll keep using expandos, the <canvas>,
    gestures, css animations, <audio> and <video> tags, webWorkers,
    geoLocation, and whatever else these 4 pretty-good browsers provide
    me, asap, and 100% regardless of M$ its IEs and their "peculiarities",
    to say it so. That's my taste and I do software design.

    --
    Jorge.
     
    Jorge, Sep 28, 2009
    #10
  11. yawnmoth

    David Mark Guest

    On Sep 27, 9:11 pm, Jorge <> wrote:
    > On Sep 28, 1:13 am, David Mark <> wrote:
    >
    >
    >
    > > On Sep 27, 7:07 am, Jorge <> wrote:

    >
    > > > On Sep 27, 12:11 pm, Martin Honnen <> wrote:

    >
    > > > > (...)
    > > > > On the other hand setting previously undefined properties on host
    > > > > objects is not required to work.

    >
    > > > Might not be required "by the spec", but de-facto it's a requisite, at
    > > > least for DOM Node(s), istm.

    >
    > > ISTM, you have jumped to a wild conclusion.  DOM node expando
    > > properties are neither required nor advisable.  Not only do some
    > > browsers (and configurations) throw exceptions, they are also a good
    > > way to create memory leaks (e.g. augmenting event objects).

    >
    > > You've got enough to worry about.  Don't design things that rely on
    > > big if's like expando properties, ActiveX, deferred scripts, MS
    > > hotfixes, etc.  Or you can go all-out in the opposite direction and
    > > use something like jQuery, which gleefully exploits any fleeting bug/
    > > feature/happenstance until it seems to stop working (then a rewrite
    > > appears claiming to fix those buggy browsers once and for all).  It's
    > > programming for failure for all involved.  The only (technical) people
    > > who can't see that are those who see failure as the only option (e.g.
    > > ten years later, these browsers are just too darn buggy).

    >
    > > Like it or not, software design is not a matter of taste.  The results
    > > of poor designs are not "good enough" and all it takes is a quick spin
    > > around the Web (in any browser) to see this is the case.

    >
    > Yeah, in the real life there are 4 pretty good browsers


    Presumably the four you have handy for observation.

    > and crap like
    > [the whole set of IEs], nearly 50-50.


    Odds are, you are wrong.

    > I live in the real life and I
    > program just for the 4 pretty good ones.


    The ones you heve.

    > It's a luxury that was not
    > possible just 3 years ago.


    When you only had three?

    > I'll keep using expandos,


    Whatever, Jorge.

    > the <canvas>,


    So what? If you do it because you spotted it in four browsers that
    you deem "pretty good", you have a problem. If you detect and/or test
    that feature, you are fine. It's not rocket science.

    > gestures,


    Leave those alone.

    > css animations,


    So, again (see above).

    > <audio> and <video> tags, webWorkers,


    You would.

    > geoLocation, and whatever else these 4 pretty-good browsers provide


    They provide all that? Pretty good (for now). IIRC, you assume these
    four always provide scripting as well. Can you see the problem with
    such unreal assumptions?

    > me, asap, and 100% regardless of M$ its IEs and their "peculiarities",


    So you deliberately exclude IE users, as well as people who disabled
    scripting.

    > to say it so. That's my taste and I do software design.


    You've described some pretty bad design decisions that alienate IE
    users (for one). The result of which will be a bad Website every
    time. That's reality, not a matter of taste. There are actually IE
    users (not to mention people who disable scripting) out there.
     
    David Mark, Sep 28, 2009
    #11
  12. yawnmoth

    Jorge Guest

    On Sep 28, 3:11 am, Jorge <> wrote:
    > On Sep 28, 1:13 am, David Mark <> wrote:
    >
    >
    >
    >
    >
    > > On Sep 27, 7:07 am, Jorge <> wrote:

    >
    > > > On Sep 27, 12:11 pm, Martin Honnen <> wrote:

    >
    > > > > (...)
    > > > > On the other hand setting previously undefined properties on host
    > > > > objects is not required to work.

    >
    > > > Might not be required "by the spec", but de-facto it's a requisite, at
    > > > least for DOM Node(s), istm.

    >
    > > ISTM, you have jumped to a wild conclusion.  DOM node expando
    > > properties are neither required nor advisable.  Not only do some
    > > browsers (and configurations) throw exceptions, they are also a good
    > > way to create memory leaks (e.g. augmenting event objects).

    >
    > > You've got enough to worry about.  Don't design things that rely on
    > > big if's like expando properties, ActiveX, deferred scripts, MS
    > > hotfixes, etc.  Or you can go all-out in the opposite direction and
    > > use something like jQuery, which gleefully exploits any fleeting bug/
    > > feature/happenstance until it seems to stop working (then a rewrite
    > > appears claiming to fix those buggy browsers once and for all).  It's
    > > programming for failure for all involved.  The only (technical) people
    > > who can't see that are those who see failure as the only option (e.g.
    > > ten years later, these browsers are just too darn buggy).

    >
    > > Like it or not, software design is not a matter of taste.  The results
    > > of poor designs are not "good enough" and all it takes is a quick spin
    > > around the Web (in any browser) to see this is the case.

    >
    > Yeah, in the real life there are 4 pretty good browsers and crap like
    > [the whole set of IEs], nearly 50-50. I live in the real life and I
    > program just for the 4 pretty good ones. It's a luxury that was not
    > possible just 3 years ago. I'll keep using expandos, the <canvas>,
    > gestures, css animations, <audio> and <video> tags, webWorkers,
    > geoLocation, and whatever else these 4 pretty-good browsers provide
    > me, asap, and 100% regardless of M$ its IEs and their "peculiarities",
    > to say it so. That's my taste and I do software design.


    BTW, Out of curiosity I've just checked the (full of expandos) web app
    I'm currently working on in a Navigator 7.2 (Gecko/20040804) (*) and
    it works flawlessly, expandos and all. just had to
    define .forEach,.indexOf, atob and btoa... :)

    (*)Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2)
    Gecko/20040804 Netscape/7.2
    --
    Jorge.
     
    Jorge, Sep 28, 2009
    #12
  13. yawnmoth

    David Mark Guest

    On Sep 27, 9:40 pm, Jorge <> wrote:
    > On Sep 28, 3:11 am, Jorge <> wrote:
    >
    >
    >
    > > On Sep 28, 1:13 am, David Mark <> wrote:

    >
    > > > On Sep 27, 7:07 am, Jorge <> wrote:

    >
    > > > > On Sep 27, 12:11 pm, Martin Honnen <> wrote:

    >
    > > > > > (...)
    > > > > > On the other hand setting previously undefined properties on host
    > > > > > objects is not required to work.

    >
    > > > > Might not be required "by the spec", but de-facto it's a requisite,at
    > > > > least for DOM Node(s), istm.

    >
    > > > ISTM, you have jumped to a wild conclusion.  DOM node expando
    > > > properties are neither required nor advisable.  Not only do some
    > > > browsers (and configurations) throw exceptions, they are also a good
    > > > way to create memory leaks (e.g. augmenting event objects).

    >
    > > > You've got enough to worry about.  Don't design things that rely on
    > > > big if's like expando properties, ActiveX, deferred scripts, MS
    > > > hotfixes, etc.  Or you can go all-out in the opposite direction and
    > > > use something like jQuery, which gleefully exploits any fleeting bug/
    > > > feature/happenstance until it seems to stop working (then a rewrite
    > > > appears claiming to fix those buggy browsers once and for all).  It's
    > > > programming for failure for all involved.  The only (technical) people
    > > > who can't see that are those who see failure as the only option (e.g.
    > > > ten years later, these browsers are just too darn buggy).

    >
    > > > Like it or not, software design is not a matter of taste.  The results
    > > > of poor designs are not "good enough" and all it takes is a quick spin
    > > > around the Web (in any browser) to see this is the case.

    >
    > > Yeah, in the real life there are 4 pretty good browsers and crap like
    > > [the whole set of IEs], nearly 50-50. I live in the real life and I
    > > program just for the 4 pretty good ones. It's a luxury that was not
    > > possible just 3 years ago. I'll keep using expandos, the <canvas>,
    > > gestures, css animations, <audio> and <video> tags, webWorkers,
    > > geoLocation, and whatever else these 4 pretty-good browsers provide
    > > me, asap, and 100% regardless of M$ its IEs and their "peculiarities",
    > > to say it so. That's my taste and I do software design.

    >
    > BTW, Out of curiosity I've just checked the (full of expandos) web app


    I imagine it is full of lots of things. :)

    > I'm currently working on in a Navigator 7.2 (Gecko/20040804) (*) and
    > it works flawlessly, expandos and all. just had to
    > define .forEach,.indexOf, atob and btoa... :)


    So you decided to expand to five browsers, adding an old one that
    virtually nobody uses (as opposed to say IE). And it didn't work. So
    you added code until it worked in that browser. Is this your idea of
    cross-browser scripting? Why don't you just use jQuery and get it
    over with?

    >
    > (*)Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2)
    > Gecko/20040804 Netscape/7.2


    I have a bad feeling about this app, Jorge.
     
    David Mark, Sep 28, 2009
    #13
  14. yawnmoth

    Jorge Guest

    On Sep 28, 3:37 am, David Mark <> wrote:
    >
    > So you deliberately exclude IE users, as well as people who disabled
    > scripting.


    Yes. Simply, yes. I do. And I do it deliberately. My target does not
    include IE users, so what ? They can always launch their fiereFoxes,
    or their Operas or their Chromes or Safaris. In fact, I'd like to push
    them to take that step. If for any reason they can't switch, I'm
    sorry, OTOH for years most non-IE users have had a lesser web
    experience, anyways. As for the switched-off JavaScript, times are
    changin'. What's coming next in the web can't/won't be possible
    without JavaScript, you should know, you'll see it's a must in the
    very near future, just like the air we breathe.

    --
    Jorge.
     
    Jorge, Sep 28, 2009
    #14
  15. yawnmoth

    Jorge Guest

    On Sep 28, 3:54 am, David Mark <> wrote:
    >
    > I have a bad feeling about this app, Jorge.


    Works even in Safari 1.3.2... (sort of :)

    --
    Jorge.
     
    Jorge, Sep 28, 2009
    #15
  16. yawnmoth

    Jorge Guest

    On Sep 28, 3:54 am, David Mark <> wrote:
    >
    > I imagine it is full of lots of things.  :)
    >


    It is. It's got animated gauges drawn in <canvas>(es), it's got
    gestures (for the iPhone), it's got 2d -webkit-transform CSS
    animations, and a translate3d one. All the fallbacks have kicked in
    flawlessly in a 5 years old browser... Still, IEs are *not supported*.
    I'm so sorry.

    --
    Jorge.
     
    Jorge, Sep 28, 2009
    #16
  17. yawnmoth

    JR Guest

    On Sep 27, 11:37 pm, Jorge <> wrote:
    > On Sep 28, 3:37 am, David Mark <> wrote:
    >
    >
    >
    > > So you deliberately exclude IE users, as well as people who disabled
    > > scripting.

    >
    > Yes. Simply, yes. I do. And I do it deliberately. My target does not
    > include IE users, so what ? They can always launch their fiereFoxes,
    > or their Operas or their Chromes or Safaris. In fact, I'd like to push
    > them to take that step. If for any reason they can't switch, I'm
    > sorry, OTOH for years most non-IE users have had a lesser web
    > experience, anyways. As for the switched-off JavaScript, times are
    > changin'. What's coming next in the web can't/won't be possible
    > without JavaScript, you should know, you'll see it's a must in the
    > very near future, just like the air we breathe.
    >
    > --
    > Jorge.


    I've noticed that some people in cljs don't seem to understand (or
    don't like to assume) that there are huge corporate intranets out
    there in which IE is not a requirement for the everyday job. I
    personally don't agree with that behaviour (excluding IE), but it's a
    reality in many places. In addition, many government intranets still
    use 'Oracle Forms' for instance and front-end apps designed for old
    versions of Netscape / Mozilla browsers and a few apps for IE 6 / 7,
    where the users don't have the option to disable Javascript simply
    because they could not get their job done... Therefore, I think this
    discussion would last forever because there is space for many types of
    developers in the market...

    Cheers,
    JR
     
    JR, Sep 28, 2009
    #17
  18. yawnmoth

    David Mark Guest

    On Sep 27, 11:00 pm, Jorge <> wrote:
    > On Sep 28, 3:54 am, David Mark <> wrote:
    >
    >
    >
    > > I imagine it is full of lots of things.  :)

    >
    > It is. It's got animated gauges drawn in <canvas>(es),


    Oh good (unless you are an IE user).

    > it's got gestures (for the iPhone),


    You mean the iPhone has gesture events and you are stepping on them.
    Probably not good.

    > it's got 2d -webkit-transform CSS
    > animations, and a translate3d one.


    Cool! I animated a width the other day.

    > All the fallbacks have kicked in


    I'd like to see your fallback for Webkit transformations.

    > flawlessly in a 5 years old browser...


    LOL. No they didn't. And what if they did?

    > Still, IEs are *not supported*.


    Nothing at all?

    > I'm so sorry.


    We've established that. :)
     
    David Mark, Sep 28, 2009
    #18
  19. yawnmoth

    SAM Guest

    Le 9/28/09 3:37 AM, David Mark a écrit :
    >
    > You've described some pretty bad design decisions that alienate IE


    Perhaps do we code for Mac users ?
    As it was a time where going on M$ knowledge base was impossible (most
    of things unreadable) with a Mac (with a browser !IE) and not helping to
    find "good" decisions/design anyway.

    Nobody forbids to have and use several browsers such as IE and a
    "standard" compliant one (except on Mac where M$ do no more support IE)

    --
    sm
     
    SAM, Sep 28, 2009
    #19
    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. asd
    Replies:
    3
    Views:
    440
    Arnaud Berger
    May 23, 2005
  2. gavnosis
    Replies:
    0
    Views:
    523
    gavnosis
    Aug 2, 2003
  3. Timo Nentwig

    selecting nodes between other nodes

    Timo Nentwig, Jun 16, 2004, in forum: XML
    Replies:
    1
    Views:
    408
    Patrick TJ McPhee
    Jun 17, 2004
  4. Replies:
    7
    Views:
    3,222
    James Kanze
    Feb 12, 2008
  5. Alan
    Replies:
    6
    Views:
    1,603
Loading...

Share This Page