[whatwg] Input type=date UI discussion

[Dean Edwards]

Hi Brian,

We are currently going through the same pains as you are in designing UI
widgets, particularly date/time widgets.

Before I add to your comments below, I'd like to add one important
consideration:

** The Platform is Important **

We are taking this into serious consideration when building an IE
implementation. Where possible we are trying to replicate the look and
feel of Windows. All of the widgets referenced by the WHATWG specs
already exist on many platforms. Windows already has date and time
controls as well as sliders and spinners for ranges and numbers.

We took the decision, that where possible, we would just copy Windows
look and feel. The only exception to this is the the date/time combo
control which we are still undecided about.

That said, consistency is important and we have the opportunity to raise
the level of web standards above the level of UI platforms if we
collaborate on a consistent look and feel. I am open to discussion on
this but would welcome the forming of some sort of group to focus on
these issues. A mailing list for implementers would be good. Can we set
that up?

Now to my comments. If I haven't commented it means I agree with what
you say. So basically this is a list of disagreements. :-)

Brian Wilson wrote:
> 
> 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.

Why is the icon on the left? We've gone for straightforward combobox
look and feel. An icon doesn't scale as well as a tiny arrow so there is
a limit to how small the input box can be before the icon is illegible.

> - The popup date selector should have a solid or beveled frame border  
> around it to differentiate from surrounding content.

We've gone solid ala Windows.

> - 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 =)

We have a minimum width but no other restrictions. The height is
dependent on the font and other display properties. It is big enough to
hold a month view without scrolling. Our popup widgets will not be
scrollable.

> - 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.

We are using IE's createPopup method. This allows Windows to manage the
position and placement of the popup window according to the active element.

> - 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.

We don't display them. Should we?

> - 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.

This doesn't apply to us as we don't show these days.

> - Date widget appearance: Once the date chooser popup widget has been  
> dismissed, the date in its correct localized format will be displayed 

I agree but localisation is hard for us. I'm not sure how we are doing 
that yet. Olav?

> in  the input date widget. This value is not free-form editable.

I disagree quite strongly with this. If we want to enable developers to
build web applications then rapid data-entry is a must. I'd like to try
to validate keyboard entry.

> - 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.

I want to avoid anything in popup windows having focus.

> - Display format for the field does not match submittal format...what  
> should it be?

What do you mean?

> - Should the left-most day of the week be Sunday or Monday? Is this a  
> localization issue?

I think it is.

> - 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).
> 

We had this originally. The conclusion was that it added clutter. Our
implementation allows keyboard entry so you can delete text to clear.
"Current" was deemed to be 50% useless as most dates are future dates.

> 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).

Is this covered in the spec? If not, it needs clarification.

> - 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.
> 

As per my previous response.

> 3. Event Handlers and the DOM
> -----------------
> - Input: Fires every time a value is changed in the year, month or day 
> in  the popup.

mmm.

> 4. User Input
> -----------------
> 4.1 Pointing Device Actions
>   - Clicking anywhere on the widget generates the date chooser popup.

Ours is modelled on a standard Windows combobox. You can type in text 
and you can use the dropdown mechanism for the date picker.

>   - Clicking outside the calendar popup dismisses the popup and uses 
> the  current values in the popup as the new date value.

ditto.

>   - 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.
> 

We will probably disallow the selection of invalid dates. Probably grey 
out the dates that are out of step or out of range.

> 4.2 Key actions
>   - ENTER: Invokes the date chooser popup

This clashes with submit. We probaly won't do this. If the popup is 
visible then it counts as select.

>   - DOWN arrow: Invokes the date chooser popup

Yes.

>   - Key actions within the date chooser popup
>     - Popup initial focus: Year field.

We won't have focusable components in popups.

>     - CTRL-TAB key moves between yr/month/day regions of the popup, in  
> that order

interesting. what about page up/down. Erik Arvidsson has coded some 
pretty complex keyboard behavior for some of our widgets. Erik?

>     - ESC key dismisses the popup and reverts the value to the value it  
> had before popup invocation.

Yep.

>     - ENTER key dismisses the popup using the current date settings.

Yep.

>     - 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

Erik?

> 
> 5. datalist interaction
> -----------------
> - 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.

We will probably revert to a standard pick list (dropdown) for this 
scenario.

> 
> 6. Issues
> -----------------
> - Look/Feel: Should popup have a "Current date" button?
> - Look/Feel: Should popup have a "Reset" button?

Clutter we decided but it may fit in better with the design you have.

> - 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.

We are displaying year and month as spinners, date and week as calendar 
style popups and are undecided about datetime controls.

> - Look/Feel: Internationalization - would current LtR, Top to bottom  
> layout be the best flow in all languages/cultures? Would this be  
> changeable?

What side is th dropdown button on in Japan? Seriously, I want to know. :-)

> - Look/Feel: CSS - Should it only affect the basic widget itself, or  
> should it be able to affect the popup widget as well?

Our popups currently inherit the following CSS from the parent <input>:

font-size
font-*
font-family (undecided but probably)
color
background-color

This is the way that <select> boxes currently work on most platforms.

> - Look/Feel: How should datalist entries be visually differentiated 
> from  regular type=date entries?

We make no distinction visually but I like the idea.

> - Error/Boundary conditions: How to enable controls in response to 
> min/max  values?

beep? ;-)

> - Error/Boundary conditions: How should the popup widget and navigation  
> controls obey any STEP attribute that is present?

What do you mean? We will grey out any dates that are not in step.

> - Key: When generating the date chooser popup, what hotkeys should 
> invoke  it? Is ENTER and/or DOWN arrow ok?

DOWN arrow definitely. Enter usually submits a form.

> - 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.
> 

Yeah. I think they should be disabled.

Phew!

I think we should also collaborate about this offline too. What do you 
think?

-dean