Minor Description
In most cases, when a component's selection changes, it should be made visible via scrollAreaToVisible(). This is currently done when the user navigates the view via keyboard (e.g. up/down arrows) but it does not happen when the user changes selection state programmatically. The caller must manually call scrollAreaToVisible().
The call to scrollAreaToVisible() can't occur until after the component has been laid out. This requires knowledge on the caller's part of how the component is implemented internally. While this may be viewed as a simple documentation issue, it is compounded by the fact that hidden components are not laid out until they are made visible. As a result, some fairly complex code is required to ensure that such components properly reflect selection state when they are hosted in containers such a CardPane or TabPane, which manage the visibility of their children.
One solution might be to eliminate the optimization that prevents a component from being laid out when it is not visible. This would make it easier for a calling application to know when it is OK to call scrollAreaToVisible(). However, this is not ideal since the optimization otherwise seems fairly valid.
Another option is for the skin class to automatically scroll the selection to visible when the selection changes. When the component is valid, the scrolling could be performed immediately, but would need to be deferred until layout() when the component is invalid. This also assumes that we always want to scroll the selection to visible every time it changes - this seems reasonable, but are there use cases where we might not want to do this?