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

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

From: Felipe Nascimento de Moura <felipenmoura@gmail.com>
Date: Tue, 21 May 2013 19:50:11 -0300
Message-ID: <CAJVBkVmaoKZTCs=PqzPDpg_FKwfdQEYmhz4MoHXt1Gb+LS4DFw@mail.gmail.com>
To: Charles McCathie Nevile <chaals@yandex-team.ru>
Cc: Silvia Pfeiffer <silviapfeiffer1@gmail.com>, "HTML WG (public-html@w3.org)" <public-html@w3.org>
Hi.

I just registered it: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22129

I hope it can become something useful :)

Cheers.


On Mon, May 20, 2013 at 6:13 AM, Charles McCathie Nevile <
chaals@yandex-team.ru> wrote:

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



-- 
*Felipe N. Moura*
Senior Web Developer

Website:  http://felipenmoura.org
 Twitter:    @felipenmoura <http://twitter.com/felipenmoura>
LinkedIn: http://goo.gl/qGmq

Meet some of my projects:
BrazilJS Conference <http://braziljs.com.br/>  |  BrazilJS
Foundation<http://braziljs.org>
|  Power Polygon <http://github.com/braziljs/power-polygon>  |
TheWebMind<http://thewebmind.org/>  |
PHPDevBar<https://addons.mozilla.org/pt-BR/firefox/addon/php-developer-toolbar/>
---------------------------------
LinuxUser #508332
*Changing  the  world*  is the least I expect from  myself!
Received on Tuesday, 21 May 2013 22:51:21 UTC

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