storing temporary variables in dom nodes

[yawnmoth]

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.

 

[JR]

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

 

[Jorge]

(...)
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,

 

[JR]

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

 

[Martin Honnen]

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.

 

[Jorge]

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]

(...)
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.

 

[Dmitry A. Soshnikov]

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.

 

[David Mark]

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.

 

[Jorge]

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.

 

[David Mark]

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.

 

[Jorge]

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

 

[David Mark]

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.

 

[Jorge]

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 have a bad feeling about this app, Jorge.

Works even in Safari 1.3.2... (sort of

 

[Jorge]

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.

 

[JR]

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.

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

 

[David Mark]

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.

 

[SAM]

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)