[whatwg] Date/time field types - min, max, popup UI.

[Sigurd Magnusson]

Aryeh, ok, thanks for clarifying that. I also note now that http://www.whatwg.org/specs/web-apps/current-work/#date-state 
  shows max and min can be written as date strings. Phew about that.  
But I'm glad you agree with the UI. I also don't think that the 'blank  
text box with a calendar icon to the right' is the most optimal way of  
asking the normal human being to choose a date -- except where this  
question is on a compact form, or where the question is optional or  
unimportant and so shouldn't dominate the web page.

I feel this textbox with icon UI has arisen based on the limited time  
available to most website developers and the fact that developers  
wished to use a text input to ensure the data is part of a standard  
GET/POST submission.

Sig

On 8/09/2009, at 11:44 AM, Aryeh Gregor wrote:

> On Mon, Sep 7, 2009 at 6:45 PM, Anne van Kesteren <annevk at opera.com>  
> wrote:
>> On Tue, 08 Sep 2009 00:40:02 +0200, Sigurd Magnusson
>> <sigurd at silverstripe.com> wrote:
>>>
>>> In looking at the HTML 5, I have noticed an opportunity to provide
>>> additional elements to support date and time field types. (Or, if  
>>> I am
>>> mistaken, it may simply be an opportunity to improve documentation  
>>> of an
>>> existing feature).
>>>
>>> Whereas most field types have a Min and Max attribute, this does not
>>> appear to be true of date/time fields.
>>
>> What makes you think they do not apply there?
>
> They do, according to this handy-dandy chart:
>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#input-type-attr-summary
>
> The UI question is more vexing.  Like a lot of features in HTML 5, how
> useful these features will be to authors looks like it will depend a
> lot on how consistently good the UI is that browsers implement.  If
> even one major browser has bad UI, or if the UIs prove to be
> inflexible, that might kill a lot of the interest that many authors
> have in using the new input types.
>