API Changes in the Tooltip

[Antranig Basman]

Hi Michelle - thanks for this heads-up about the tooltip plugin. Justin 
and I had a conversation about it yesterday afternoon which I'd like to 
summarise -

The work done on restoring at least the delay option for the tooltip 
should be packaged in a way that it is reusable in other components - 
for example the pager and others. Justin said that this was not actually 
very much code, and was able to be achieved using the "custom 
animations" option for the plugin. But I think this is also an 
opportunity to make some other improvements in the usability of the plugin.

I think a good approach from here would be to create a "wrapper 
component" for the raw jQuery UI plugin which would be a standard Fluid 
component that could be configured as a subcomponent (IoC driven or 
otherwise) of any component in a standard and repeatable way. Our 
"that-ist bridge" can convert any Fluid component into jQuery UI plugin 
but going the other way requires some work.

The other useful functionality to restore would be point 3, provided by 
the tooltip ID. Actually this functionality was never "completely 
helpfully" delivered - the ability to provide the tooltip ID was 
(presumably) morally aimed at the capability of reusing the same DOM 
node and markup for multiple tooltips. Justin showed me that since we 
have lost this capability for the time being, the new use of the plugin 
creates a lot of "mouse droppings" in the DOM which could significantly 
impact performance on pages where there are lots of DOM nodes which 
require tooltips.


What I suggest for the new "tooltip wrapping component" is an API 
somewhat similar to our "selectable" and "activatable" plugins for 
keyboard-a11y - the configuration argument to the component contains a 
map of DOM nodes/selectors to the text or markup that should be 
displayed over that node. The component only ever creates one instance 
of an actual tooltip plugin instance, and the map can be updated at any 
time if the required tooltip text changes. And the component would also 
subsume the packaging for applying the "custom delay" configuration that 
we have just worked on.

To answer your specific questions, I wanted to clarify 1. - which is the 
API that would not work in most uses, why doesn't it work?

2 & 3. I think it might be possible with the "wrapping" approach to 
preserve the old options, although the only particularly useful one to 
end users is the "delay". The "tooltipId" option can't be preserved 
without rewriting the plugin but in fact it never perfectly met its need 
in the first place. More useful would be the "once-only" semantics for 
creating markup provided by our wrapping component which would be 
represented by its stable identity as a Fluid component instance. We can 
provide this facility without needing to change the plugin code.

We could expose some of the "new tooltip options" since they could 
conceivably be useful, although the only particularly helpful one I can 
see is "position".

On 25/11/2010 18:56, Michelle D'Souza wrote:
> Hi,
>
> The accessibility improvements in 1.3 required a fix to the tooltip that we used. When the author was contacted, we found out that the tooltip code base we had been depending on had been end of lined and that there was a new tooltip plugin that would be shipping with jQuery UI 1.9.  We have switched to using this new tooltip in both Inline Edit and Pager and have found that the keyboard accessibility in the new tooltip is greatly improved.
>
> With the switch has come some API change. The three things that are not available in the new plugin are:
> 1. a tooltip styling option
> 2. a delay option
> 3. a tooltip ID which allowed the user to specify the ID of the tooltip DOM node
>
> Inline Edit is a production component so we preserved both the styling and delay options in the API. The code to preserve this API is currently in the Inline Edit codebase. We decided to remove the tooltip ID option since it is actually a buggy API that when used results in invalid markup if there are more then one Inline Edits on a page.
>
> Pager, on the other hand, is a preview component whose API we expect to change. Currently, we have not preserved any of the three API changes above. Instead, we exposed the entire options structure for the new tooltip plugin in the Pager options. This choice may result in future API change especially since the tooltip plugin is still pre-release.
>
> I have a few questions about these choices:
>
> 1. Is it reasonable to remove an API that would actually not work in most uses of the component?
> 2. Should we expose the new tooltip options in the Pager options? What about in Inline Edit's options?
> 3. Should we preserve the delay and tooltip styling options in Pager?
>
> Other comments?
>
> Thanks,
>
> Michelle
>
>
>
>
> ------------------------------------------------------
> Michelle D'Souza
> Software Coach, Fluid Project
> Inclusive Design Research Centre
>
> _______________________________________________________
> fluid-work mailing list - fluid-work at fluidproject.org
> To unsubscribe, change settings or access archives,
> see http://fluidproject.org/mailman/listinfo/fluid-work