Dialog Helper Option Removal

[Scott González]

Dialog currently has options for dragHelper and resizeHelper.  Both are undocumented and seem unnecessary.  For resizeHelper, we can just create a specific class name to add like ui-dialog-resizing.  For dragHelper, I can't really see a good use case for this, so I'm proposing we drop it.

[Scott González]

I should probably add that I checked Trac to see why/when these were
added and there's no detail in the commit messages and no related
tickets.

[Richard D. Worth]

+1

- Richard

[Paul Bakaus]

+1

--
Paul Bakaus
UI Architect
--
http://paulbakaus.com
http://www.linkedin.com/in/paulbakaus

[Eduardo Lundgren]

Hi Guys,

dragHelper is useful when we need to create for example a empty div that is the helper for the dialog.

Imagine if you have a very big dialog with thousands of children, whether you drag this dialog will be very slow, although using the dragHelper option the user can create a empty div (representing the dialog) to be the helper, this helper will be insanely faster to drag than the original dialog.

We really need this option in my opinion, what do you think?

- Eduardo Lundgren

--
Eduardo Lundgren
Software Engineer
Liferay, Inc.
Enterprise. Open Source. For Life.

[Richard D. Worth]

I'm not convinced that's a common enough case to justify it. If the dialog has too much in it to be dragged around, maybe it shouldn't be draggable? Or maybe hide the contents of the dialog (efficiently, using css) during dragging. Or if you really did want that much content to be draggable, but with a dragHelper, use the draggable plugin.

If you want a dialog, it means you're looking for a titlebar, a close button, maybe some buttons at the bottom. These are varied, flexible, and extremely common. Could be as complex as an entire form. But thousands of children? I wouldn't consider that a common use case of dialog. Or as I said, not a draggable dialog, if having that many elements causes an issue with dragging it.

- Richard

[Eduardo Lundgren]

Hi Richard,

I mentioned thousands but hundreds are enough to cause the delay.

I like the idea of externalize an option like that because I had this problem before and I've tried to hide the elements with CSS setting visible:hidden and the performance is the same as with visible children elements, although there is performance improvements when use display:none, at the same time it could breaks the height of the dialog, therefore dragHelper was one solution to get these results, with this option we can let the user move a helper element instead of the original dialog DOM element.

It's a common option in another frameworks and it seems very useful, on EXT JS Framework the Ext.Window has an option called "plain":

plain : Boolean

True to render the window body with a transparent background so that it will blend into the framing elements, false to add a lighter background color to visually highlight the body element and separate it more distinctly from the surrounding frame (defaults to false).

