W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2004

[whatwg] Proposal: datesubmissionformat (repost)

From: Malcolm Rowe <malcolm-what@farside.org.uk>
Date: Wed, 21 Jul 2004 17:27:08 +0100
Message-ID: <40FE995C.2040204@farside.org.uk>
[I seriously need to improve my web-based email client. I'm reposting 
this using Thunderbird, and hopefully this time it will actually be 
readable.]

Hello list,

I'd like to propose an additional feature for Web Forms 2, namely the 
ability for the author to control - to a limited extent - the submission 
format of an <input type=date> control. This isn't entirely a novel 
idea; both Jim and Matthew have touched on it before me.

What's the use case for this feature? Just one: For sites that have 
already deployed a form that accepts dates, this feature would allow 
them to provide enhanced support for WF2-compliant UAs with minimal work.

Take the following site as an example:
http://www.lets-go-travel.net/?q=enquiry/new
[chosen because it has a simple input form and no client-side scripting, 
and because it has a short, quotable, URL.]

Ignoring the (fairly horrible) site design and misuse of (X)HTML, the 
relevant code boils down to this:

Date:
<input type="text" maxlength="10" name="edit[visit_date]" size="8" value="">
Enter date of visit as dd/mm/yyyy

As I mentioned above, this particular page has no client-side validation 
at all. Therefore, this page can be trivially changed for WF2 UAs as 
follows:

Date:
<input type="date" maxlength="10" name="edit[visit_date]" size="8" value="">
Enter date of visit as dd/mm/yyyy

(The 'size' and 'maxlength' attributes are invalid for WF2 type="date" 
controls, and will be ignored by compliant UAs, but will be respected by 
legacy UAs that do not understand type="date").

However, the obvious problem with this solution is that the submitted 
value will be in the format 'dd/mm/yyyy' for pre-WF2 UAs, and 
'yyyy-mm-dd' for WF2 UAs.[1]

So, what can the site author do? In my mind, they could do one of three 
things:

* They could change to <input type=date>, and change the server-side 
processing to allow either type of date to be provided.

* They could change to <input type=date>, and add client-side scripting 
to convert one value into another (and probably provide some client-side 
validation for non-WF2 UAs at the same time).

* They could do nothing, and leave the page as-is.

I think that, for many of the smaller, 'non-professional' sites, the 
last choice will be the most common.

What I'm proposing would be an additional attribute that allows 
submission to be carried out using one of several common named formats. 
The above example could then be re-written as follows:

Date:
<input type="date" datesubmissionformat="d/m/y" maxlength="10"
name="edit[visit_date]" size="8" value="">
Enter date of visit as dd/mm/yyyy

These two changes (type="date", datesubmissionformat=...) are all that 
is necessary to provide an enhanced user experience for WF2 clients, and 
require only minor changes to the HTML source, and no changes at all to 
the form processor.

Critically, I am not proposing a general-purpose format specifier; the 
allowed values for this attribute would be drawn from a short list of 
'common' date formats. The ones I had in mind were "iso" (for ISO8601, 
the default, yyyy-mm-dd), "d/m/y" (UK format, dd/mm/yyyy), "m/d/y" (US 
format, mm/dd/yyyy), and probably a 'European' format "d.m.y" (dd.mm.yyyy).

The reason for suggesting named formats rather than a format specifier 
is primarily simplicity (for both page authors and UA authors), but also 
because I don't think it's necessary. This feature is intended to assist 
the easy enhancement of existing pages, and not as a general-purpose way 
to control the format that the UA submits; for new pages, ISO8601 should 
not present a problem.

For pages that do use client-side validation, there would also be one 
extra change: the validation would need to be switched off for 
WF2-compliant UAs.

Thoughts and comments welcome.

Regards,
Malcolm

[1] There is also the additional problem that the 'as dd/mm/yyyy' text 
is not appropriate for WF2 UAs, but this does not really relate to the 
topic of this post.

Notes:

* This feature would only affect the submission format, and not the 
value in the DOM. People using script are already able to detect a WF2 
UA, and would need to change their script to disable validation anyway, 
so I don't think that this would be a great hardship (and making this 
attribute affect the value in the DOM is likely to be significantly more 
complex than just changing the format used for submission).

* This feature is not useful for people who have developed custom
client-side date controls (multiple <select>s, etc). However, I think 
it's precisely the people who *don't* have the time to code custom 
controls or script who would need the most help in adopting WF2's features.

* This feature is not intended for new sites. If I were developing 
something from scratch, I would ensure that the server-side processing 
could handle dates in ISO format as well as my preferred format.

* This feature would only apply to <input type=date>, and not datetime,
time, month, or any other type. The reason for that is that I don't 
think that there's a consistent existing use of 'bare' input controls 
for those types, whereas there is such a use for 'date' types.

* The names of the formats aren't great; a more obvious list might be 
'iso', 'uk', 'us', 'europe', but I don't like the UK-/US-centricity of 
that list, and I don't like the implication that all of Europe uses the 
same format.

* The name of the attribute, 'datesubmissionformat' is not ideal - it's
quite long. I can't think of anything shorter that doesn't imply that 
it'd apply to other controls.

* The attribute only applies to one subset of controls, <input 
type=date>. In itself, that's not ideal (I'd prefer a more orthogonal 
approach). However, I don't want to get into the complexity of providing 
a general 'submission format' attribute.
Received on Wednesday, 21 July 2004 09:27:08 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:35 UTC