Some Observations

[Jörn Zaefferer]

While building an example application, I noticed a few issues:

- .slider() can't be used on an input, instead I have to manually create a div, insert that, handle the resulting layout issues...
- there is no demo that shows how to use draggable and droppable to add items to a container; there is the simple photo manager demo, but thats way too complex
-> my attempt at inserting the ui.helper at the droppable had two results: either nothing happened (helper was killed), or I cloned it first, but then ended up with position:absolute and the position styles
- the theme font-sizes are irritating: as soon as I apply a tabs widget, the font-size of the tabs content changes, I dunno why and I don't know how to set it up so that I can toggle tabs without affecting contents font-sizes
- themeroller bookmarklet works well, but takes a long time to load and doesn't seem to cache anything, when loading it again, the load time is just as bad

On the other hand:
- tabs work well as is, and the markup is easy enough to write down without having to lookup the docs or copy an example

Any thoughts on these? I can put comments on the appropiate wiki pages later on.

Jörn

[Scott Jehl]

On Nov 4, 2009, at 9:45 AM | Nov 4, 2009, Jörn Zaefferer wrote:

While building an example application, I noticed a few issues:

- .slider() can't be used on an input, instead I have to manually create a div, insert that, handle the resulting layout issues...

I agree that this would be a nice convenience. Would we just support the slider replacing the input, or fading in and out upon focus? 

Something like this for instance, could replace it:

var myInput = $('#myInput');

$('<div></div>')

.slider({

slide: function(ui){

myInput.val(ui.value);

}

})

.insertAfter(myInput)

.prev()

.hide();

It'd be nice for this to happen when you call myInput.slider(), but maybe just documenting this code is enough...?

We've been talking for a while about being able to call .slider() on a select as well, and there's an example plugin in the lab that does it already.

- there is no demo that shows how to use draggable and droppable to add items to a container; there is the simple photo manager demo, but thats way too complex
-> my attempt at inserting the ui.helper at the droppable had two results: either nothing happened (helper was killed), or I cloned it first, but then ended up with position:absolute and the position styles
- the theme font-sizes are irritating: as soon as I apply a tabs widget, the font-size of the tabs content changes, I dunno why and I don't know how to set it up so that I can toggle tabs without affecting contents font-sizes

This one can be tough because we always put the ui-widget class on the outermost container, and that controls font size inheritance for all its children. 

I'd recommend you write a single override style that sets the ui-tabs-panel class back to whatever font-size you need to make 1em = 10px (or whatever your content assumes 1em is equal to). 

So if you set your global font-size in themeroller to 1.2em, you could add this rule to reset the content panel:

.ui-tabs-panel { font-size: .83em;  }

Does that make sense?

[Richard D. Worth]

On Wed, Nov 4, 2009 at 9:45 AM, Jörn Zaefferer <joern.z...@googlemail.com> wrote:

While building an example application, I noticed a few issues:

- .slider() can't be used on an input, instead I have to manually create a div, insert that, handle the resulting layout issues...

If we built in support for using it on an input, what would we do? Place the generated slider element after the input? Hide the input and they user would have to .show() if they want it visible? Leave the input visible and the user would have to .hide() if they want it hidden? It seems the "resulting layout issues" may be specific to each use case, so I wonder if they aren't better handled by the user. I'm not against this level of integration. Just some questions I think we need to consider. Filament Group has a great example of extending slider in this way:

http://www.filamentgroup.com/lab/update_jquery_ui_slider_from_a_select_element_now_with_aria_support//

but I think that may be a bit more than we should build into slider's core. Maybe we can approach this from an extension point of view? That is, write an extension that allows you to call .slider on an input and/or a select.

 

- there is no demo that shows how to use draggable and droppable to add items to a container; there is the simple photo manager demo, but thats way too complex 

-> my attempt at inserting the ui.helper at the droppable had two results: either nothing happened (helper was killed), or I cloned it first, but then ended up with position:absolute and the position styles

You should be cloning or moving ui.draggable, not ui.helper

- Richard

[Scott González]

On Wed, Nov 4, 2009 at 10:45 AM, Jörn Zaefferer <joern.z...@googlemail.com> wrote:

