- From: Dean Edwards <dean@edwards.name>
- Date: Sat, 19 Jun 2004 02:29:35 +0100
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
Received on Friday, 18 June 2004 18:29:35 UTC