Changed component as I assume you want this considered for 5.1.

I'm not sure @pattern is the right way to solve that problem. It's actually not clear to me if the real issue is the Brazilian use case or localising number format in general. FWIW, I think it would be better to wait for feedbacks from developers after the widget will be widly and correctly implemented. For example, I'm not sure how <input type='number' lang='<locale>'> wouldn't be enough to force some localisation format.

I think the problem with locale is that it will be forcing developers to chose one of the existing patterns, when offering a pattern attribute would be more "malleable". Although, it would probably be easier to implement than specifying a mask.

(In reply to comment #2)
> I'm not sure @pattern is the right way to solve that problem. It's actually
> not clear to me if the real issue is the Brazilian use case or localising
> number format in general. FWIW, I think it would be better to wait for
> feedbacks from developers after the widget will be widly and correctly
> implemented. For example, I'm not sure how <input type='number'
> lang='<locale>'> wouldn't be enough to force some localisation format.

(In reply to comment #3)
> I think the problem with locale is that it will be forcing developers to
> chose one of the existing patterns, when offering a pattern attribute would
> be more "malleable". Although, it would probably be easier to implement than
> specifying a mask.

Why would a developer want to set a format that has no meaning? Should we allow that? Like using X as decimal separator and $ for thousands? If a developer wants to use exotic format that has no meaning, it's not clear to me that using <input type='number'> is the right solution.

(In reply to comment #4)
> (In reply to comment #3)
> > I think the problem with locale is that it will be forcing developers to
> > chose one of the existing patterns, when offering a pattern attribute would
> > be more "malleable". Although, it would probably be easier to implement than
> > specifying a mask.
> 
> Why would a developer want to set a format that has no meaning? Should we
> allow that? Like using X as decimal separator and $ for thousands? If a
> developer wants to use exotic format that has no meaning, it's not clear to
> me that using <input type='number'> is the right solution.

It is not exotic formats!
As I mentioned, users in Brazil(the current example) are used to different currency formats, using "." as thousand separator and "," as decimal separator, while float numbers use no separator for thousand, and use "." as decimal separator.
So, it is not exotic, and it is not the "pattarn", and as I mentioned, if I type "1.234,56" in an input of type number, it is NOT VALID(both html form validation and :invalid are triggered), when it IS valid for us!
Meanwhile, if a user is supposed to type, let's say, the discount in %, the user will type something like "2.5", again, in an input=number, with different format, validation and separators(no thousando separator, as well).

(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > I think the problem with locale is that it will be forcing developers to
> > > chose one of the existing patterns, when offering a pattern attribute would
> > > be more "malleable". Although, it would probably be easier to implement than
> > > specifying a mask.
> > 
> > Why would a developer want to set a format that has no meaning? Should we
> > allow that? Like using X as decimal separator and $ for thousands? If a
> > developer wants to use exotic format that has no meaning, it's not clear to
> > me that using <input type='number'> is the right solution.
> 
> It is not exotic formats!
> As I mentioned, users in Brazil(the current example) are used to different
> currency formats, using "." as thousand separator and "," as decimal
> separator, while float numbers use no separator for thousand, and use "." as
> decimal separator.
> So, it is not exotic, and it is not the "pattarn", and as I mentioned, if I
> type "1.234,56" in an input of type number, it is NOT VALID(both html form
> validation and :invalid are triggered), when it IS valid for us!
> Meanwhile, if a user is supposed to type, let's say, the discount in %, the
> user will type something like "2.5", again, in an input=number, with
> different format, validation and separators(no thousando separator, as well).

Oh, I was forgetting, I think it is important to us to use inputs of type number for both of those situations(the price and discount, for example), because they are numbers, so, the enabled mobile keyboard should be the numeric one, as well as the validation rules. Also, the screen readers should mark it as numbers.
That's why I think it is supposed to be of type number, and I believe it would be useful if we could keep its validation more dynamically.
Although, I don't know what/how would it be better to implement such pattern...I mean, would it be like regular expressions? Maybe something simpler!

> Although, I don't know what/how would it be better to implement such
> pattern...I mean, would it be like regular expressions? Maybe something
> simpler!

The pattern attribute already exists and indeed works like a regex:
http://www.w3.org/html/wg/drafts/html/master/single-page.html#the-pattern-attribute

(In reply to comment #5)
> It is not exotic formats!

Sorry, I didn't meant that Brazilian format was exhaustic. I was trying to explain that allowing anyone to specify the thousand and decimal separator is a door open to allow weird thing and clearly, what we want is: thousand={,.'} decimal={,.} decimal != thousand. That's why I meant that using lang='something' for those edge cases could be a solution for web developers.

Generally speaking, I do not think the <input type='number'> widget is used and supported enough to be able to do that kind of monkey patches on the specification for the moment.

(In reply to comment #8)
> (In reply to comment #5)
> > It is not exotic formats!
> 
> Sorry, I didn't meant that Brazilian format was exhaustic. I was trying to
> explain that allowing anyone to specify the thousand and decimal separator
> is a door open to allow weird thing and clearly, what we want is:
> thousand={,.'} decimal={,.} decimal != thousand. That's why I meant that
> using lang='something' for those edge cases could be a solution for web
> developers.
> 
> Generally speaking, I do not think the <input type='number'> widget is used
> and supported enough to be able to do that kind of monkey patches on the
> specification for the moment.

I believe the way the input=number works today(even with the pattern attribute) works for numbers(I mean, integer and float ones, also using "E", etc...) but for financial date, it is not the best solution(the use of pattern would help, indeed, but it is not like something being used the way what it was created for).
That was the reason why I first proposed the idea of having an < input type="currency" >, avoiding such problems and being more "focused", even for semantics(let's say that a screen reader could read "one thousand twenty three dollars and fifty cents" instead of "one thousand twenty three point five"...HTML5 forms validation and css :invalid state would be a plus!
I believe the "pattern" attribute can really allow weird thing, as mentioned by Mounir Lamouri, but it is supposed to be used in any type of input, not only in numbers...then it makes more sense, but still, not the best solution for the situation we are discussing here...

let me know your thoughts about it :)

HTML5.1 Bugzilla Bug Triage: Incubation needed

A lot of the spec performs input validation for type=number using the rules for being valid floating-point numbers. Thus, to allow currency values as underlying values, they'd have to conform to the rules for floating-point numbers--which is why 1.23,45 does not validate. Pattern is intended for text entry controls, of which number is not.

To make this scenario better for i18n, user agents, could allow currency input into type=number, and convert between the user's value (in the locale) to a floating-point value--how what signal will the use to know this? lang attribute? As noted, lang does not provide enough context to know the intent of the value.

Seems like the best path forward is an input type=currency, which would act more like a text input, supporting pattern, etc., then like a number control. User agents could take the semantic hint that currency input is expected and show appropriate keyboards/UI, but wouldn't offer a spinner control or min/max/step semantics.

This bug constitutes a request for a new feature of HTML. The current guidelines [1], rather than track such requests as bugs or issues, please create a proposal outlining the desired behavior, or at least a sketch of what is wanted (much of which is probably contained in this bug), and start the discussion/proposal in the WICG [2]. As your idea gains interest and momentum, it may be brought back into HTML through the Intent to Migrate process [3].
[1] https://github.com/w3c/html#contributing-to-this-repository
[2] https://www.w3.org/community/wicg/
[3] https://wicg.github.io/admin/intent-to-migrate.html