#1883 closed bug (wontfix)

Opened November 02, 2007 05:18AM UTC

Closed November 05, 2007 03:20PM UTC

Last modified May 24, 2008 03:39AM UTC

slider() cannot be applied to JQuery objects that are not yet in DOM

Reported by: nostrademons Owned by:
Priority: minor Milestone:
Component: ui.core Version: 1.2.1
Keywords: Cc:
Blocked by: Blocking:
Description

The following test case fails with an obscure JQuery error message ("elem.style has no properties" on jquery.js:698):

<div id = "placeholder"></div>
<script type = "text/javascript">
$(document).ready(function() {
$('<div class = "ui-slider-1">' + 
      '<div class = "ui-slider-handle"></div>' + 
  '</div>').slider().appendTo('#placeholder');
});
</script>

This attempts to create a new JQuery object from HTML, turn it into a slider, and then add it to the DOM. If I reverse the order of those calls, appending it into the DOM first and then turning it into a slider, it works fine:

<div id = "placeholder"></div>
<script type = "text/javascript">
$(document).ready(function() {
$('<div class = "ui-slider-1">' + 
      '<div class = "ui-slider-handle"></div>' + 
  '</div>').appendTo('#placeholder').slider();
});
</script>

I'm not sure if you need to support this, since the workaround is simple. But if not, it should be clearly documented on the Slider's documentation page. It took me a while to track down because the error message is so inscrutable...

Attachments (0)
Change History (4)

Changed November 02, 2007 02:52PM UTC by nostrademons comment:1

One other annoyance about this bug: it makes it difficult to create libraries that compose JQuery widgets into components that can be spliced into the page. Instead of returning a whole DOM fragment that can be appended anywhere, they need to take the selector of the parent and ensure that the component is added into the DOM before slider() is called. And this restriction bubbles down into clients of *that* component, which need to ensure that the parent object they pass in is already part of the DOM. This could have large ripple effects on a project's architecture.

Changed November 03, 2007 04:41AM UTC by nostrademons comment:2

I've got a patch for this. It pulls into a function all the initialization code that is dependent upon Dimensions or DOM properties, and then reinvokes that function when a drag begins. So if the element was not part of the DOM at creation (and hence never had its parentSize/axis initialized), it will pick it up on the first mouse action. It also deletes one call to offset() whose result is never being used.

As a nice (untested) side-effect, this should allow you to resize slider containers between actions without throwing off the slider calculations.

It still does not let you specify a startVal for a slider that's not part of the DOM - there's no way it could, really, since it has no dimensions to calculate a position and there's no event to hook code into between initialization and visibility. If my patch for bug #1737 is accepted, a workaround might be to call sliderMoveTo once the slider has been added to the DOM.

It also has problems with vertical sliders, but those existed in the original version, and so should be considered a separate bug.

Changed November 05, 2007 03:20PM UTC by paul comment:3

resolution: → wontfix
status: new → closed

Hi, I don't think there is a good way of solving this issue, and I don't think it's worth the trouble, since most things won't work without being in the DOM (this is something the user should be aware of, not the script). Anyway, thanks a lot for your time!

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

milestone: 1.2.2

Milestone 1.2.2 deleted