- From: Malcolm Rowe <malcolm-what@farside.org.uk>
- Date: Tue, 20 Jul 2004 11:59:37 +0100
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