Re: [suggestion] Another field type for HTML form inputs

On Thu, 16 May 2013 08:28:07 +0400, Silvia Pfeiffer
<silviapfeiffer1@gmail.com> wrote:

> On Thu, May 16, 2013 at 10:35 AM, Felipe Nascimento de Moura
> <felipenmoura@gmail.com> wrote:
>> hi.
>>
>> well, about that paragraph related to number formats that are already
>> supported by type "number"...
>> let's talk about what I faced here in Brazil(many other countries will  
>> have
>> the same situation):
>> - float number's format: 1234.56
>> - currency format: R$ 1.234,56
>
> Wow, this is the first time I've heard about a localization that has
> different number formatting to currency number formatting.

I have run across it before - it makes filling financial forms a nightmare
of mistakes.

> When I look at  
> http://pic.dhe.ibm.com/infocenter/forms/v3r5m1/index.jsp?topic=%2Fcom.ibm.form.designer.locales.doc%2Fi_xfdl_r_formats_pt_BR.html
> it seems you are wrong about the float number format, though, of
> course, I wouldn't know. Are you sure that is the case?

One of the issues is that what standards claim is the right localisation
doesn't always match what users actually expect and do.

One of these things is easier to change, in order to reduce the number of
painful mistakes we are dealing with.

>> Besides that, if I define the step attribute to "0.01", after typing  
>> that value(the invalid one), if I click in any of the up or down arrows
>> some browsers render for the user to go step by step, it jumps to
>> "0.01", once the previous value was invalid...please, notice that js
>> libraries apply THAT mask into the input value, so, when the js lib
>> tries to mask the value as the user types, it gets invalid(or, in some
>> browsers, is reset to ""...an empty value!). To use the js mask libs,
>> we must use inputs of type text!
>> What is even worst!
>
> Bugs in the implementation of the js library should be registered there.
> Bugs in browsers should be registered there.

Yes. But I think the key point here is slightly different. It should be
easier to provide localisation of number formats.

> You might need to point out to browsers the very special case of
> Brazil as you have explained above!
>
>> Agreed! Currency symbols would represent a problem when persisting date  
>> into a database, once it's impossible to "translate" an amount from one  
>> currency to another...we might just ignore the symbols by now! :p
>
> If you ignore the symbols anyway, then you can just render them in
> front or behind your input box.

Right.

>> About css+html, I see this as thousand-separator existing for
>> input[type=currency] as list-style exists for lists, and :invalid for
>> invalid inputs in forms...but I may be seing it in a different way than  
>> W3C intends to make HTML interact with CSS...
>
> input[type=number] works the same.
>
>> This way, programmers would also be able to ask the user what is the  
>> mask the user wants to use, instead of just base the formats on what
>> the OS says...
>
> There may be an argument to be made to allow the @pattern attribute on
> <input type=number>....

That is quite possibly the optimal solution, if pattern supports this
easily.

I note that software that is typically used for dealing with currency
generally supports providing patterns for it - a feature I use extensively
and one area where the Web Platform is pretty second-rate for building
interfaces.

>> I think it would be useful for me and, in a talk I gave around here, or
>> talking to other developers, I noticed that this is something most of
>> front-end programmers have faced!
>>
>> I know programmers can use areas-x and role, microdata or RDF to "fix"  
>> it to stay semantic, but wouldn't it be easier this way?
>
> What do browser vendors think about how currency should be supported?

"It should be simple".

Probably more important is to ask people who build systems that work with
currency - ERP systems, accounting interfaces, expense forms, and so on.

cheers

Chaals

-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
             chaals@yandex-team.ru         Find more at http://yandex.com

Received on Monday, 20 May 2013 09:13:50 UTC