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

Well...maybe allowing the pattern attribute would help, indeed.
But something must be done about it!

Because...the way it is, developers are supposed to pick a js lib to mask
the input(or build their own), define a RDF/microdata, use area-x, rule,
and understand much more of many more things...(correct me if I am mistaken
about it)
...something tells me that developers will not do that! And we will see W3C
representatives complaining that developers don't adopt some useful
patterns and accessibility...we have seen this before! Thousands...millions
of pages use inputs where the user types a currency value...almost none of
them uses such technologies, using just a text input, applying the mask via
js, and nothing more...

I think we must think on ways developers can do more, reaching better
results, in the easiest, most profitable way(easy and fast to implement,
with good, visible results). This way, companies will pay more attention on
what W3C is saying and hire developers who are worried about it!

I am just a bit afraid that developers find the pattern attribute too
complex. Although, it would offer more power, so developers could apply
many other uses to it, indeed!

PS.: About formats, I was taught in school, with that format I mentioned!
But it is Brasil, here, rules are not always applied! hehe




On Thu, May 16, 2013 at 3:01 PM, Greg Babula <gbabula@gmail.com> wrote:

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



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