The chunks in unitState.dataParts shall be strings and nothing but strings as stated in the verona2+ specification. I interpreted this a little bit more open before, and stores JSON data in it, which lead to compatibility issues.

Treat elements with `contenteditable` like form fields regarding the attributes `name` and `required`

Background:

The state of being done for an item is not well-defined in Verona2.
It pretty much open, what for example makes a checkbox-item `done`, when it's unchecked, since it can not be told if it's left unchecked intentional or not.

In the Verona2 version of this player, an item (wich is, spoken in HTML-terms any form element and any element with contenteditable-attribute), could be regarded as answered, but not valid. This lead to the question, how to tell if an unchecked checkbox oder an empty textbox was answered at all. The simple-player employed a mechanic, that marked an item as touched when it was entered by the mouse or git the focus. Touched items where regarded as answered, regardless if they had content or not, and regardless of their validity from the HTML point of view.

In Verona3, answers should not be propagated if they are invalid while "invalid" is defined as "not interesting for the study".

@see: https://github.com/verona-interfaces/player/issues/25

Form this followed that there is not 'complete-and-valid' state in the ResponseProgress anymore since it's the same as 'complete' and the Simple Player must not distinguish between answered and answered and also valid items anymore.
Additionally, the Simple Player should take raw HTML as literal as possible and the former "markAsTouched"-attempt could therefore lead to a behaviour that was not intended by the unit's author. So the mark-as-touched-attempt becomes obsolete and was removed.

The downside of this is, that the problem of intentionally unchecked checkboxes, wich is not solved in HTML (https://www.w3.org/html/wg/tracker/issues/111) in a satisfying way is not solved yet by the player in any way and remains for the unit's author.

Another issue left open is, how to handle element's pseudo-form-elements with `contenteditable`, that can not be marked as required (https://github.com/iqb-berlin/verona-player-simple/issues/8).

closes https://github.com/iqb-berlin/verona-player-simple/issues/6

This is a subtile change in Verona3

from the top-level iof the JSON where it was places wrongly.

* Adds startPage in playerConfig in vopStartCommand to let the player jump to the previously selected page; this might also be helpful in evaluation use cases where (after the test) the given answers of items at a specific page are expected to be presented

* makes validPages and currentPage optional in playerState for players w/o paging feature

In Verona2 it was mandatary, now it's consecutive:

"made validPages and currentPage optional in playerState for players w/o paging feature"

removed non-standard property unitCount, which was not implemented but enabledNavigationTargets

It is assumed that no response will be reported unless it is valid, so complete will do

Remove vopGetStateResponse; the player should answer the vopGetStateRequest by sending vopStateChangedNotification with all data parts

fixes https://github.com/iqb-berlin/verona-player-simple/issues/3

The implicit form submission had two different negative effects:
- Hitting enter in an input-field could navigate the test-host's iframe to an unknown page
- Bizarre enough browsers click the frist <button>-element in a form after the enter-button got hit in any input-field

Fixes https://github.com/iqb-berlin/verona-player-simple/issues/5

in order to send a vopStateChangedNotification even if `myInput.value = "something"` is used by any script!

add whitespace after pages in scrolled mode to make sure, it is possible to scroll to last page if it's smaller than viewport