[whatwg] [Web Forms 2.0] Last minute suggestion - The <format> element.

[Ian Hickson]

Ok, I read through the <format> discussion. As far as I can tell there are 
multiple different proposals being mixed into one.

1. A proposal to control the submission format for WF2 UAs.

I disagree that this is desirable. The whole point of having a type is 
that it means we can all standardise on a single, reliable, unambiguous, 
easy to parse, standard submission format.

Having a single format means libraries can be written that can then just 
be used directly, instead of having to handle dates individually for each 
site as we do now.


2. A proposal to control the display format for WF2 UAs.

I agree that there might be some (rare) cases where you would want to 
override the UA's default rendering, but that is a presentation issue, and 
as such belongs in CSS or Web Controls 1.0, not Web Forms.


3. A proposal to display the format the server accepts, for pre-WF2 UAs.

This seems to be a reasonable request -- the question is how to do it.

The most common suggestion is an element that would not render in UAs that 
supported the new input controls but would in legacy UAs.

Unfortunately, this makes some assumptions that I'm not sure we can make. 
For example, it assumes that a UA either supports all of the new date/time 
input types as well as the <format> element, or it supports none of them. 
Given past experience with the way UAs implement specs a bit at a time, I 
really don't think this is a good assumption.

I also am not too happy about the idea of introducing an element purely 
for the purpose of hiding content from new UAs -- effectively deprecating 
the element straight away.


On Fri, 21 Jan 2005, Matthew Raymond wrote:
>> 
>>    http://whatwg.org/demos/date-01/
> 
> 1) It uses a page worth of Javascript to do the work of a single HTML tag.

Most of the JS was added at Jim's insistence, so as to degrade gracefully 
in UAs with two or three users. Also, the code takes care of the timezone 
problem (which <format> doesn't). It also handles hiding the format just 
for supported types so it works with incomplete WF2 UAs, and has graceful 
fallback in both WF2 and non-WF2 UAs when JS is disabled.

I can't really see how to achieve that with <format>.


> 2) It uses a fallback method of displaying formatting hints that forces 
> webmasters to learn Javascript, even when they may have little or no use 
> for it outside of the date/time formatting issue.

Not really, the code is generic and can be cut-and-pasted.


> 3) It requires that you add the ISO8601 date and time format to your 
> server's date/time parsing, regardless of whether you actually want 
> people to be able to submit data to the server in that format.

And <input type="file"> requires that you support multipart/form-data, and 
using the <select data=""> feature requires that you use a particular 
format, etc. I don't really see why that is a problem.


> 4) On legacy user agents with Javascript disabled or unavailable, it requires
> the user to delete the format hint when entering a new date.

In most UAs the current value is selected when you tab into a control, so 
that doesn't seem like a serious problem. Also, as you say, it's only an 
issue when JS is disabled.


> 5) On legacy systems, the user can still input ISO8601 dates and times 
> and have them validate on the server, in spite of the fact that the 
> dates and times aren't in the listed format. This may encourage some 
> users to use random date/time formats that the server doesn't support.

I don't follow this argument.

Also, the demo in question supports most formats, it isn't a big problem 
(and can be abstracted into a library).


> 6) It may increase the difficulty of training people to use certain web 
> apps within a corporation, because you must train them to use a 
> different date format on legacy and WF2 user agents.

The Web app can easily be written to use whatever format the WF2 UA uses 
as its legacy format.


> 7) If a company has a specific internal date/time format, and they want 
> that format used on all company web apps, they have to configure every 
> WF2 user agent in the company to use that date/time format, since the 
> <input type="datetime"> control doesn't provide a method of setting the 
> format the user must enter the date and time with.

A company that requires that all its employees have the exact same date 
and time settings for display purposes has much bigger problems.


> Number 3 is the worst part, in my opinion. You shouldn't have to add 
> parsing on the server just to get a date/time control in WF2 clients, 

