jQuery Forum

There was some kind of discussion going down on the Menu wiki page, which wasn't really the right place. Its basically about handling home/end and page up/down keys:

In order to explore if the "new" widget factory can and should make it into 1.8, I built an extremely simplified accordion widget that inherits from a panel widget: <a href="http://jquery-ui.googlecode.com/svn/branches/labs/widget-factory/tests/visual/inheritance.html">http://jquery-ui.googlecode.com/svn/branches/labs/widget-factory/tests/visual/inheritance.html</a>
The interesting part is the click method, which accordion overwrites (and doesn't call super).  For init and destory its just delegating to panel; the method stubs just indicate where additional init/destroy code would be placed.
Please keep in mind that while inheritance is useful in this case, the much preferred approach to building widgets based on other widgets is composition, like in the combobox case: <a href="http://localhost/jquery-ui-dev/tests/visual/autocomplete/combobox.html">http://localhost/jquery-ui-dev/tests/visual/autocomplete/combobox.html</a>
What do you think?
Jörn

--

I suggest that we drop the concept of private widget methods, removing the underscore everywhere, as well as that special code that prevents calls to these private methods.
By doing so, we enable unintended usage, which is important for emergent design: We can't anticipate how a component will be used like, so its good to observer and learn.
We also maintain the current style of public APIs simply by documenting only public methods, or those intended for general use. If it turns out that a undocumented method is actually quite useful, its easy to add to the API, simply by documentating it. Today we'd have to rename the method.
Jörn

--

Two ideas:
Put a download-link on each demo page, eg. a red download button on the Draggable page that would link to the Download builder with the correct selections.
Does the download builder already look at the URL? If not, this would be something to consider for the rebuild. If it does, it could be easy to add.
Add much more prominent CDN links somewhere, including links to theme files. Currently the Download page links to Google's CDN page, which doesn't have Theme links at all.
The only way to find these is to look at the 1.7.2 release blog post, rather hard to find now. Should be easy to add in any case.
Jörn

--

A first draft: <a href="http://bassistance-plugins.googlecode.com/svn/trunk/plugins/validate/demo/themerollered.html">http://bassistance-plugins.googlecode.com/svn/trunk/plugins/validate/demo/themerollered.html</a>
Thanks to Todd for making the initial suggestion. It uses jQuery UI CSS framework classes and the button widget for the submit buttons. I tried to apply it also for the checkboxes - that doesn't really work currently. I'd have to apply .buttons() to each paragraph that holds a checkbox, but that pretty much screws up the layout (and needs adjustments on the validation side to fix the error labels): <a href="http://bassistance-plugins.googlecode.com/svn/trunk/plugins/validate/demo/themerollered-checkboxed.html">http://bassistance-plugins.googlecode.com/svn/trunk/plugins/validate/demo/themerollered-checkboxed.html</a>
Also in a form like that, its not at all obvious that the checkbox is actually a checkbox, and not just a button that triggers something else.
Soo, in summary: CSS framework FTW, base button too, checkbox button not so much.
Suggestions?
Jörn

--

Hi,
I've built a testpage to document this issues with fadeIn/Out: <a href="http://jquery-ui.googlecode.com/svn/branches/labs/fadequeue/index.html">http://jquery-ui.googlecode.com/svn/branches/labs/fadequeue/index.html</a>
As written on that page, the issues are:
<ul><li>Without using stop(), animations just queue up, thats inacceptable</li><li>With
just using stop(), styles end up in the middle, screwing up the next
fade, that is, stopping a fadeout half way through will cause the next
fade in to not fade to 1</li><li>Using stop(false, true) will
finish the animations, which worksaround the above problems, but the
result is ugly, as a stopped fadeout will skip to the end, then fade in
again from 0, instead of just fading in from the current opacity</li><li>The
crazy complicated stuff, using a mix of fadeIn/Out and fadeTo, apart
from being way too complicated, has the big drawback that the
fadeTo-animations take exactly as long as the others, while it usually
doesn't fade from 0 to 1, but only from, say, 0.7 to 1. Adding a
calculation to figure out how long the animation should be relative to
the current opacity would make this just more complicated.</li><li>fadeIn/Out can use opacity values defined in CSS stylesheets, while fadeTo requires the user to specify the opacity</li></ul>My goal for now is to create a plugin, with your help, that can be used instead of fadeIn/Out. It would not queue up animations, it would read opacity from stylesheets, just like fadeIn/Out do, and it would adjust the animation duration relative to the current opacity if a fade is stopped/reversed, so that if a fade in is stopped half-way through by a fadeout, the fadeout would only take half the specified duration, resulting in the same animation speed all the time.
Based on how the plugin ends up, I hope we can port back something to jQuery Core to make that available just as easily as fadeIn/Out.
Looking forward to your ideas.
Jörn

--

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

Implemented a searchAutocomplete widget on top of autocomplete:
http://jquery-ui.googlecode.com/svn/branches/dev/tests/visual/autocomplete/select.html
Currently the button displays all results, giving focus to the input
for keyboard control. When entering a value, the list is displayed,
too, but not filtered; instead matches are highlighted in the results.
Pleae review and comment this as well as the default visual test:
http://localhost:81/jquery-ui-dev/tests/visual/autocomplete/default.html
I hope FG can improve the Theme for both tests, eg. matching the input
to the button height.
Jörn

Thanks Maggie for the update on the Button theme. The result so far is
here: http://jquery-ui.googlecode.com/svn/branches/dev/tests/static/button/default.html
Icon positioning is currently the biggest issue, and the
float-approach doesn't work out in IE6. An approach to explore is to
use inline-block instead, keeping in mind that it works in IE6 only on
inline-elements. Stupid enough, this should work:
.ui-button .ui-icon {
display: inline;
display: inline-block;
}
While that should help with IE, its not supported in FF2. There are
workarounds for that as well. A JavaScript example:
http://jquery.bassistance.de/validate/demo/js/cmxforms.js
That uses display:-moz-inline-box, which is, along with
-moz-inline-block, mentioned here:
https://developer.mozilla.org/en/CSS_Reference/Mozilla_Extensions (too
bad all the links just point at the FF3.5 page; not so much an actual
developer resource)
A related discussion, that may help to figure this out:
http://archivist.incutio.com/viewlist/css-discuss/67644
Jörn

