- From: Brian Wilson <brian@opera.com>
- Date: Tue, 12 Jul 2005 16:35:36 +0200
[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
Received on Tuesday, 12 July 2005 07:35:36 UTC