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

Olav Junker Kj?r wrote:
> Matthew Raymond wrote:
> 
>>   I think we should introduce to WF2 a new element called <format> that 
>>would contain the formatting hint text. This element would be rendered 
>>in legacy user agents as text, but in WF2 user agents, its contents 
>>would be used in a far more intelligent manner. Take this example, for 
>>instance:
>>
>>| <label>Start Date <format>(MM/DD/YYYY)</format>:
>>| <input type="date" id="startdate"/></label>
> 
> I dont think you can use the same string as human readable hint and as 
> machine processable format. For example, the hint will need to be 
> localized for different languages. So the actual format string should 
> probably be an attribute.

    Well, how about giving an attribute, such as |value|, that will be 
processed according to a specific set of rules. At the same time, only 
the child contents of the <format> element will be the only content that 
the user agent should render. If the |value| attribute is not defined, 
ISO8601 is used. Therefore, example above would have to be rewritten as 
the following:

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

    This would mean that, for a server that only parses ISO8601 dates, 
you'd use this:

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

    We could make |value| default to the contents of <format> when not 
defined. The problem with that, though, is that we'd have to define very 
strict rules about how the formatting string is parsed when the child 
content is used.

>>   Some webmasters, however, may want everyone to enter the date in the 
>>exact same format, for the sake of consistency (which would be useful to 
>>simplify employee training, for instance). This can be accomplished by 
>>assigning the value "entry" to the |applyon| attribute:
> 
> This defeats the idea that the datetime control should be localized and 
> feel native. Many platform datetime selectors allows the use to select 
> the date from a calendar and displays it formatted something like 
> "Saturday, January 22, 2005" in the users language. By constraining the 
> date control to follow a simple format string, a lot of UI power is 
> lost.

    If you're referring to controls being of such a nature that they 
_can't_ display the date in a specific format, then we can simply make 
the <format> element "where applicable".

    I presume, though, that you're talking about the possibility of 
webmasters intentionally using applyon="entry" as a means of forcing a 
specific format on WF2 browsers. In that case it becomes an issue of 
consistency of interface across WF2 and legacy user agents versus 
presentational abuse.

    If you assume consistency of interface isn't worth it, then I 
suppose we could do away with |applyon| entirely, and simply state that 
if |value| is defined, the format it defines should always be used for 
submission. The question is whether or not there's a reason webmasters 
would prefer ISO8601 be sent rather than the fallback format for legacy 
user agents.

> (Btw. the point of hiding the hint for WF2 compliant browsers is 
> lost if WF2 users should enter data in the exact same format.)

    I intentionally tried to avoid specifying what the user agent should 
or shouldn't render, although I definitely wanted to imply hiding under 
certain circumstances. If the format matches the native format, 
obviously the UA has the option of not rendering the hint.

Received on Saturday, 22 January 2005 21:27:26 UTC