User:Frank Schönheit/ODF Proposals/Mouse Wheel Scroll

Summary

Proposal owner

...

Proposal short name

An attribute controlling the mouse wheel scroll behavior for form controls.

Rationale

Most of today's computers come with a mouse which has a scroll wheel. Usually, in desktop applications this wheel is used to scroll through some document's or user interface element's content.

This is true for form controls in ODF documents as well: There's a number of controls which can canonically make use of a scroll wheel. For instance, a form control described by a form:number element could allow the user to scroll through its value range. A multiline text input field described by the form:textarea element could allow the user to scroll through its content.

However, different modes of operation exist in common user interfaces, considering when mouse wheel input is accepted and processed. In particular, a user interface element might process a mouse wheel scroll event only when it currently is the one and only dedicated active ("focused") element, or it might accept such events regardless of its activation state. The latter is usually used for convenience, since it allows the user to just move the mouse pointer over the UI element, and use the mouse wheel, without actually focussing it.

ODF currently does not allow to define this behavior for form controls. This might lead to undesired behavior of documents used for data input, depending on how vendors implement the form controls in their application.

For instance, imagine a text document containing a multi-line text input control. Moving the mouse over the document, and scrolling the wheel, will initially scroll the document content. If by this, the contained text control is scrolled to a position below the mouse cursor, then suddenly the control might process the scroll events, scrolling its very own content, instead of continueing to scroll the document content. For the application, it's hardly possible to automatically determine which behavior is desired here, this depends on knowledge about the document which only its creator has.

So, the idea is to introdce an attribute form:mouse-wheel-processing, added to all applicable form control types, which determines under which circumstances a form control should process and consume mouse scroll events.

Requested changes to the ODF Standard

Text changes/additions

Note: All chapter numbers in the following are taken from the "OpenDocument v1.2 Committee Draft 02", as of 2009-07-01.

A new attribute is to be added to chapter "17 Generic Attributes", as follows:

The form:mouse-wheel-processing attribute controls in which situations a form control
processes events of a mouse scroll wheel, which happen when the mouse cursor is over
the control.
The value of this attribute can be one of the following:
  - never: The control is completely agnostic of mouse scroll wheel events.
  - when-focused: The control processes mouse scroll wheel events only if it currently has the focus.
  - always: The control processes mouse scroll wheel events regardless of its focus.

Schema changes/additions

The following fragment is to be added to the schema definition:

    <define name="form-mouse-wheel-attlist">
        <optional>
            <attribute name="form:mouse-wheel-processing">
                <choice>
                    <value>never</value>
                    <value>when_focused</value>
                    <value>always</value>
                </choice>
            </attribute>
        </optional>
    </define>

Also, a reference to this new attribute definition is to be added to the following elements:

• form:formatted-text
• form:listbox
• form:combobox
• form:date
• form:time
• form:number

This is to be done by adding the following fragment to the definition of those elements:

    <ref name="form-mouse-wheel-attlist"/>

Impacts

Conformance

This proposal does not add any mandatory features or behaviors to ODF documents or applications.

Backwards compatibility

Existing ODF processors will ignore the new attribute.

Accessibility impact

This feature does not require review by the Accessibility Subcommittee.