[whatwg] <output> and onforminput
Christian Schmidt
whatwg.org at chsc.dk
Thu Jul 1 03:07:00 PDT 2004
Jim Ley wrote:
> So you break all caching, you ensure that WF2 forms have to be
> submitted in the same "session" as they are downloaded (I can't
> download a form last week, and submit it today, as my clock's likely
> to have changed) and you can't deliver forms by email, from CD etc.
> for submission to the web.
It wasn't meant as a requirement, but as a suggestion to how UA's could
help users detect inaccurate clocks. The UA may choose not to use it at
all or only when it has reason to believe that the users clock is
inaccurate.
If the user has recently verified that current setting, or if the OS has
recently synchronized the clock with an NTP server, the detection could
omitted.
It also wasn't meant as a silver bullet to solve all inaccurate clock
problems one could imagine, but I think that it would be helpful in most
common scenarios.
> It certainly seems an awful lot of work when I failed to see anyone
> have a problem with this on the web today.
Even if a website doesn't allow the user to enter datetimes, it would
often be appropriate to display times in the user's local timezone (e.g.
on a news site). The user would either have to specify the timezone
somewhere in the web application, or the timezone should be read from
the UA using Javascript. In either case the application should take
measures to ensure that this setting is correct - so the work should be
done anyway.
The problem does exist on the web today. If your clock is properly
configured, you probably wont notice it, though. Slashdot allows you to
specify your timezone. I don't think eBay does - that's confusing,
because absolute time is relevant with respect to when an auction ends.
Clock inaccuracies is not a problem specific to Web Forms, but a general
problem for many webpages. I don't know if that makes it outside the
scope of the Web Forms specification to help solve this problem.
Christian
More information about the whatwg
mailing list