Yeah, the clean-up has to happen onmousedown, rather than onEnd as I
said previosuly.  I did some more testing and found I still needed to
catch the onEnd event to clean-up after unusual cases such as when the
element is dragged off screen in IE...

In the end I added a boolean flag to test if the element was being
dragged, set on mousedown and unset on mouseup so that conversion only
happens at each end of the drag.  Without this test I found (in IE
particularly) that elements could suddenly disappear off screen if the
px hadn't been committed back to % from the previous attempt...

So in summary, in each class containing a single draggable element
(this.element) I ended up with this:

init code:

/* member variables, left and top are % */
this.left   = 0;    = 0;
this.dragging = false;

/* Make it draggable and attach its useful events to this object */
this.draggable = new Draggable(this.element, {
    onEnd: this.onDragEnd.bindAsEventListener(this),
/* convert percent to px for position before drag starts */
Event.observe(this.element, 'mousedown', this.onMouseDown);
/* and convert px to percent for position after drag completes */
Event.observe(this.element, 'mouseup', this.onMouseUp);

2 conversion methods:

/* toPixelPosition
 * convert this.left/ to px,
 * check within bounds and setStyle of this.element */
toPixelPosition: function() {

/* toPercentPosition
 * convert left/top properties to %,
 * check within bounds and store in this.left/ */
toPercentPosition: function() {},

3 event listeners:

onMouseDown: function(event) {
    // get var me from event

    if (!me.dragging) {
      me.dragging = true;

onMouseUp: function(event) {
    // get var me from event

    if (me.dragging) {
    me.dragging = false;

onDragEnd: function() {
    if (this.dragging) {
        // mousedown event not fired (dragged off window)
    this.dragging = false;

Hope I haven't cut out too much extraneous code and you can still
follow the flow!

If the scriptaculous codebase allowed % coordinates it would be better
obviously.  I had a look in the but decided that there would be
changes needed in multiple locations and that this less elegant method
would be easier to maintain in the short term.  I doubt that support
for effects on elements using percentage based layouts is high on most
developers' priority list!

I'm afraid I'm new to the scriptaculous scene so I'm not sure what the
process is regarding bug reports.


On Mar 28, 11:17 pm, Jay <> 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 &" 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