Please take a look at these two:
http://jquery-ui.googlecode.com/svn/branches/dev/tests/visual/button/default.html
http://jquery-ui.googlecode.com/svn/branches/dev/ui/jquery.ui.button.js
The approach so far was to keep each task seperate: push button,
toggle button (based on checkbox), toggle-set (based on radio). So far
toggleButton is applied to a checkbox, while radioButton is applied to
some element, and its child-radio-inputs will then be converted to a
button set.
Its certainly possible to merge all these into a single button widget,
but that would probably get quite messy in the long run.
Jörn

It looks like the Modal implementation needs to be based on what
$.ui.dialog.overlay currently does, and replace that. This isn't a
trivial task:
- there is shared maxZ property to handle
http://dev.jqueryui.com/ticket/4309 - this is read and write both by
$.ui.dialog.overlay and dialog itself
- $.ui.dialog.overlay handles multiple instances, while also creating
an overlay element for each one; its unclear how this should be
transferred to a widget, eg. should the modal be created just once for
each modal dialog, and open/close it, or create and destroy it for
each open/close of the dialog?
- the event capturing has some oddities, and performs badly according
to http://dev.jqueryui.com/ticket/2804
- there's a lot of extra code specifically for IE6, for calculating
the window size
I think a lot of this has to be cleaned up for Modal.
Jörn

fadeIn() and fadeOut() cool be much more useful if they'd work
together instead of queueing up against each other. A usecase where
this comes up is a tooltip widget, where a single element is reused to
display the tooltip of various elements (absolutely necessary for a
large number of tooltipped elements, eg. a large table).
An example of that usecase, implementing an ugly workaround to get the
queuing under control, is here:
http://jquery-ui.googlecode.com/svn/branches/dev/tests/visual/tooltip/default.html
The relevant code of the workaround is this:
open: function(target) {
    [...]
    
    if (this.tooltip.is(":animated"))
        this.tooltip.stop().show().fadeTo("normal", this.opacity);
    else
        this.tooltip.is(':visible') ? this.tooltip.fadeTo("normal",
this.opacity) : this.tooltip.fadeIn();
},
close: function() {
    [...]
    
    if (this.tooltip.is(':animated'))
        this.tooltip.stop().fadeTo("normal", 0);
    else
        this.tooltip.stop().fadeOut();
    
    [...]
}
Where "this.opacity" refers to the opacity value, read in _init:
this.opacity = this.tooltip.css("opacity");
Thats necessary to use the CSS defined opacity value, instead of just
fading to 1.
As you may guess, that workaround isn't easy to come up with - I've
written it some time ago and have no idea why it works. I don't think
this makes sense as a plugin, so I hope we can come up with an idea to
improve fade support in core, to be available and useful for everyone,
not just someone who knows where to copy the workaround from.
Jörn