You'll almost certainly have to anyway, since without type="date", etc, 
authors are more likely to use a number of <select>s than a single field. 
(That's part of the problem we are trying to solve.)


> and you shouldn't have to add Javascript to get a simple format hint on 
> legacy systems. This is overhead that the webmaster really shouldn't 
> have to deal with.

By supporting most formats automatically, like the demo does, I don't 
really see that there is a problem.


> | <label>Start Date: <format value="MM/DD/YYYY">(MM/DD/YYYY)</format>
> | <input type="date" id="startdate"/></label>

What if the attribute doesn't match the contents?
What if the UA doesn't support <format> but does support type="date"?
What if the user is not a native speaker of English and doesn't understand 
the format, but would understand it if the UA used a native datepicker? (I 
myself have been in this situation when using Norwegian sites.)
What if there are multiple <format> elements?


> One of my concerns with the <format> element as previously defined is 
> that if the users sees a localized version of the date and time in their 
> <input type="datetime"> controls, it may not match text dates and times 
> elsewhere on the page or website. As a result, there are only three 
> possible solutions:
> 
> 1) Force the date/time control to display the format of the <format> 
> element (applyon="entry").

I think this would lead to inconsistent and poor UI (as mentioned by Olav, 
I believe).


> 2) Preconfigure the settings of the user agents to display a specific 
> format in all date/time controls.

Obviously this is not under the control of the authors.


> 3) Require WF2 user agents to display dates and times in the text in a 
> localized format.

Yes, I agree that this is the best solution.



> | <p>
> |   The meeting is currently being held on <date>2005-1-30</date>
> |   at <time>11:00:00.0</time>.
> | </p>
> |
> | <form>
> | <label>New Meeting Date:
> | <input type="date" value="2005-01-30">
> | <format>Format: yyyy-mm-dd</format></label>
> |
> | <label>New Meeting Time:
> | <input type="time" value="11:00:00.0Z">
> | <format>Format: hh:mm</format></label>
> | </form>
> 
> Because the contents of <date> and <time> are already in ISO8601 format, no
> |value| attributes have to be specified. The format to submit is ISO8601 as
> well, so format doesn't require a |value| attribute.

The <format> elements above could also, IMHO, be replaced by <span> 
elements that are removed by JS in WF2 UAs, or by a more comprehensive 
solution like in the demo. However, I don't really see how inventing a 
whole new element just to have legacy UAs handled here is the way to go.

Effectively, <format> is the same as <nodateinput> (c.f. <noframe>). I've 
never been a fan of <noframe> (and <noscript>).


> | <form>
> | <label for="meetdate">New Meeting Date: </label>
> | <input type="date" id="meetdate" name="meetdate" value="2005-1-30">
> | <format for="meetdate" min="2005-01-25" max="2006-01-30"
> | value="%m/%d/%Y">
> |   Format: mm/dd/yyyy
> | </format>

This just seems way over the top, especially given that the only real 
reason to have it at all is for legacy UAs.

At the end of the day, while backwards compatibility is key, there is a 
limit to exactly how many of the new features we add should be designed 
specifically to overcome migration issues.


> Also note that I'm changing my definition of <format> so that the child 
> contents are purely a fallback for legacy clients. Why? Well look at 
> this example:
> 
> | <label for="date1">Departing:<br></label>
> | <input id="date1" name="date1" value="mm/dd/yy">
> | <format for="date1" min="now" value="%m/%d/%Y">
> | <input src="/eta/calendar.gif" name="cbtn1" alt="View Calendar"
> | type="image">
> | </format>
> 
> The above is a modified version of the markup Expedia.com uses for date
> entry for Mozilla Firefox in the "flights" tab. Because <input name="cbtn1">
> is unnecessary on a WF2 user agent, the element has been made a child of
> <format> so that it will not be rendered. A similar solution, with the help of
> some Javascript, could probably be used to create three <select> elements in
> fallback rather than an <input type="text">. I'm working on an idea for how to
> make this possible without Javascript. Feel free to post comments.

This has all the problems that I had raised when similar ideas where put 
forward for how to have <input type="date"> fallback on something other 
than a text box.


> For people who want specific date formats displayed, perhaps we need
> special CSS properties for this purpose. Perhaps something like this:
> 
>    date, input[type=date] { format-date: "%m/%d/%Y" }

It's quite likely that the CSS working group will do something like this.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'