While building an example application, I noticed a few issues:

- .slider() can't be used on an input, instead I have to manually create a div, insert that, handle the resulting layout issues...

I actually thought you could do this. We should verify that all of our plugins which act as form controls can be called directly on HTML 4 native form controls.
 

- there is no demo that shows how to use draggable and droppable to add items to a container; there is the simple photo manager demo, but thats way too complex

This should be pretty easy to build.
 

-> my attempt at inserting the ui.helper at the droppable had two results: either nothing happened (helper was killed), or I cloned it first, but then ended up with position:absolute and the position styles

We should revisit the docs for this to make sure it's very clear what each of these properties contain. I know a lot of users find out just by logging the ui hash, which can be misleading since ui.helper is sometimes the same as ui.draggable.
 

- the theme font-sizes are irritating: as soon as I apply a tabs widget, the font-size of the tabs content changes, I dunno why and I don't know how to set it up so that I can toggle tabs without affecting contents font-sizes

I've seen a fair amount of comments on the mailing list about font sizes with our themes, but I don't think we can really do much better than what we have - people will always have to tweak the themes to get the exact look they're going for.
 

- themeroller bookmarklet works well, but takes a long time to load and doesn't seem to cache anything, when loading it again, the load time is just as bad

I believe there are plans to do a complete review of the bookmarklet fairly soon.

[Wichert Akkerman]

On 11/5/09 04:42 , Scott González wrote:
> On Wed, Nov 4, 2009 at 10:45 AM, Jörn Zaefferer

> <joern.z...@googlemail.com <mailto:joern.z...@googlemail.com>>

> wrote:
>
> While building an example application, I noticed a few issues:
>
> - .slider() can't be used on an input, instead I have to manually
> create a div, insert that, handle the resulting layout issues...
>
>
> I actually thought you could do this. We should verify that all of our
> plugins which act as form controls can be called directly on HTML 4
> native form controls.

You could with older versions of UI at least, I haven't tried the
current code in a while.

Wichert.

[Jörn Zaefferer]

More:

- when using .trigger("slide") to trigger a slide event, eg. directly after intializing the slider, so that the code in the slide-option gets executed, nothing happens; I'd have to implement the same code again, which is even more annoying as I can't reuse the same function: the slide event handler has to use ui.value in order to get at the actual value, as .slider("value") returns the current value
- when clicking on a an #-anchor before tabs are initialized, the location is updated to include that anchor; when then tabs are initialized, they use that location to display the tab; so far, so good, but when now clicking on other tabs, the location isn't updated, so on each reload, that same tab is activated

[Scott González]

On Thu, Nov 5, 2009 at 2:09 PM, Jörn Zaefferer <joern.z...@googlemail.com> wrote:

More:

- when using .trigger("slide") to trigger a slide event, eg. directly after intializing the slider, so that the code in the slide-option gets executed, nothing happens; I'd have to implement the same code again, which is even more annoying as I can't reuse the same function: the slide event handler has to use ui.value in order to get at the actual value, as .slider("value") returns the current value

I'm torn on this. I could see why someone might expect triggering an event to trigger the callback, but I really wouldn't want to implement that.
 

- when clicking on a an #-anchor before tabs are initialized, the location is updated to include that anchor; when then tabs are initialized, they use that location to display the tab; so far, so good, but when now clicking on other tabs, the location isn't updated, so on each reload, that same tab is activated

Seems like we should probably update the hash.

[Scott González]

I had an idea for how we could fix this. Plugins could bind the callback as an event handler instead of just using it as a callback. This would require plugins to actually write code to handle the callback options, which isn't as elegant as what we have now where the plugins don't need to do any work at all. We could move that logic into the base widget so that each plugin wouldn't need to duplicate the logic, but then the plugins would have to list which options are callbacks. That wouldn't be too bad.

So a plugin would look like this (based on the new widget factory cuz it's nicer):

$.widget('ui.dialog', {
    options: {
        close: null,
        closeText: 'close',
        open: null,
        title: null
    },

    callbacks: 'close open',

    _init: function() { ... }
});
       

2009/11/5 Scott González <scott.g...@gmail.com>