I have created a widget in dashcode and placed it in the book.
The widget contains a form supported with jScript.
The form requires user input.
At the moment the cursor stays in one position on the screen and the next input field with the focus moves that fixed
position on the screen.
What I was expecting was that the form would not move and that the input focus would move from input field to input field.
Help with this issue would be greatly appreciated.
See:
iBooks Author: About HTML widget creation
Using DashCode to create an interactive widget
Just remember that tabbing from one entry field to another with a touch interface is different from a desktop OS, especially when the onscreen keyboard may expect the user to tap | Previous | Next |
As well:
Creating Books with JavaScript Interactivity
With OS X Mavericks, iBooks customers can read interactive books on both iOS and OS X. Interactive features like drag-and-drop or user-initiated animations are supported on both platforms. Interactivity on iOS requires touch events, while interactivity on OS X requires mouse events. Ensure that your script supports both touch and mouse input.
Thanks for the information.
I have just created a widget with one default button and tried to load but the message I am now getting is 'The HTML5 widget wasn.t added because it requires use of Java, which isn't allowed'. I check the widget and Java Script execution is ticked.
Help is always appreciated
First, Java is not JavaScript.
Are you seeing the focus / move behavior on iOS or OS X or both?
The focus move behavior is only on iOS on a first generation iPad [don't know about any other iOS on a later model iPad].
If I reduce the vertical height of the widget to less than 200px and with a top margin of 10px there is no movement irrespective of where the input field is located < 200px.
I have set the widget info file width to 1024 and height 768 so that the widget displays top centre.
When the keyboard is displayed clear of the widget for any input position over 200px that input field moves to the same point on the screen as do other inputs fields that are over 200px.
In its web equivalent the deployment works perfectly in Safari, IE, Chrome and Firefox.
Desktop browsers are meaningless test platforms when it comes to HTML content for iOS (or any mobile platform, really).
I do know that on iOS, enclosing views are moved so the user can clearly see where she is inputing text, and this behavior happens in both HTML and native views. This is expected (and correct) behavior. The views return to their proper positioning once the keyboard has been dismissed.
So, what you are seeing – as near as I can tell without pictures or videos – is correct behavior. Is there something I'm missing?
Your response makes very good sense and I thank you for your time. What I will do is test the form in Safari on iPad and see what results and post the outcome.
Minor etiquette nitpick: one is supposed to mark others' posts as helpful or solving one's question. Marking personal follow-on posts as solving the question – which you appear to do frequently – is poor form, not fair to the people who helped you, and confusing to other participants trying to find an answer to the question originally posed.
Dashcode Widget
