W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2009

[whatwg] Week Strings

From: Smylers <Smylers@stripey.com>
Date: Fri, 19 Jun 2009 10:48:17 +0100
Message-ID: <20090619094817.GA1943@stripey.com>
For <input type=week> elements the spec requires:

  The value attribute, if specified, must have a value that is a valid
  week string.

    -- http://www.whatwg.org/html5#week-state

But the spec's HTML source contains this comment immediately afterwards:

  <!-- ok to set out-of-range value, we never know when we might have to
  represent bogus input -->

Does that comment mean that the above requirement will be changed to
something along the lines of "must have a value that is a syntactically
valid week string but may represent a week that doesn't actually exist"?
That is, the author can seed a browser's week-picker control to a value
which the browser must not submit back to the server?

In general determining that something is a valid week string requires
knowing which day of the week the year in question begins on.  For
example "2009-W53" is a valid week string (because 2009 began on a
Thursday) but "2010-W53" isn't (because 2010 will begin on a Friday).
Browsers will need to do this to know whether they can submit a week

The spec doesn't appear to provide an algorithm for determining which
day of the week a year begins on (however I am not a browser developer;
possibly this is sufficiently straightforward that those who are don't
need it spelling out).

Currently Validator.nu accepts this:

  <input type=week value=2010-W53>

but not this:

  <input type=week value=2010-W54>

If out-of-range week values are to be permitted in <input> elements then
a validator should permit both of them.  Conversely if they aren't
permitted then it should accept neither of them (and therefore have to
implement a 'which day is January 1st' algorithm, which I'm guessing it
currently doesn't).

Received on Friday, 19 June 2009 02:48:17 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:13 UTC