[whatwg] HTMLInputElement, "date" State, and Complexity

On Thu, Jul 30, 2009 at 6:10 AM, Tab Atkins Jr.<jackalmage at gmail.com> wrote:
> On Thu, Jul 30, 2009 at 12:54 AM, Garrett Smith<dhtmlkitchen at gmail.com> wrote:
>> HTML 5 defines input type="date" as an input state. This is
>> implemented in at least one userAgent (Opera). Which other browsers
>> have implemented that?
>
> No one else, in their public releases. ?I don't keep track of
> nightlies much, so I'm not sure if anyone has the functionality
> sitting there waiting to be included.
>
>> It seems like the added value to the programmer for valueAsDate
>> appears to be convenience method to format to/parse from ISO 8601, but
>> place on input as a behavior property, and working only when the input
>> is in the "date" state. For setting[1], the convenience appears to be
>> to set a date value when the Date's [[value]] is "valid", although a
>> "valid" date does not seem to be mentioned, much less clearly defined,
>> and the reference links to [GREGORIAN] are broken[1].
>>
>> I can't see much other reason for having valueAsDate. Am I missing something?
>>
>> [1]http://www.whatwg.org/specs/web-apps/current-work/#valid-date-string
>
> Do you need much more reason than that it lets you conveniently
> convert between the date string and a Date?
>

Yes, I think more reason is needed. I did not see a definition of a
Date in HTML 5 but it seems out of place.

A utility method to convert between string and the (not defined) Date
is out of place for HTML.  valueAsDate is a utility method.

valueAsDate adds complexity. It is out of place. It doesn't add much
value. Developers will still need a fallback.

Methods for formatting Date/parsing string don't belong on HTMLInputElement.

> ~TJ
>

Received on Thursday, 30 July 2009 09:10:12 UTC