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