Theme handling in Dialog and Datepicker widgets

[Christoph Herold]

Hi everyone!

As I'm working on the integration of jQuery UI in DNN, I come across
an issue concerning the theming of the Dialog and Datepicker widgets.
I was very impressed, when I saw that you even added support for
multiple themes on one page by simply prefixing the styles. The
problem is, that the popup controls are added at the bottom of the
page, therefore being only themeable by adding the class name to the
body. But this disables the use of multiple themes.

I was able to work around this issue by using the open/close and
beforeShow/onClose events respectively and using jQuery().wrap to
create a <div> with the given theme's class name, and jQuery().replace
to remove it when closing. In the case of the Datepicker I was able to
use jQuery(inst.dpDiv) to access the element for wrapping. For Dialog
I had to use jQuery(this).parent().parent(), which, to me, looks kind
of ugly, and I fear this is bound to break in future releases. Also,
the close events are called at the start of the closing animation, so
the wrapping div and therefore the theming is removed before the
animation completes.

Shouldn't the popup widgets include a theme name option so this
handling can be included with the widget? I'd be willing to supply a
patch for this feature, if it is decided to include this option.

Best regards,
Christoph

[Jörn Zaefferer]

My proposal for that was an appendTo-option: http://dev.jqueryui.com/ticket/4306

Would that work for you, too?

Jörn

[Christoph Herold]

Yes, I think, that should work too, although the user may have to be
more careful with this option concerning position offsets. But in the
end your's is definitely more flexible. Thinking of the server side, I
would probably just place the creation of the "appendTo" element in
the document ready block using jQuery, too. This way, I can still have
the element at the end of the body without having to worry about other
server side controls changing things around.

Here's my vote for the appendTo option. I'd be glad to submit a patch
for that, too :-)

Best regards,
Christoph

[Scott Jehl]

Christoph's first idea is more in-line with what we've been discussing
already on the wiki.
Unless I'm misunderstanding the suggestion, "appendTo" will only
really suit the needs of plugins that aren't overlaid on top of other
content, and those plugins aren't the problem (it's easy to scope to a
tab strip because it's right in the document flow).

The scoping problem is with plugins like datepicker, dialog, and
whatever others that need to be appended at the end of the body for z-
index stacking purposes. We had agreed that these plugins will need a
helperClass option.
All this would do is essentially wrap a static div ( with a class
matching the option's value) around the overlay plugin elements, which
will soon be overlay, shadow, and the plugin itself.
Then you can simply scope styles against that helper class.

[Jörn Zaefferer]

That makes sense, too. I would have used appendTo like that, though I
assumed that it might be useful to append a datepicker to a dialog
instead of the body element. If that doesn't make sense, nevermind.

Jörn

[Scott Jehl]

Hmm, I guess in a case like that there's the option to use datepicker
inline anyway?

On Apr 24, 2009, at 8:21 AM, Jörn Zaefferer <joern.z...@googlemail.co

[Jörn Zaefferer]

Try to display a form that contains an input field with a datepicker
in a dialog. The datepicker isn't display above the dialog, but below
it instead.

I just added this to the modal-form dialog demo:

In the form markup:
<label for="date">Date</label>
<input type="text" name="date" id="date" value="" class="text
ui-widget-content ui-corner-all" />

To initialize:
$("#date").datepicker();

And the additional script:
<script type="text/javascript" src="../../ui/ui.datepicker.js"></script>

Jörn

[Scott González]

Does anyone object to adding appendTo and <pluginName>Class options to all plugins that generate a wrapper?  Dialog already has a dialogClass option, which gives you the ability to have a class applied to the outermost generated wrapper; we could do the same for datepicker.  Adding the appendTo option would solve some of the other various issues, and we could default the option to 'body' to keep the current behavior.

[Scott Jehl]

Yeah, I think we discussed this in the past. It would add a class to a
wrapper div which is always there in positioned plugins (always
classed generically maybe as .ui-widget-wrap), wrapping not only
dialog, for instance, but also shadow, overlay, and iframe fixer for
that dialog. Is that right?
Appendto is nice as well, since it solves different problems beyond
just css scope issues.
I think both would be great in all overlay type widgets



On Jul 12, 2009, at 11:06 PM, Scott González

[Jörn Zaefferer]

appendTo option sounds fine, as that was my initial proposal anyway:
http://dev.jqueryui.com/ticket/4306

Whats the default for <pluginName>Class? And what is Scott referring
to with ".ui-widget-wrap"?

Jörn

[Scott González]

On Mon, Jul 13, 2009 at 3:27 AM, Jörn Zaefferer <joern.z...@googlemail.com> wrote:

Whats the default for <pluginName>Class? And what is Scott referring
to with ".ui-widget-wrap"?

The default is an empty string (don't add any additional classes), so in the case of dialog, the outermost wrapper always has a class of "ui-dialog" and you can specify additional classes via the dialogClass option.

I believe Scott Jehl is talking about adding an additional wrapper, which I don't think is necessary.  Do our scoped themes support putting the scope directly on the widget?  That would be the only reason I can think of that would require an additional wrapper.

[Scott Jehl]

No, they don't.

Theme scope is always handled by descendent selectors, which is why we worked out this universal wrapper idea. When you scope a theme in the dl builder, whatever you type is prefixed with a trailing space before every selector string in the UI CSS files. 

Adding scope to the widget itself can't properly scope the other classes being used on that element, and it also does nothing for overlay and shadow either.

[Scott González]

Here are my current thoughts:

Add an appendTo option to datepicker and dialog; default to null (this changes current behavior, but should actually solve more problems than it could potentially cause).  Here's how we should handle null: If the element is an inline datepicker or a dialog and the element is in the DOM, don't move it.  For datepickers if the element is an input element that the datepicker will be tied to, insert the datepicker immediately after the input or append to the input's parent.  If the element is not in the DOM, append to the body.

There's shouldn't be a need for a datepickerClass option since it doesn't generate a wrapper for inline datepickers and if the datepicker is attached to an input, then it can be scoped by the parent.

Don't add extra wrappers just to allow TR theme scoping.  TR themes are not a 100% solution for all theming needs and the user should be able to add a wrapper on their own if they need to.  The extra markup would essentially just be cruft in most cases.

[Scott Jehl]

Isn't that ignoring the fact that we always need to append overlaid widgets to the end of the body? A datepicker inserted directly after its input will end up with zindex issues with other elements in ie. Default for overlaid widgets should always append to body and reappend on every open (inline widgets don't need to append to anything, as you said). If someone uses the appendto option to override the body default, then that's fine, but that's an exception IMO.

On the class though, we really need a way to scope any overlaid widgets using our framework. You're right that it isn't the only way to style widgets, but it is our supported framework and lots of people have this problem already (with no official solution yet). 

If we don't wrap dialog, shadow, and overlay, how could we possibly scope a theme to them?

[Scott Jehl]

Also, the problem is a user can't add that wrapper on their own. We constantly re-append out of their wrapper, and even if we didn't, it's an ugly workaround that I wouldn't trust to be future compatible... don't u think?

This one wrapper would address this issue in a clean way.