( http://extjs.com/deploy/dev/docs/?class=Ext.Window ).

Apparently, this option has the same result than our dragHelper option that means instead of dragging the original DOM element let the user drag a helper, but in this case auto-create the empty helper.

There is an EXT example for the same helper idea: http://extjs.com/deploy/dev/examples/window/layout.html
Feel free to sniff the HTML and see the x-panel-ghost div being appended to the body on this example.


We can think about another solutions that let us have performance improvements while dragging the dialog.

I ask you guys to think about this carefully, it's looks a useful and common opition.

My vote goes to or keep the dragHelper opition or create a "smarter" option like Ext.Window plain opition.

Let me know your thoughts.

Thank you,
Eduardo Lundgren

[Richard D. Worth]

On Tue, Feb 24, 2009 at 5:40 PM, Eduardo Lundgren <eduardo...@gmail.com> wrote:

Hi Richard,

I mentioned thousands but hundreds are enough to cause the delay.

Still not seeing this as a common case. Do you have a real-world example? And I'm talking about an example that's going to fit in the 80-95% of use cases. If we try to handle that last 5% in each plugin, it will surely lead to bloat.
 

I like the idea of externalize an option like that because I had this problem before and I've tried to hide the elements with CSS setting visible:hidden and the performance is the same as with visible children elements, although there is performance improvements when use display:none, at the same time it could breaks the height of the dialog,

In that case, simply set the dialog height on dragStart, and reset it on dragStop. Like so:

$("#dialog").dialog({
  dragStart: function() { $(this).dialog("option", "height", $(this).parents(".ui-dialog").height()).hide(); },
  dragStop: function() { $(this).dialog("option", "height", "auto").show(); }
});

 

therefore dragHelper was one solution to get these results, with this option we can let the user move a helper element instead of the original dialog DOM element.

With my sample code above, they're moving the original dialog (not a helper), it's just empty. Seems a simple enough two-line work-around for (what I still see as) an uncommon case.

- Richard

[Eduardo Lundgren]

On Tue, Feb 24, 2009 at 9:51 PM, Richard D. Worth <rdw...@gmail.com> wrote:

On Tue, Feb 24, 2009 at 5:40 PM, Eduardo Lundgren <eduardo...@gmail.com> wrote:

Hi Richard,

I mentioned thousands but hundreds are enough to cause the delay.

Still not seeing this as a common case. Do you have a real-world example? And I'm talking about an example that's going to fit in the 80-95% of use cases. If we try to handle that last 5% in each plugin, it will surely lead to bloat.

What about the Ext.Window example ? That represents a very common usecase - dialog using empty helper.

 

 

I like the idea of externalize an option like that because I had this problem before and I've tried to hide the elements with CSS setting visible:hidden and the performance is the same as with visible children elements, although there is performance improvements when use display:none, at the same time it could breaks the height of the dialog,

In that case, simply set the dialog height on dragStart, and reset it on dragStop. Like so:

$("#dialog").dialog({
  dragStart: function() { $(this).dialog("option", "height", $(this).parents(".ui-dialog").height()).hide(); },
  dragStop: function() { $(this).dialog("option", "height", "auto").show(); }
});

This is a good solution. Although, this two lines of code aren't simple as using the option dragHelper and it also doesn't give the user the possibility to use a different element to be the helper instead of the original, with the dragHelper option you can do both possibilities.

It's represents the jQuery UI components integration, one component taking advantage from another component option, in this case the dialog using the draggable helper option.

We can link the dragHelper documentation with the ui.draggable helper option documentation, by this way, the user can figure out how this helper works looking at the ui.draggable helper documentation ( http://docs.jquery.com/UI/Draggable#option-helper ).

[Scott González]

On Tue, Feb 24, 2009 at 9:40 PM, Eduardo Lundgren <eduardo...@gmail.com> wrote:

What about the Ext.Window example ? That represents a very common usecase - dialog using empty helper.

 
I've actually never seen a dialog do this prior to seeing this example.  I'd be interested to know what other libraries support this functionality natively since I agree with Richard that this seems like a minority use case.  Also, while Ext is very powerful, it is very far from being something we want to model our code after.

This is a good solution. Although, this two lines of code aren't simple as using the option dragHelper and it also doesn't give the user the possibility to use a different element to be the helper instead of the original, with the dragHelper option you can do both possibilities.

It's always going to be easier to use an option than to do something yourself.  The hard part of building a good, reliable, robust library is knowing where to draw the line and not add an option.
 

It's represents the jQuery UI components integration, one component taking advantage from another component option, in this case the dialog using the draggable helper option.

As mentioned above, we need to be very careful about deciding when to add options to plugins.  Just because a dialog can use the draggable and resizable plugins doesn't mean that it should expose as many of their options as possible.  In fact, it should only expose the options that are relevant for dealing with a dialog, in the context of a dialog.  In many cases, this won't even be a direct pass-through of the options.
 

We can link the dragHelper documentation with the ui.draggable helper option documentation, by this way, the user can figure out how this helper works looking at the ui.draggable helper documentation ( http://docs.jquery.com/UI/Draggable#option-helper ).

Documentation for any plugin should be fully self-contained.  If you want to know everything about how a dialog works, you should only have to read the dialog documentation.  If you want a draggable dialog, you shouldn't need to know anything about how the draggable plugin works.  If you want to do something really custom with how your dialogs are dragged, you should make the dialog draggable yourself and gain full access to draggable's power.

The beauty of jQuery and jQuery UI is how simple it is to use and learn.  We need to be very careful about mixing things together, blurring lines, adding bloat, etc.  Just because something can be done, or even has been done, doesn't make it a good idea.

[Richard D. Worth]

On Tue, Feb 24, 2009 at 9:40 PM, Eduardo Lundgren <eduardo...@gmail.com> wrote:

On Tue, Feb 24, 2009 at 9:51 PM, Richard D. Worth <rdw...@gmail.com> wrote:

On Tue, Feb 24, 2009 at 5:40 PM, Eduardo Lundgren <eduardo...@gmail.com> wrote:

Hi Richard,

I mentioned thousands but hundreds are enough to cause the delay.

Still not seeing this as a common case. Do you have a real-world example? And I'm talking about an example that's going to fit in the 80-95% of use cases. If we try to handle that last 5% in each plugin, it will surely lead to bloat.

What about the Ext.Window example ? That represents a very common usecase - dialog using empty helper.

A use case is something a user needs, not something a developer has provided. The fact that this option exists in some other library does not naturally mean to me that our users need it in ours. I'm suggesting that 80-95% of the time a jQuery UI Dialog is created, it does not contain 100s of elements, so it shouldn't be a plugin option. That's premature optimization.
 

 

 

I like the idea of externalize an option like that because I had this problem before and I've tried to hide the elements with CSS setting visible:hidden and the performance is the same as with visible children elements, although there is performance improvements when use display:none, at the same time it could breaks the height of the dialog,

In that case, simply set the dialog height on dragStart, and reset it on dragStop. Like so:

$("#dialog").dialog({
  dragStart: function() { $(this).dialog("option", "height", $(this).parents(".ui-dialog").height()).hide(); },
  dragStop: function() { $(this).dialog("option", "height", "auto").show(); }
});

This is a good solution. Although, this two lines of code aren't simple as using the option dragHelper and it also doesn't give the user the possibility to use a different element to be the helper instead of the original, with the dragHelper option you can do both possibilities.

How is it simpler to use the dragHelper option?

1. You have to provide a function which creates and then returns a new DOMElement.

2. If they're dragging around a dialog, and the only issue is dragging performance (because of complex content), why would they want to be dragging around anything but a dialog, or something that looks like their dialog? For that element to even remotely resemble the dialog that you're supposedly dragging around is going to take a lot more than two lines of code.

3. With the dragHelper option, you'd also want it the same size, right? That's most of the two lines above. Or, if size doesn't matter, then just hide the content and let them drag around the titlebar.

dragStart: function() { $(this).hide(); },
dragStop: function() { $(this).show(); }
 

It's represents the jQuery UI components integration, one component taking advantage from another component option, in this case the dialog using the draggable helper option.

We can link the dragHelper documentation with the ui.draggable helper option documentation, by this way, the user can figure out how this helper works looking at the ui.draggable helper documentation ( http://docs.jquery.com/UI/Draggable#option-helper ).

We have made a conscious and explicit decision not to do this. That's why the few resizable and draggable options that dialog exposes are exposed as dialog options. The fact that they're acheived by lower-level plugins is an implementation detail. Sharing code is good. Making someone learn options for 5 plugins to use 1 is not.

- Richard

[David Muir]

Considering how slow dragging dialogs are, this is a very useful tool for those wanting their interfaces to be fast and responsive. Ubuntu uses a similar option for resizing windows, so the idea of using a helper object is a common enough use-case that even window managers use it.

That said, I wasn't even aware of the option until seeing this discussion. I hope it stays as I'd like to use it.

David

[Scott González]

On Tue, Feb 24, 2009 at 5:40 PM, Eduardo Lundgren <eduardo...@gmail.com> wrote:

It's a common option in another frameworks and it seems very useful, on EXT JS Framework the Ext.Window has an option called "plain":

plain : Boolean

True to render the window body with a transparent background so that it will blend into the framing elements, false to add a lighter background color to visually highlight the body element and separate it more distinctly from the surrounding frame (defaults to false).

( http://extjs.com/deploy/dev/docs/?class=Ext.Window ).

Is this the real use case?  Could we add an option that does this as opposed to a direct pass-through of draggable's helper option?  A boolean that clears the contents and adds a class would be much more reasonable to expose as an option (though as I said before I haven't seen this in anything I've used).

[Richard D. Worth]

I'd prefer to simply add .ui-dialog-dragging (see the first message in this thread) and then use css to hide the content

.ui-dialog-dragging .ui-dialog-content { display: none; }

Then we could have dialog automatically (and always) maintain the height of the dialog during drag. No option, nothing for the user to do except add the css line above. Which says exactly what it does (even a lot better than the two lines of javascript I wrote earlier): while a dialog is being dragged, hide its content. This also provides all the unlimited flexibility for displaying other content in its place, changing the background color, the opacity, the border, etc. And it's consistent with ui-draggable-dragging and ui-dialog-resizing (again, see first message in this thread).

- Richard

[Eduardo Lundgren]

On Wed, Feb 25, 2009 at 12:33 AM, Richard D. Worth <rdw...@gmail.com> wrote:

On Tue, Feb 24, 2009 at 10:26 PM, Scott González <scott.g...@gmail.com> wrote:

On Tue, Feb 24, 2009 at 5:40 PM, Eduardo Lundgren <eduardo...@gmail.com> wrote:

It's a common option in another frameworks and it seems very useful, on EXT JS Framework the Ext.Window has an option called "plain":

plain : Boolean

True to render the window body with a transparent background so that it will blend into the framing elements, false to add a lighter background color to visually highlight the body element and separate it more distinctly from the surrounding frame (defaults to false).

( http://extjs.com/deploy/dev/docs/?class=Ext.Window ).

Is this the real use case?  Could we add an option that does this as opposed to a direct pass-through of draggable's helper option?  A boolean that clears the contents and adds a class would be much more reasonable to expose as an option (though as I said before I haven't seen this in anything I've used).

Like I said before: "My vote goes to or keep the dragHelper opition or create a "smarter" option like Ext.Window plain opition."
This option could be a boolean (Scott suggested above) or whatever solution we decide is better, the important result is give the possibility to the user build empty draggable dialogs for performance.

David Muir fave a good example where it's used on the real world.
 

I'd prefer to simply add .ui-dialog-dragging (see the first message in this thread) and then use css to hide the content

.ui-dialog-dragging .ui-dialog-content { display: none; }

Then we could have dialog automatically (and always) maintain the height of the dialog during drag. No option, nothing for the user to do except add the css line above. Which says exactly what it does (even a lot better than the two lines of javascript I wrote earlier): while a dialog is being dragged, hide its content. This also provides all the unlimited flexibility for displaying other content in its place, changing the background color, the opacity, the border, etc. And it's consistent with ui-draggable-dragging and ui-dialog-resizing (again, see first message in this thread).

- Richard

[Scott González]

On Tue, Feb 24, 2009 at 10:33 PM, Richard D. Worth <rdw...@gmail.com> wrote:

I'd prefer to simply add .ui-dialog-dragging (see the first message in this thread) and then use css to hide the content

.ui-dialog-dragging .ui-dialog-content { display: none; }

Then we could have dialog automatically (and always) maintain the height of the dialog during drag. No option, nothing for the user to do except add the css line above. Which says exactly what it does (even a lot better than the two lines of javascript I wrote earlier): while a dialog is being dragged, hide its content. This also provides all the unlimited flexibility for displaying other content in its place, changing the background color, the opacity, the border, etc. And it's consistent with ui-draggable-dragging and ui-dialog-resizing (again, see first message in this thread).

This sounds good to me.  Any objections to this?

[Eduardo Lundgren]

The idea is the goal here, I vote in keep it as simple as possible and for me option is better for this case.

Although, if the result is increase the performance and keep the empty helper whatever solution is welcome.

What we can't is remove the possibility.

[Scott González]

On Tue, Feb 24, 2009 at 10:44 PM, Eduardo Lundgren <eduardo...@gmail.com> wrote:

The idea is the goal here, I vote in keep it as simple as possible and for me option is better for this case.

Although, if the result is increase the performance and keep the empty helper whatever solution is welcome.

What we can't is remove the possibility.

The possibility is always there, even if it means you have to instantiate the draggable on your own instead of using dialog options.

[Eduardo Lundgren]

Considering that we can get the instance of the components we can do everything, what I mean is make the work easier.

[Richard D. Worth]

I think what Scott meant is there's always the possibility of using a simple draggable with a handle div instead of a dialog. So removing the option from the dialog plugin doesn't remove dragHelper for a draggable div with 100s of elements as a possibility.

- Richard

[David Muir]

Like this very much indeed. Makes a lot more sense to modify look and feel during an event via css than through js. Could we also have a .ui-dialog-resizing added as well?

David

[Richard D. Worth]

On Tue, Feb 24, 2009 at 11:02 PM, David Muir <david...@gmail.com> wrote:

Like this very much indeed. Makes a lot more sense to modify look and feel during an event via css than through js. Could we also have a .ui-dialog-resizing added as well?

Yes that was proposed at the first message in this thread:

http://groups.google.com/group/jquery-ui-dev/msg/5c188a1c03684d99

I'm going to call that consensus at this point. Thanks all.

- Richard
 

[Scott González]

On Tue, Feb 24, 2009 at 11:02 PM, David Muir <david...@gmail.com> wrote:

Like this very much indeed. Makes a lot more sense to modify look and feel during an event via css than through js. Could we also have a .ui-dialog-resizing added as well?

Yup, I suggested .ui-dialog-resizing in the first post of this thread.  Haven't heard any objections to removing the resizeHelper option in favor of just adding the ui-dialog-resizing class.

[David Muir]

I've got to start using a thread based mail client....

Cheers,
David

[Wichert Akkerman]

Previously Richard D. Worth wrote:
> If you want a dialog, it means you're looking for a titlebar, a close
> button, maybe some buttons at the bottom.

I disagree. I want dialogs, but without a titlebar or close button as
part of the dialog. For close I have form-buttons inside the dialog,
and a title bar serves no useful purpose most of the time.

Wichert.

--
Wichert Akkerman <wic...@wiggy.net> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.

[David Muir]

Couldn't you just hide that with css?
.ui-dialog-titlebar {display: none;}


David

[Richard D. Worth]

On Wed, Feb 25, 2009 at 4:49 AM, Wichert Akkerman <wic...@wiggy.net> wrote:

Previously Richard D. Worth wrote:
> If you want a dialog, it means you're looking for a titlebar, a close
> button, maybe some buttons at the bottom.

I disagree. I want dialogs, but without a titlebar or close button as
part of the dialog. For close I have form-buttons inside the dialog,

This is my point exactly. If this is what you want, it's possible you want something other than a jQuery UI Dialog. I was attempting to describe the main features of the dialog plugin that separate it from

$("#myDiv").draggable().resizable();

The only other feature (in the default case) is positioning. It's likely this will be abstracted out as a utility plugin that dialog would use (as it does draggable and resizable). In the meantime, if you want to use the dialog plugin as a positionable "empty box" you can just hide the titlebar using css. But that's not the design of the plugin. It's designed to be a dialog, with a titlebar.

a title bar serves no useful purpose most of the time.

Without a titlebar, where would it be draggable by? That's the whole point of most of this thread - draggable dialogs that are dragged around by their titlebar. Same as most all windows in most OS window managers. Seems a pretty useful purpose to me. That and displaying the title.

- Richard

[Wichert Akkerman]

Of course I can hide, but why should I have to hide something that
should not be there? Currently I just remove that stuff from the DOM
directly after creating the dialog.

Wichert.

[Wichert Akkerman]

Previously Richard D. Worth wrote:
> On Wed, Feb 25, 2009 at 4:49 AM, Wichert Akkerman <wic...@wiggy.net> wrote:
>
> > Previously Richard D. Worth wrote:
> > > If you want a dialog, it means you're looking for a titlebar, a close
> > > button, maybe some buttons at the bottom.
> >
> > I disagree. I want dialogs, but without a titlebar or close button as
> > part of the dialog. For close I have form-buttons inside the dialog,
> >
>
> This is my point exactly. If this is what you want, it's possible you want
> something other than a jQuery UI Dialog. I was attempting to describe the
> main features of the dialog plugin that separate it from
>
> $("#myDiv").draggable().resizable();

- overlay
- positioning
- sizing

some of those can be simplified - currently the plugin tries hard to set
inline styles for things that can be done with a few CSS rules.

> Without a titlebar, where would it be draggable by? That's the whole point
> of most of this thread - draggable dialogs that are dragged around by their
> titlebar. Same as most all windows in most OS window managers. Seems a
> pretty useful purpose to me. That and displaying the title.

That quickly leads you to the insanity that is ExtJS, which last time I
looked created 14 nested divs just to create a table since their entire
model is based on the idea that everything should be resizable,
draggable and act like a OS-level window in all aspects.

jQuery has always tried to do the exact opposite: do as little as
possible and do it well. I think that applies here as well.

For non-modal dialogs I can see the point of having them be draggable.
For modal dialogs I can not imagine a sensible use case where you want
that.

[Richard D. Worth]

On Wed, Feb 25, 2009 at 2:11 PM, Wichert Akkerman <wic...@wiggy.net> wrote:

Previously Richard D. Worth wrote:
> On Wed, Feb 25, 2009 at 4:49 AM, Wichert Akkerman <wic...@wiggy.net> wrote:
>
> > Previously Richard D. Worth wrote:
> > > If you want a dialog, it means you're looking for a titlebar, a close
> > > button, maybe some buttons at the bottom.
> >
> > I disagree. I want dialogs, but without a titlebar or close button as
> > part of the dialog. For close I have form-buttons inside the dialog,
> >
>
> This is my point exactly. If this is what you want, it's possible you want
> something other than a jQuery UI Dialog. I was attempting to describe the
> main features of the dialog plugin that separate it from
>
> $("#myDiv").draggable().resizable();

- overlay
- positioning
- sizing

The idea is that they could be someday separate plugins. If or when they do exist separately (and until they do) I wouldn't see it changing the design of the dialog to have a titlebar (visible by default). So I don't see a compelling need to have a dialog option to not add the titlebar element. If there were a real common use case for a *dialog* to not have a titlebar, sure. But if it's simplify repurposing the dialog for something it's not, no.
 

some of those can be simplified - currently the plugin tries hard to set
inline styles for things that can be done with a few CSS rules.

I think we've gotten a lot better about this in the latest release. We fully support width: 'auto' and height: 'auto' now. The default for Height is auto; for width it's 300 to handle our default case

$("<div>Hello, world</div>").dialog();

300px seems a more reasonable default width than the full width of the viewport for such a simple dialog. If you want you can always set your own default to auto. Or you can specify an override in css.

Are there other inline styles that we're still setting that you believe we can do just as well in the css framework? If so, I'd love to hear specifics.

> Without a titlebar, where would it be draggable by? That's the whole point
> of most of this thread - draggable dialogs that are dragged around by their
> titlebar. Same as most all windows in most OS window managers. Seems a
> pretty useful purpose to me. That and displaying the title.

That quickly leads you to the insanity that is ExtJS, which last time I
looked created 14 nested divs just to create a table since their entire
model is based on the idea that everything should be resizable,
draggable and act like a OS-level window in all aspects.

I think what we have is a pretty simple model. Two nested divs, by default it's draggable and resizable (obvisously that's going to add a few more divs). If you want neither or only one you can set each option to false, or simply not include the dependent plugin (in which case it will assume false). We believe a dialog by default should be draggable and resizable, as it is in an OS. That said, there is a recognized use case for a positioned sized element that is not a dialog, and may or may not be draggable or resizable. We don't yet have a plugin just for this.

jQuery has always tried to do the exact opposite: do as little as
possible and do it well. I think that applies here as well.

For non-modal dialogs I can see the point of having them be draggable.
For modal dialogs I can not imagine a sensible use case where you want
that.

If it's on top of content they happen to need to see while interacting with the modal dialog, they'd have to close and then reopen it. Ugh. This is an extremenly minor example, but I still view it as a sensible use case. Just because it's modal doesn't mean necessarily the user should be not able to move it. Just that they shouldn't be able to interact with anything else until it's closed.

- Richard