- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 1 Sep 2004 13:46:30 +0000 (UTC)
The various proposals for data formatting basically boiled down to two
requests:
1. That there be a way to take the value entered in a form control, and
format it specially when the form control doesn't have focus, in
particular to handle number fields which may need to be thousands-
separated or have a currency symbol introduced,
2. That there be a way to format data (times and dates, numbers) such
that it can be placed into markup in raw form and reformatted on the
fly in a similar way.
On Sat, 19 Jun 2004, Dean Edwards wrote:
>
> 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.
In the case of WF2, that's intentional, since implementors need to give us
feedback on what issues they run into with making the controls work.
> 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).
For number fields, it would seem likely that the UA would just do that
automatically, we shouldn't have to say anything about it.
> 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.
Same with dates, IMHO.
> 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.
Since money is just a number, I would be more comfortable with:
<input type="number" currency="...">
...or similar. This also has the advantage that we can introduce it in WF3
and WF2 UAs will still be compatible with it.
> [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...
Well, the idea is that the _UA_ would do the reformatting automatically.
For most types, it can. It's only really currencies (of the ones mentioned
so far, anyway) that have special formatting rules that the UA can't
guess.
On Sat, 19 Jun 2004, Malcolm Rowe wrote:
>
> What happens if the user's currency format has a suffixed currency
> symbol, or if the locale-aware way to represent currency values isn't 'a
> decimal point followed by two decimal places'?
Well, currencies can't just be naively localised, because you never know
what currency you might be actually dealing with.
> If we're going to do this at all, wouldn't we want named formats, like
> 'format="currency"' or 'format="short date"'?
For <output>, the latter might make sense; the former IMHO wouldn't.
On Sat, 19 Jun 2004, Matthew Thomas wrote:
>
> For dates, I suggest "short", "long", and "longwithday". [...]
> ["number"]
Agreed.
> OSes also have settings for displaying currency, but I think these would
> be inappropriate for Web use, because Web sites are often referring to
> currencies other than the user's local one.
Agreed.
> And prefixing or affixing currency symbols hardly needs help from
> special Web Forms markup.
How would you do it? Assuming you want the currency symbol to appear in
the text box?
On Sat, 19 Jun 2004, Doron Rosenberg wrote:
>
> While it makes sense to use the OS settings, a way to override them is
> probably still needed. Amazon.com wants to calculate in dollars, even
> if you are coming from germany.
Right. For currencies, it makes sense.
On Sun, 20 Jun 2004, Matthew Thomas wrote:
> On 20 Jun, 2004, at 12:28 PM, Doron Rosenberg wrote:
> >
> > I can play devil's advocate and use mapquest - it wants to display 1.2
> > miles, not 1,2 miles.
>
> Nonsense. MapQuest have just hard-coded it that way (even when my
> browser language is set to French and I'm asking for driving directions
> from Paris to Lyon) because doing the right thing is too much bother.
I wouldn't say it was "nonsense" -- who knows what MapQuest want. But
yeah, I agree that as a user I would want it to use my locale settings.
On Tue, 29 Jun 2004, Pete Harlow wrote:
>
> I am filling in a form on a UK web site. I live in France. How do I fill
> in the phone number, and how is it validated? First try - +33 etc. The
> non numeric character is thrown out. Second try - not enough digits in
> the raw French number. Leave blank - no good, mandatory field.
Since WF2 has no specific telephone field, that would be up to the server.
> Dates in Europe are often written 2004-06-29, but not always, but never
> the US way.
In WF2 your UA would pick the locale format.
> If that doesn't break the validation, the accented characters in my
> address will.
WF2 supports that without any problems, in theory.
> And so on. Where does the zip/post code go?
Again, not a WF2 problem as far as I can see.
> What would you deduce from the lang attribute of this mail??
I think the localisation should use the OS settings, not the language of
anything.
> Most of these problems can be avoided if the form and the validation
> code it runs are carefully designed, but frequently the points above are
> not considered, and may be quite obscure to a web designer in one
> culture designing a form that will be used in others. It is a tall
> order, but I wonder if a structure can be devised that will assist a
> form designer in taking these aspects into account?
I don't really see how we can make it better. :-)
Suggestions are welcome of course.
On Thu, 1 Jul 2004, Martin Kutschker wrote:
>
> But WC1 is not in a very good shape right now. I hope it's getting
> somewhere when WF2 is ready.
I don't expect to start work on WC1 for a _long_ time.
> CSS-property "date-format:"
>
> inherit | short | medium | long
>
> Display a date in short, medium or long manner according to the UAs locale.
I hesitate to call this stylistic, to be honest. Even without stylesheets,
you're still going to want dates, times, etc, to be localised.
On Thu, 1 Jul 2004, Martin Kutschker wrote:
> Martin Kutschker writes:
> >
> > CSS-property "date-style" (or "calendar-type"):
> >
> > inherit | sun | moon | hebrew | japanese | <...>
>
> Better would be:
>
> inherit | gregorian | hebrew | muslim | japanese | <...>
I really know nothing about alternate calendars. If we're to add stuff
like this, IMHO we can only really do it with input from people who use
such systems on a daily basis online.
On Thu, 8 Jul 2004, Dean Edwards wrote:
>
> ...a date picker will quite likely do this by default. a better example
> is the formatting of numbers/currencies.
>
> a user enters this in a number field:
> ---------------
> |500000 |
> ---------------
>
> after tabbing out the number gets formatted like this for a french user:
> ---------------
> |500.000,00 |
> ---------------
>
> it gets formatted like this for a UK user:
> ---------------
> |500,000.00 |
> ---------------
I think number fields could be expected to do this natively too.
On Tue, 13 Jul 2004, fantasai wrote:
>
> For numbers, you'd just want to either append or prepend a unit
> identifier.
Some systems are more complex (resistance notation, e.g.).
On Tue, 13 Jul 2004, Pete Harlow wrote:
> >
> > <p>The boat trip will be on
> > <date format="compact">2005-12-04</date>.</p>
> >
> > <p>The boat trip will be on
> > <date format="compact" iso="2005-12-04">04/12/05</date>.</p>
>
> I take it the content between <date> and </date> is for legacy UIs otherwise
> <p>
> <date format="compact" iso="2005-12-04" />
> </p>
> would be cleaner...
I presume we could say that if the iso attribute is omitted, it takes the
value from the contents of the element.
On Tue, 13 Jul 2004, Matthew Raymond wrote:
>
> <p>The boat trip will be on <date>2005-04-12</date>.</p>
>
> The contents of <date> would be in ISO 8601. If the browser doesn't
> recognize <date>, it will simply be ignored and the ISO 8601 date will be
> displayed. UAs that support <date> could implement it in such a way that
> Outlook, Sunbird or some other calendar program would open when the date is
> clicked. (Could go even further with this, but I'd like to see how the
> suggestion is received in its current form.)
That seems reasonable to me.
So my conclusion is we should wait for WF3, but then:
* Add something to type="number" to support basic currency and unit
formatting of input
* Add something like <date>, <time>, and <number> so that dates, times,
and numbers can be auto-formatted.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 1 September 2004 06:46:30 UTC