Test coverage reports based on http://siliconforks.com/jscoverage/
Coverage means that a line of code is executed at least once. This
doesn't test for each possible code path for that line; but if its
never executed at all, its very likely that its buggy.
Accordion: 63%
Missing: mouseenter, mouseleave and keydown events, animations
Core: 47%
Missing: $.ui.plugin, $.ui.contains, $.ui.hasScroll, $.ui.isOverAxis,
$.ui.isOver, $.fn.enableSelection, $.fn.disableSelection,
$.fn.scrollParent, :widget-custom-expression, method calls to _private
methods, $.widget.prototype._trigger with an event that has a
originalEvent property, all of $.ui.mouse
Datepicker: n/a, the jscoverge server crashed trying to parse
ui.datepicker-fr.js, doh
Dialog: 63%
Missing: hover, focus, blur, mousedown and click events on title bar;
calls to open() and close() with options.modal=true; hover and blur
events on buttons; most of the _position code (probably broken by my
change there); all of $.ui.dialog.overlay
Draggable: 54%
Droppable: 19% (ugh)
Position: 96% (yay)
Missing: Call position as a getter; flip collision detection with the
at-value == "center"
Progressbar: 100%!
Resizable: 58%
Selectable: 78%
Slider: 44% (ugh)
Sortable: 34% (ugh)
Tabs: 69%
Overall not too shabby, though droppable, slider and sortable really
need some attention. Resizable and draggable are also covered by
dialog - when running both dialog and resizable tests, coverage for
resizable goes up to 74%. That also means that there are too many
resizable features tested as part of dialog, instead of being in the
resizable suite.
Jörn

browserscope.org now has some reflow tests, including a bookmarklet:
http://www.browserscope.org/reflow/about
The bookmarklet works great, I still need to figure out if the tests
themselves a useful for improving CSS performance.
Jörn

We made some progress on the Tooltip planning: http://wiki.jqueryui.com/Tooltip
Thanks to Craig Thompson for pushing this forward.
Some of the open issues:
- currently there is a sticky tooltip, which can be seen as a
glorified tooltip, or as a very lightweight dialog; I think we may
need to provide an alternative to our current dialog (or trim it down)
for that to work, but tooltip isn't the right place, the interaction
of a sticky tooltip is just screwed: a way-too-tiny close icon, no way
to discover that a click will actually open the tooltip-dialog instead
of opening a real dialog or another page; the events (click) or
completely different then for a default tooltip (mouseenter,
mouseleave)
- Accessibility: nothing there yet
- configuring Position plugin: the of-option is somewhat inflexibe, as
the user can't configure the position option to use the mous event for
the of-option (it would be easier if of would accept a callback to get
the value at "runtime"); also Position doesn't provide any info about
its collision detection, so we don't know when the tip (or callout)
has to be positioned elsewhere to adjust to the collision detection
- methods: should the Tooltip provide open/close methods? Could these
be used to implement a sticky tooltip? Or would a sticky tooltip
plugin cancel the beforeclose event and use the close-method when
clicking the close-icon?
Jörn

Hi,
we've tweaked our process to develop new plugins a few times already,
and this probably won't be the last time. After various discussion
during the DevDays and the conference, Richard, Scott and me decided
during the team meeeting today to restructure the dev branch, and
therefore our priorities, as the following:
- Move all folders currently under branches/dev into branches/labs
- Create a new branch from trunk under braches/dev
- Start from scratch, in that single branch, with autocomplete,
button, modal, menu and tooltip
- Once these five are all merged into trunk, start on a new dev branch
with five new widgets
I'll be doing the necessary changes, starting tomorrow. If you have
any questions, let me know in this thread.
Jörn