Opened 13 years ago

Closed 13 years ago

#8959 closed defect (fixed)

keeping zindex value from original element in the pieces createed for dojox.fx.split anims

Reported by: Kenny Owned by: nic
Priority: high Milestone: 1.4
Component: Dojox Version: 1.3.0b3
Keywords: zindex fx anims Cc:
Blocked By: Blocking:


The different animations in dojox.fx.split (converge, explode, shear,..) don't take into acocunt the z-index property of the original element.

So, when playing with several div across each other, every time you play an anim, the anim goes behind all the other divs.

I tried style:"z-index:999;", when instanciating the anim (I tried also style:"zIndex:999;",), but it didn't change anything.


Attachments (3)

drawerContainer.7z (30.1 KB) - added by Kenny 13 years ago.
test_split_zIndex.html (1.7 KB) - added by nic 13 years ago.
test case
split.js.diff (1.6 KB) - added by nic 13 years ago.

Download all attachments as: .zip

Change History (14)

comment:1 Changed 13 years ago by Kenny

I finally succeeded to manip the css properties of the pieces.

I noticed that the anims create x divs with the same id as the original element.

I added this:

onPlay:function() {
        dojo.query("div > #" (node) {
      , "zIndex", myNewZindex);

But maybe it's a good idea to automatically integrate the z-index of the original element.


comment:2 Changed 13 years ago by Adam Peller

Owner: changed from Adam Peller to dante

comment:3 Changed 13 years ago by dante

Milestone: tbdfuture
Status: newassigned

hmmm if it's making them all with the same id that would be a problem anyway. can you provide a small testcase illustrating the z-index breaking something?

comment:4 Changed 13 years ago by Kenny

Yes. That's what I thought (about the multi ids). And more, this trick doesn't work on IE7 (but work with Opera, Safari and FF).

I'm going to show you a good example soon, but I need more time now to finish my widget that play with fully with z-index and dojox.fx.split anims.

Give me few times and I'll provide a testcase.


comment:5 Changed 13 years ago by Kenny

Ho. Sorry.

I forgot to mention that the problem comes from all the divs created for the anim (that contain themselves the divs with the same id as the original one) have no way to be catch with a dojo.query or something else. They have no id. Just styles that change from one anim to another. So impossible to track.
(And that's why I had to do a node.parentNode on my result)

Maybe, if possible, it would be a good idea to englobe all the pieces created for the anim in a div with an idea that is easy to find.
Or give a specific attribute to the divs.

Then, it'll become easy to manipulate properties of the divs.

I must say that I quite like those anims. Sometimes I'm really surprised with the visual when trying new parmaeters.
And you have so many possibilities thanks to them.

Nice work.

The 2 things about the anims I keep an eye on are:

  • not give a too high number for params that determine the number of divs created for the anim (like rows and columns). If not, it becomes quite quick heavy, especially when you have complex widgets to duplicate,
  • also I didn't yet understand why, but it seems that the anims have strange visuals side effects when the widget to animate is too near others stuffs. You'll see that with my testcase.


comment:6 Changed 13 years ago by Kenny

Ok.. Here it is.

My new widget.
To test it, you just have to give the right path for dojo and mywidgets at the beginning of index file, but I guess you know that.

I take advantage of this post to ask you if you could take 2 min to check the widget and tell me what you think about it.

I wanted something like that for my application, and as I was learning Dojo, I decided to make a widget from that idea.
It's not much but I'm quite happy with the result.
You have lots of possibilities, lots of params to play with.
I tried to keep in mind the max liberty for people to use it.

I wanted a container / controller principle, but not attached one to the other, like in the stackContainer / stackController widget and all their subWidgets (tabContainer, ..).

So, I started from the stackContainer to redraw the idea. That's why my drawerController looks a lot like the stackController. The same for the Button.
But my container should only play with their children to show or hide them but not englobe them.

Now, it's working quite good in nearly all main browsers (FF, IE6, IE7, Opera, Safari).

I already think of lots of thinks to make it better or new ideas, new possibilities to offer it, but I would like to have an opinion before going on.

Anyway, if you are interested by it, or if you think it can fit in the dojo framework, feel free to do it. I'll be glad.

Now, concerning the problems I've noticed:

  • with FF: the anims from dojox.fx.split have strange visual effects. But as it's the only one to have these problems, maybe it comes from FF itself.
  • with Opera: works really well (anims and z-index)
  • with safari 4: works really well except, I don't know why, the buttons from right / top or bottom drawers can be seen in wrong position, but not all the times.
  • with IE7 and IE6: works quite good. The problem is that my hack with the z-index doesn't work. I tested and it seems that I set correctly the attr, but it doesn't change on screen.
  • with Chrome: catastrophic. Lots of small problems. Only top drawers positions can be used. Damned, Chrome seems to have lots of problems with Dojo. With my main application, it's the same. I know it's a young browser, but ..

Hope You'll enjoy it.

Thanks for your time.


Changed 13 years ago by Kenny

Attachment: drawerContainer.7z added

Changed 13 years ago by nic

Attachment: test_split_zIndex.html added

test case

Changed 13 years ago by nic

Attachment: split.js.diff added

comment:7 Changed 13 years ago by nic

Added a simple test page and a patch: a fix and few optimizations

comment:8 Changed 13 years ago by Kenny

Hey Nic,

Excellent.. Thanks.

A question: <script> pTop = y * pieceHeight, pLeft = x * pieceWidth </script>

Did you put those because with certain elements, the created divs are badly placed? Like if you play an anim on a calendar widget, it appears always on top left of the screen.. (you can see it if you change the anim to a anim from fx.split to the calendar).

comment:9 Changed 13 years ago by Kenny

That fix seems perfect..

I removed my hack (the onPlay function for the anims) I modified the split.js file..

I tested the new version in FF, IE6, IE7 and Opera and the ZIndex problem is no more.. Great.

Thanks a lot Nic.

Now, the last strange thing I have with my widget is the ugly split effects in FF. Even IE6 looks much more nice than FF (Yeah.. I know it sounds incredible.. but it's true).
FF is the only one to have these visual problems when playing split anims.

The other point, is that if you play a split anim (fade in/out works correctly) on certain widget (ie the calendar), the anim won't work. You just see the calendar that appears at the end of the anim.
In FF (and only in FF), you can see that the created divs for the calendar are always on top left of the screen and not where the initial div is.

To see that, you can put an split anim on the calendar that is on the righ-top drawerContainer.
Or you can add this to any other drawerContainer that already has an split anim configured:

dijit.byId("xxx").addChild(new dijit._Calendar ({title:"Calendar"}));

Nic & Peter, thanks for your help.


comment:10 Changed 13 years ago by dante

Milestone: future1.4
Owner: changed from dante to nic
Status: assignednew

... makes sense for this to be your first checkin :P

comment:11 Changed 13 years ago by nic

Resolution: fixed
Status: newclosed

(In [17331]) fixes #8959 - the cloned node now has the right z-index and no id

Note: See TracTickets for help on using tickets.