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

[whatwg] Proposal: datesubmissionformat

From: Malcolm Rowe <malcolm-what@farside.org.uk>
Date: Tue, 20 Jul 2004 11:59:37 +0100
Message-ID: <courier.40FCFB19.00004376@mail.farside.org.uk>
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 Tuesday, 20 July 2004 03:59:37 UTC

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