__defineSetter__ in Mozilla
If I override a property in Moz with __defineSetter__, can I get at
the original property inside my setter function? Say I wanted to add
something to a page so that every time someone tried to set
anyelement.style.display, it alerted “hello” and then set the value
they specified. I could do
function setterfn(newstyle) {
alert('hello');
this.display = newstyle;
}
CSSStyleDeclaration.prototype.__defineSetter('display',setterfn);Of course, that won’t work, because “this.display” in setterfn calls
the setterfn, because it’s trying to set “display” on a style object!
Infinite loop.
I’m quite happy to do this another way, if setters aren’t the
approach. Just don’t suggest Object.watch(), because it’s totally and
utterly unreliable on DOM objects and doesn’t fire half the time. The
solution can be (and I am expecting it to be) Moz only, but it has to
be a proper released version of Moz and not Deer Park.
I’ve been trying to do this for two days and it’s doing my head in. :-)
(originally a mail for a couple of people, but it occurred to me that I have a weblog for this sort of thing)
What about calling this.setProperty(”display”, newstyle, “”)?
2 hours later
Dylan: nice one! That works. DIdn’t even *know* about setProperty().
8 hours later
Hm. New problem, then; what I actually want to do, in cssdisplay(), is get the computed style of the element. However, I don’t *have* the element; “this” in cssdisplay() is the style declaration. Any suggestions for how I can get the element, or how I can pre-prep all elements (including dynamically created ones) so that I can get a reference to an element from its CSSStylrDeclaration object?
8 hours later
What I can do is, in cssdisplay, walk through all the elements on the page and say
if (thiselement.style === this) { // do something with thiselement }
which works, and should be fine as long as the page isn’t *too* massive, which it won’t be for this project.
11 hours later
One question - WHY ?
Why on earth would you ever want to do this - bored maybe ? Too much time on your hands ?
:-)
11 hours later
OCB: for a mighty cool project, which I shall be revealing as soon as I get it working :)
17 hours later
[...] There are times when this weblog is silent because I’m not up to much. There are also times when it’s silent because I’m up to too much and don’t have time to post. This most recent silence has been the latter sort, although a couple of nuggets (like the thing about mousewheel scrolling and the thing about defineSetters came out of my current work. Still not ready to reveal it, but I do have one other thing to say: I’m going to SxSW 2006! Yes indeed. I shall be there in Austin. I got well sick last year of everyone going on about it, and Simon ragged on me for thinking about not going, pointing out that it is great and fantastic and now he works at Yahoo, and I examined his argument and found it compelling. We’ll ignore, for the moment, all the 64oz steaks for $0.99 that you get in Texas, although I shall not be ignoring them when I get there, no sirree. Bring me another. And another plate of chips, too. Oh yes. Anyway, I’m really looking forward to it. It’s going to be cool. I’m also speaking at a couple of upcoming conferences; details when they go public. Blimey — jetting off to other countries, speaking at conferences…I’m turning into Jono. Heh. [...]
3 weeks later
The problem with looking up the element that owns the style property is basically a shortcoming of JavaScript/ECMAScript, I’ve been there many times and still don’t know how to do it. Would be nice with a generic obj.__parent__ or something. (The problem is much worse with getters and setters BTW, in other contexts you are much likely to have the information in a variable anyway.)
The only real solution I know so far is to use closures where you define the setters/getters but this naturally sucks because you can not use prototype.__define[GS]etter__ to that extent. Maybe ES4 comes to the rescue?
121 weeks later