[whatwg] <output> and onforminput
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
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
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
> 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
measures to ensure that this setting is correct - so the work should be
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.
More information about the whatwg