I should have mentioned that unless you're okay with things wigging out after 2.1 billion clicks (and it would be perfectly reasonable to be okay with that), you will want to do that readjustment. If you try this copy (http://jsbin.com/uzokad/2) which starts just a few numbers shy of the limit, the results vary from browser to browser as to what happens when the value exceeds a signed 32-bit int -- they differ, but are nearly-universally undesirable. (Chrome just happily keeps going; I guess they either use a JavaScript number [a 64-bit format IEEE 754 floating-point value -- this is my suspicion] or a 64-bit int.) But IE, Firefox, and Opera all became unhappy in varying ways.
-- T.J. :-) On Jul 4, 10:41 pm, "T.J. Crowder" <[email protected]> wrote: > Hi, > > I was playing with something a couple of years back that was going to > have a bunch of little boxes, any of which needed to be brought in > front of the others on click. I played with keeping track of the most- > recently-brought-forward box and then lowering its z-index again when > another one was brought forward -- basically, having a background > (statically-positioned content), a mid-ground (absolutely positioned > content with z-index of one value), and foreground (absolutely- > positioned content with a slightly higher z-index). But it didn't work > well, not least because there was no "history" to it -- I'd drag a box > over somewhere, then start dragging another and the box I'd dropped > previously would (of course) go underneath other boxes depending on > which boxes came first in the document order. > > I got distracted and never finished fiddling with that (it was just > something I was playing with), but your question reminded me of the > awkwardness and as I know a good deal more now about JavaScript and > CSS than I did then, my first thought was: How 'bout an ever- > increasing value? > > Browsers seem to store z-index in 32-bit signed integers, meaning that > the range in front of the statically-positioned content is 0 to > 2,147,483,647 (more than 2.1 billion). So in my lots of small boxes > situation, I could probably have just had a variable, `nextZIndex`, > seeded it with the value 1, and then each time one of my boxes was > clicked and needed to be brought in front of the others, I'd just > assign that next z-index to it and increment `nextZIndex`. The boxes > will maintain themselves in most-recently-clicked order...for 2.1 > billion clicks, which I think is a reasonable limit. :-) Here's a live > copy of the sort of thing:http://jsbin.com/uzokad > > It feels a bit...open-ended, but has the advantage of being > wonderfully simple. And you could always put in a check for when you > find your `nextZIndex` value is at about 2,147,483,000 or so and do > the "expensive" (not really at that point, in the scheme of things) > operation of redoing the numbering on all of your relevant elements. > > FWIW, > -- > T.J. Crowder > Independent Software Engineer > tj / crowder software / com > www / crowder software / com > > On Jul 4, 4:27 pm, kstubs <[email protected]> wrote: > > > > > > > > > Those are some good ideas. In an effort to just write something quickly I > > decided to: > > > 1) keep track of context object z-index > > 2) set z-index of this object to some absurd big z-index value > > 3) on lost focus (or when the object should resume the "not" expanded state) > > return z-index to original size > > > This seems to be working fine.. > > I was fishing for if anyone else had ran into similar implementation > > problems. You know its fantastic to finally be able to write all of this > > great Javascript code using Prototype, but you still have to write it > > intelligently. -- You received this message because you are subscribed to the Google Groups "Prototype & script.aculo.us" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en.
