[whatwg] Input type=date UI discussion

[Brian Wilson]

[I hope my mailer doesn't screw up the formatting too much]

Some possible user interface realizations (draft) of the date widget:
--------------------------
Input type=date widget:
    http://people.opera.com/brian/testfiles/input-date-widget.png
Input type=date widget (disabled):
    http://people.opera.com/brian/testfiles/input-date-widget-disabled.png
Input type=date popup:
    http://people.opera.com/brian/testfiles/input-date-popup.png

1. Widget Description
--------------------------
An Input Type=Date widget indicates a date value. According to the spec,  
this is the domain of the allowed input: "A date (year, month, day)  
encoded according to ISO 8601: four or more digits (0 to 9) representing  
the year, a hyphen (U+002D), two digits for the month, a dash, and two  
digits for the day. All the numbers must be in base ten and zero padded if  
necessary."

The following attributes will directly affect the display of this widget:
disabled, list, min, max, readonly, step, value.

The following attributes will explicitly not change the rendering of this  
widget:
pattern, maxlength, size.

2. Widget Look and Feel
--------------------------
2.1 Main Widget Characteristics
- Initial display is a read-only text box field with a calendar grid icon  
on the left. Activating the widget invokes the calendar popup sub-widget.
- The popup date selector should have a solid or beveled frame border  
around it to differentiate from surrounding content.
- Attribute visual effects - Disabled attribute: the initial text field is  
grayed out, and the popup can not be generated by user key or click  
action. Any valid existing value will be displayed in the grayed out  
field. The widget's data will not submit with the form.
- Attribute visual effects - Readonly attribute: Any valid existing value  
will be displayed in the field, but the user can not invoke the calendar  
popup. The widget value may only be changed via scripting when this  
attribute is used. The widget's valid value is submitted along with form.
- Popup date chooser appearance: Suggested default dimensions for this  
widget are 300px wide X 200px tall (is this ok? What should the reasoning  
be? I just used a rough estimate based off the screenshot =)
- Popup date chooser placement: Heuristic for placement - should always  
appear within the browser canvas when possible. The top-left corner of the  
popup should appear just under the bottom-left of the read-only text box.  
If the device window is too small to display at the recommended  
dimensions, alternate layouts should be used, as long as chooser  
functionality remains intact. it should display in "best" location.  
Whatever the placement, chooser popup widget must be small enough to  
always be totally visible even at 640x480. This requirement may be even  
smaller on smaller devices.
- Popup date chooser appearance: Days not in the current month on the day  
grid should be either an alternate color or grayed out to aid visual  
differentiation.
- Popup date chooser appearance: If a day button outside the current  
highlighted month is clicked on, the month and year fields are  
automatically adjusted as appropriate.
- Date widget appearance: Once the date chooser popup widget has been  
dismissed, the date in its correct localized format will be displayed in  
the input date widget. This value is not free-form editable. Widget should  
be wide enough to always display the entire date in its localized format.  
The date format used internally and in the DOM is its submission format.
- Year numbers, Month labels and day numbers should be localized strings.
- If a value attribute is present, and valid, when the popup is invoked,  
the year/month/day indicated will all be pre-set. The year field will have  
initial focus.
- Valid values for the step attribute must be non-negative integers  
greater than zero.
- The default step value for this control is 1. The measurement units are  
in days.
- Display format for the field does not match submittal format...what  
should it be?
- Should the left-most day of the week be Sunday or Monday? Is this a  
localization issue?
- Possible addition: Two additional function buttons not mentioned in the  
WF2 specification could aid usability:
"Current" (set the date to the current date), and "Reset" (reset the date  
to the field's value before popup was invoked).

2.2 Widget Error/Boundary Conditions
- Value: If no value attribute is present, the current year, month, day  
will be used as the default values upon entry to the popup (obeying any  
min/max/step attribute values).
- Value: If value attribute is present but not conformant to type, it will  
be treated as though the value was null (""). The popup will then behave  
as described above.
- Min/max: If a value is specified that is less than any valid min value  
specified, or greater than any valid max specified, the field will be set  
to that value. However, if the popup date chooser is invoked, the value  
will be automatically set to the respective min/max value.
- Min/max: If the min or max value violates the date format, it will be  
ignored.
- Step: If no step attribute is specified, it defaults to 1 day.
- Step: Negative, zero, or invalid step values are ignored and treated as  
the default value of 1 day.
- Step: If the step value is greater than the range between the min and  
max...what should happen?
- Value: If a valid value attribute does not fall on an allowed interval  
of min/max/step, the value will be used as the widget's value. If the  
popup date chooser is invoked, the value will snap to the value nearest  
the original value that satisfies the min/max/step relationship.

3. Event Handlers and the DOM
-----------------
3.1 Event Handlers
- Click: Fires when any part of the widget is clicked. Clicks within the  
calendar popup do not trigger a click event. A click event on the widget  
generates the calendar popup. The event is triggered before the popup is  
generated.
- Change: Triggered only if date value has changed and focus is lost on  
the element.
- Input: Fires every time a value is changed in the year, month or day in  
the popup.
- Focus: Fires when focus is given to the widget via TAB navigation to the  
field or by clicking anywhere that would initially trigger a click event.  
If the popup is displayed, the element still has the "focus".
- Blur: Focus was on the element, and TAB navigated away, or user has  
clicked anywhere other than the widget or popup.

3.2 DOM
Button or key press events will suspend visual changes to the widgets  
numeric value until next subsequent button or key up event. The widget  
will operate on a last-value-valid principle, which means any DOM changes  
that take place between key/mouse down and key/mouseup will be lost.

4. User Input
-----------------
4.1 Pointing Device Actions
   - Clicking anywhere on the widget generates the date chooser popup.
   - Clicking outside the calendar popup dismisses the popup and uses the  
current values in the popup as the new date value.
   - If the date selected in the popup is not valid according to the  
field's constraints, the value will revert to the last valid value.

4.2 Key actions
   - The widget display is read-only. Except for the listed key behaviors  
below, the widget is unresponsive to key input.
   - TAB moves focus to and from the date widget. Focus is received from  
previous element in the tabindex order (or the previous focusable element  
in the document order.) Focus is sent to the next focusable element in the  
tabindex order (or the next focusable element in the document order).
   - ENTER: Invokes the date chooser popup
   - DOWN arrow: Invokes the date chooser popup
   - Key actions within the date chooser popup
     - Popup initial focus: Year field.
     - TAB key dismisses the popup and moves focus to the next element in  
tabindex or document order
     - CTRL-TAB key moves between yr/month/day regions of the popup, in  
that order
     - ESC key dismisses the popup and reverts the value to the value it  
had before popup invocation.
     - ENTER key dismisses the popup using the current date settings.
     - Year has focus: UP/DOWN = next/previous year. LEFT/RIGHT = no effect
     - Month has focus: UP/DOWN = next/previous month. LEFT/RIGHT = no  
effect
     - Day has focus: RIGHT/LEFT/UP/DOWN = navigate on day grid
     - Ex. Case: Month field has focus, value=December, UP key= increase  
year by 1, set month to Jan, set day focus to 1. Month field still has  
focus
     - Ex. Case: Month field has focus, value=July, Day=31, UP key=  
increase month field by 1 (August), set day field to 1st.

5. datalist interaction
-----------------
- If the date widget points to a valid datalist element, manually entered  
numeric values will only succeed in submission if they match an associated  
option element value.
- Input type=date widgets pointing to valid datalist elements should  
behave normally with the following exceptions: all days in the current  
date popup display that are not part of the datalist options are not  
selectable (disabled), and are grayed out.

6. Issues
-----------------
- Look/Feel: Should popup have a "Current date" button?
- Look/Feel: Should popup have a "Reset" button?
- Look/Feel: This widget should probably be used for  
type=datetime/datetime-local/date/year/month/week types. In type=date, the  
week portion is disabled/grayed. In type=year/month/week, all but the  
respective sections are disabled/grayed.
- Look/Feel: Internationalization - would current LtR, Top to bottom  
layout be the best flow in all languages/cultures? Would this be  
changeable?
- Look/Feel: CSS - Should it only affect the basic widget itself, or  
should it be able to affect the popup widget as well?
- Look/Feel: How should datalist entries be visually differentiated from  
regular type=date entries?
- Error/Boundary conditions: How to enable controls in response to min/max  
values?
- Error/Boundary conditions: How should the popup widget and navigation  
controls obey any STEP attribute that is present?
- Key: When generating the date chooser popup, what hotkeys should invoke  
it? Is ENTER and/or DOWN arrow ok?
- Look/Feel: How should step=any be handled graphically? As if the step  
attribute didn't exist? Isn't step=any the same as step=""?
- Look/Feel: Month value could be either numeric or named. If named,  
values should definitely obey the user's language strings/settings.
- Look/Feel: Perhaps day values that don't obey the min/max/step attribute  
could be disabled, or day values that do obey these values could have an  
alternate color.


-Brian

-- 
Brian Wilson
Opera Core QA