API Changes in the Tooltip

Thu Dec 2 18:00:07 UTC 2010

This was talked about at the last developer meeting. We are going to have to do some tasking for this to see if we can get it done in time for 1.3. I believe it was suggested that we could do part of the implementation for 1.3 and finish up the rest for a later release.

- Justin
On 2010-11-26, at 3:59 PM, Antranig Basman wrote:

> 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
> 
> _______________________________________________________
> fluid-work mailing list - fluid-work at fluidproject.org
> To unsubscribe, change settings or access archives,
> see http://fluidproject.org/mailman/listinfo/fluid-work