I meant to add that the method detailed above starts and ends with the
elements in % layout (even if element is clicked but not dragged), so
resizing the window is handled as expected by the CSS declarations.
There's no need for a window resize event listener.


> On Mar 28, 11:17 pm, Jay <j...@demosphere.com> wrote:
> > 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.
> > Thanks,
> > --Jay
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 prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to