Thank you!
To work with the existing iscroll5 script, then, I will need to
create a simple data structure describing some properties of each
possible option. (e.g. is it an iscroll5 option, or an additional
widget option? Is it initialized in in iscroll5, or allowed to be
undefined in iscroll5? Etc.)
Two more questions:
1. Is it at all typical of widgets to have "sub-options"?
iscroll5 has one case of this. It has an option "indicators", which
is an object containing quite a number of options related to
indicators (scroll bars) such as fade, interactive, resize, shrink...
I might merge options found in an object at that key just as done
for options itself, or I might flatten the namespace. e.g. options.indicatorsFade.
Which approach is more "widget-friendly"?
2. iscroll5 "normalizes" options. That is, it will set
some options that are unset in the merge between defaults and your
supplied options. (Rather than to static defaults.) And it will
"fix" some irrational options.
(So, then, I copy back the options to the widget, as I do with the
current jquery.mobile.iscrollview.)
Is there precedent for this in other widgets? Is this unexpected
behavior of a widget?
I don't see a real problem with this, so long as the
documentation makes it clear. Anybody see other problems with this?