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

[Ian Hickson]

On Wed, 29 Jul 2009, Garrett Smith 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?
> 
> 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

Your understanding is correct, it is a convenience API.


On Thu, 30 Jul 2009, Garrett Smith wrote:
> 
> 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.

I agree that a whole library would be out of place, but a single attribute 
to obtain Dates where relevant seems like the right balance to strike.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'