[whatwg] Something for the end-user??

[Dean Edwards]

Ian Hickson wrote:
> On Thu, 10 Jun 2004, Dean Edwards wrote:
> 
>>whilst we're talking about numbers...
>>a common scenario in web apps is to have a separate format for
>>displaying numbers (e.g. currencies). The user enters "19" but after
>>tabbing to the next field this is then displayed as "$19.00". focus/blur
>>events are usually used to format/unformat the underlying value. is it
>>too late to formalise something like this by introducing a "format"
>>attribute? i could have really used it on the last project i worked on.
> 
> 
> We could do that; could you propose some text? I'm not familiar with the
> requirements.
> 
> Would it just be:
> 
>    format="$%02.2d"
> 
> ...? Where that's basically a subset of the printf format specifier
> functionality?
> 

ian,

you seem to agree with this in principle (good!) but we've had no 
feedback on formatting patterns. :-(

i'm responding to this *again* because it seems to have been overlooked.
so here is a summary of why i feel we need a "format" attribute.

a "format" attribute is complimentary to the "pattern" attribute. this 
spec admirably covers form submission and validation but very little 
about the way data is displayed.
formatted data provides the end-user with a degree of instant 
validation. this can be gratifying when entering forms data (dates for 
example). if we are looking to encapsulate common javascript algorithms 
into the UA then this should be a definite candidate.

numbers
--------
because javascript/ecmascript only respects US/english style numbers it 
is unreasonable to ask the spec to allow/validate european style numbers 
(e.g. 1.000.000,00) but it should at least provide a mechanism for 
displaying numbers in this format (it's only polite).

dates
-----
i don't want my english style date converted to a US style date when 
submitted to the server (especially if i'm booking a plane). after 
tabbing out of a date field, if my date entry is formatted (e.g. 30 Jul 
2004) then i *know* i've entered the right information.

currencies
----------
a large proportion of forms data is about money (true). again the 
feedback thing: is "50", fifty dollars or fifty cents? data formatting 
provides immediate feedback.
i also humbly suggest adding another input type - "currency". without a 
format attribute this is meaningless. it's just a number. however, with 
a format attribute it becomes a more meaningful (and ubiquitous) kind of 
number. if the models for web apps are amazon and paypal then they may 
be interested in a "currency" input type (with appropriate formatting to 
the locale). if we don't have a new input type then perhaps a named 
format "currency" will suffice.

[quote]
The submission format is not intended to be the format seen and used by 
users. UAs may use whatever format and UI is appropriate for user 
interaction; the description above is simply the submission format.
[/quote]

this is a real nuisance in web applications because there is currently 
no way to separate the presentation and content of forms data. this 
issue needs to be addressed. a lot of javascript code is wasted on 
formatting data for the end-user, which on submission, is then 
"unformatted" for the server. some servers are just to darn lazy to do 
it for you...

further, i suggest that this attribute ("format" for now) be applied to 
the output element. use case:

<input type="number" name="cost" format="$%02.2d"/>
<input type="number" name="amount" format="%d"/> // :-)
<input type="number" name="total" format="$%02.2d"/>

i'd appreciate some feedback this time round. so, web-developers out 
there, if you are reading this then you can save yourselves a lot of 
time by responding positively to this post!

now can someone suggest some suitable date and number formatting 
patterns please?

-dean