W3C home > Mailing lists > Public > public-html@w3.org > May 2013

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

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Thu, 16 May 2013 14:28:07 +1000
Message-ID: <CAHp8n2=yS-OqsqwTSoTi2BLbwFHnL6LOs36v1etqpi+GMpKAog@mail.gmail.com>
To: Felipe Nascimento de Moura <felipenmoura@gmail.com>
Cc: public-html@w3.org
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.
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?

> 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.
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.

> 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>....

> 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?

Received on Thursday, 16 May 2013 04:28:59 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:46:02 UTC