[whatwg] HTMLInputElement, "date" State, and Complexity
dhtmlkitchen at gmail.com
Thu Jul 30 09:10:12 PDT 2009
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, 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.
>> I can't see much other reason for having valueAsDate. Am I missing something?
> 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.
More information about the whatwg