Skip to main content

Search and Top Navigation

#2421 open feature ()

Opened February 27, 2008 02:41AM UTC

Last modified December 29, 2013 01:06PM UTC

Resizable breaks with %-based positioning but works with pixel-based positioning

Reported by: briang Owned by:
Priority: minor Milestone: 2.0.0
Component: ui.resizable Version: 1.5b4
Keywords: resizable haspatch Cc:
Blocked by: Blocking:
Description

I am using resizables to display an object in a Gantt-chart like setup where each resizable object represents some subset of the overall range available. If you consider horizontal sizing only, the left and right edges of the parent are the min and max values and the resizable can represent any subset of that range by dragging the edges.

Initially I attempted to position the left/width of the resizable object using percentages like so:

<div class="package" id="pkg1" style="margin: 5px; padding: 20px; background-color: #eee; left: 15%; width: 40%;">
  <div style="float: left; background-color: #ccc; width: 20%;">Package #1</div>
  <div style="float: left; background-color: #f00; width: 80px;">$250.00</a></div>
</div>

The associated resizable call was:

$(".package").resizable({ handles: 'w, e', autohide: true, minWidth: 10, containment: 'parent'});

This results in bizarre behavior where the resizable is displayed properly at first. However, upon trying to drag either handle results in the left handle snapping back to the left edge of the parent. After that, it behaves properly.

If instead you use pixels:

<div class="package" id="pkg1" style="margin: 5px; padding: 20px; background-color: #eee; left: 167px; width: 236px;">
  <div style="float: left; background-color: #ccc; width: 20%;">Package #1</div>
  <div style="float: left; background-color: #f00; width: 80px;">$250.00</a></div>
</div>

It works as expected including the initial drag. It appears the percentage is miscalculated when the widget is instantiated.

Percentage-based support would be valuable in order to support fluid layouts.

I've confirmed this in both FF 2 and IE 6 on Windows XP.

Attachments (0)
Change History (13)

Changed February 27, 2008 12:52PM UTC by paul comment:1

owner: paulbraeker

Changed May 04, 2008 09:10AM UTC by paul comment:2

priority: majorminor

Changed May 05, 2008 08:56AM UTC by paul comment:3

type: bugenhancement

This is a enhancement, not really a a bug.

Changed May 24, 2008 03:39AM UTC by comment:4

milestone: 1.2.4

Milestone 1.2.4 deleted

Changed May 24, 2008 07:26PM UTC by paul comment:5

component: ui.coreui.resizable
version: 1.2.31.5b4

Changed August 17, 2008 09:19AM UTC by Cloudream comment:6

milestone: → TDB

Changed February 17, 2009 12:30PM UTC by jzaefferer comment:7

milestone: TBD1.6
owner: eduardo
status: newassigned

Changed March 08, 2009 02:33PM UTC by rdworth comment:8

milestone: 1.71.8

Changed December 02, 2010 10:02AM UTC by ra comment:9

Problem: Currently % based location is overwritten with px based position ('top:20%;' -> 'top:20px'). As a result resizable item will jump.

Fix: Very easy fix - % based position needs to be kept unchanged. Does not interfere with current px based positioning. Works great with % based positioning. My fix needs just a bit more optimizing - to use only single css() instead of four css() calls.

NEW CODE:

//keep % location unchanged
if(el[0].style.top.slice(-1)!="%"){
    el.css("top",this.position.top+"px");
}
if(el[0].style.left.slice(-1)!="%"){
    el.css("left",this.position.left+"px");
}
if(el[0].style.right.slice(-1)!="%"){
    el.css("width",this.size.width+"px");
}
if(el[0].style.bottom.slice(-1)!="%"){
    el.css("height",this.size.height+"px");
}

OLD CODE:

el.css({
    top: this.position.top + "px", left: this.position.left + "px",
    width: this.size.width + "px", height: this.size.height + "px"
});

Changed June 26, 2012 01:22AM UTC by scottgonzalez comment:10

type: enhancementfeature

Changed October 11, 2012 02:52PM UTC by scottgonzalez comment:11

milestone: 1.9.02.0.0

Changed October 19, 2012 06:00PM UTC by mikesherov comment:12

keywords: resizableresizable haspatch
status: assignedopen

Changed December 29, 2013 01:06PM UTC by tj.vantoll comment:13

#9722 is a duplicate of this ticket.