That's a pretty good workaround I guess. I had a little confusion
implementing it because I used a "handle" for the draggable, but
"observe"d the click on the draggable element, which had the left
style, so I got pretty confused for a while. These sorts of events are
challenging to debug even in Firebug due to their nature. Another
problem is if it is clicked, but never actually dragged, I will have
changed the style from % to px units, and never have a chance to go
back (if using the onEnd to clean up), so later resizings still don't
have the benefit of percentage styling.

I've searched for the line of code that is assuming px units instead
of respecting the % specification, but couldn't tell if it was in
Position.cumulativeOffset or where exactly. It might be in
Position.relativize or Elements.Methods.relativize. I still consider
this a bug, to just go off and parse the number without respecting the
units. Is there a way to log a bug?

Do you know if there is an event to watch for window resizing, where I
might be able to clean up any clicked-but-un-dragged px conversions
before things get mis-shapen? Percentage styles are too good a
technique to have to avoid when using draggables/sortables.


On Mar 27, 7:50 am, Conchur <> wrote:
> I've just come up against the same issue, making percentage-based
> positioned elements draggable without flickering.
> The scriptaculous startDrag function doesn't notify the draggable
> element of the onStart method until after the left/right co-ordinates
> have been initialised, so there's no opportunity to convert them using
> the built-in notifications.  It seems that any left/right values are
> silently assumed to be 'px' (i.e. '%' is ignored) and so the element
> flickers to 50px (instead of 50%) when the mousedown event is first
> trapped.
> The fix I've made listens for the mousedown event on the element, and
> converts the % to px (using the container ratio code you've already
> quoted).  You also need to listen for the onEnd event of the drag
> action, and do another conversion back to % from the new px position
> using the inverse ratio.
> HTH,
> C.
> On Mar 23, 3:06 pm, Jay <> wrote:
> > Hi,
> > Just noticed that if a draggable element uses a percentage in the
> > style for 'left', a couple things don't seem to work right.
> > <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" 
> > "";>
> > <html>
> > <head>
> > <script src="
> > prototype.js" language="JavaScript" type="text/javascript"></script>
> > <script src="
> > scriptaculous.js" language="JavaScript" type="text/javascript"></
> > script>
> > </head>
> > <body>
> >         <div id="d1" style="height:200px; width:300px; border:1px solid
> > green; position:relative;">
> >                 <div id="d2" style="position:absolute; top:20px; left:20px; 
> > height:
> > 20px; width:80px; border:1px solid gray;">
> >                         ABC 123
> >                 </div>
> >         </div>
> >         <script type="text/javascript">
> >                 new Draggable('d2',{revert:true});
> >         </script>
> > </body>
> > </html>
> > Notice the 'left:20px' style - this setting works ok. But if you try
> > it with 'left:20%' two odd things happen. The first is very quick in
> > this example and hard to see (but shows up more in my production
> > version) - at the start of the drag, there is a quick flash or wiggle
> > to left=0 then back again. This does not happen with a 'px' setting
> > only with a '%' setting. The second is the x,y location where it
> > reverts to - it always goes back to the numeric quantity in pixel
> > units, not the amount as a percentage. Wouldn't this be a bug?
> > I like to use percentage because my container element changes in size
> > if the browser window is resized or more options are chosen, etc. For
> > now however, I'm doing something like this:
> >     var wid=$('container').getWidth();
> >     var gleft=Math.round(wid*0.04); // left:4%
> >     gdiv.setStyle({position:'absolute', top:gtop+'px', left:gleft
> > +'px', width:'92%'});
> > With that it doesn't flash, and stays lined up as the drag and drop
> > operates, but of course it isn't reacting to dynamic changes in
> > container size as it would with a percentage.
> > Thanks,
> > --Jay
You received this message because you are subscribed to the Google Groups 
"Prototype &" group.
To post to this group, send email to
To unsubscribe from this group, send email to
For more options, visit this group at

Reply via email to