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

Sounds like allowing the pattern attribute on a numerical input is the best
solution here.

The pattern would then define if the input is valid or not and inherit the
proper styling.

That would also be more consistent, adding a new input type would be
confusing since a common use-case for the number input is currency.





On Thu, May 16, 2013 at 12:28 AM, 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.
> 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?
>
> Cheers,
> Silvia.
>
>


-- 
*Greg Babula*
*Front End Developer*
http://GregBabula.info <http://gregbabula.info/>

*------*
*NOTICE: This communication (including any attachments) is covered by the
Electronic Communications Privacy Act (18 USC 2510 et seq) and is intended
to remain confidential.*
*------ *