Several years ago, I griped (unsuccessfully) about the need for a scrollable content object model. I remember someone mentioning on planet.mozilla.org that this would not be a problem going forward, but I couldn’t find the entry. So today, I was exploring another user-interface concept, and it led me back again to scrollable content. (As you read this, my context is the XULRunner 1.9.0.x code base.)
Ahh, I remember the frustrations well. It took me several hours (and a few blind alleys), but I actually hit on a really simple way to tell where a XUL box with scrollbars has scrolled to. Though the XUL box itself has to use my particular XBL binding and CSS styling, it’s still a nice starting point.
Here’s the binding, stylesheet, and a demonstration all in one. Note that it’s a lot cleaner than my previous attempt, and it works.
I realize the scrollX
and scrollY
properties are read-only. I don’t see a way around that for this approach. If you really want it, you’ll probably have to implement a native-code, C++-based component.
Or, you could wait for Firefox 3.1 / XULRunner 1.9.1, which now has scrollLeft and scrollTop for all DOM elements – and it’s settable there, too. (This makes the third big improvement I’m looking for in XR 1.9.1 that isn’t in 1.9.0.x, which means it’s time to seriously think about moving forward… The other two are new drag and drop features, and a DOM Range fix I pulled in from very early in the 1.9.1 cycle.)
Note I groaned very audibly when I was writing this article and decided to check what 1.9.1 has. Talk about a feeling of a wasted day!
It’s 5am, and I can’t think straight – and I can’t tell the difference between what you have and a (with QIing its .boxObject to a nsIScrollBoxObject). Unless you’re doing remote XUL, of course; if that’s the case it sounds more like it needs some nsIClassInfo magic.
(From Alex: I was never, never able to make a work.)