[whatwg] input element types

[Ian Hickson]

On Wed, 16 Jun 2004, Jim Ley wrote:
>>>
>>> With dates and times why the restriction on UTC?
>>
>> Only with the "datetime" type is there that restriction; it is intended
>> specifically to cater for the situations where a time-zone-defined time
>> is needed.
>
> Right, so not much use at all really then, seen as we generally have
> timezone dependant dates for almost all internet use.

Oh I wouldn't say that. Most of the time when I enter a time it is not a
timezone-independent time. For example if I want to search for all
messages sent before 2pm this afternoon, the server will need to know what
I meant by "2pm this afternoon".


> I want to know when my train arrives in London if I leave today.  Seen
> as we can't have the legacy clients deal with the timezone issues, and
> we add a dependance on the client knowing the UTC offset of the user I
> think it's all rather over-specified and un-implementable.

Since ECMA262 already requires this, I don't see the problem.


>>> [flight example]
>> Indeed. For this use, the "time" type is available.
>
> So we cannot use the datetime control for travel sites?  Rather
> inconvenient is it not?

Not really. Travel sites rarely ask for a specific time, they generally
ask for a specific date and then a very vague time ("Afternoon", for
instance).


>> Truncated representations don't seem like they would require much in
>> the parser. You just set anything you haven't read yet to zero.
>
> You seem to be mis-remembering ISO 8601, the truncated representations
> don't default to 0.

Oops. Ok, I've changed the way it is defined. There is now a strict format
to be used, defined in the spec.


>>> week: one of the more popular uses of weeks in the UK is the tax week,
>>> this of course doesn't work as an ISO8601 week, could the week widget
>>> be generalised so it can be used for these other definitions of week?
>>
>> Possibly; how would you do it? (I don't know enough about the UK Tax
>> week to know exactly what needs generalising.)
>
> The date that is week 1.

With ISO weeks there is no single date this is week 1, it's defined in
terms of the first thursday of the year, IIRC.

Also, that would require one date per year in the range of the control,
which is a problem since the default range is unlimited.

So I'm not sure how to do this. Suggestions welcome.


>>> Why are +0 etc. invalid?  The MUST restriction on the UA to not submit
>>> numbers in invalid formats is required why, surely SHOULD is more
>>> appropriate?
>>
>> It has to be "MUST" so that servers are guarenteed to always be able to
>> parse the result. Why would it be "SHOULD"?
>
> Because of the over-validation suggestions I've talked about before on
> the list, servers cannot rely on the format being returned, since
> servers cannot rely on a Web Forms 2.0 client.

Sure, but if they do have a Web Forms client, why should they have to deal
with multiple formattings?

What's the advantage of decreasing interoperability here?


>>> Will there be any methods for a form requesting values not directly
>>> representable in your required submission format (such as 1/3)?
>>
>> Not in this version, but what did you have in mind?
>
> A method for requesting numbers not representable in your format...  as
> to how it might look, I have no idea yet, I've not really thought about
> it.

Please send a proposal (with use cases of course), I'll add it to the Web
Forms 3.0 list.


>> Yeah. I've dropped "tel" for now.
>
> Good, 1 down, how many more features do I have left?

I don't know, how many others do you want removed?

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