Use <input type=text pattern="\d{5}(-\d{4})?">.

I'll close this bug as WORKSFORME - please reopen if you feel your problem isn't addressed.

(In reply to comment #1)
> Use <input type=text pattern="\d{5}(-\d{4})?">.
> 
> I'll close this bug as WORKSFORME - please reopen if you feel your problem
> isn't addressed.

The pattern attribute only works for type=text, but not for number. I a lot of countries the zip-code is just a number. Example in Switzerland it is a 4 digit number. The number must be in between 1000 and 9659. I think here it would be appropriate to use number, especially because on mobile devices the keyboard would change to a number-pad. Type=tel would work too, but is semantically incorrect.

With type=text there is no chance to check validity by browser and as far as I know, you cant address this with regex.

I know there are countries that have also letters in the zip-code, so numbers would not work. That's why I think a type=zip is needed.

I'm confused.  Did you read my response?  In it, I described exactly how to make an input that only accepts valid US zipcodes.  Is my suggestion inadequate in some way?

You also bring up the issue of international postal codes.  This is a substantially different problem, because there is *no* pattern to them.  If you're accepting international addresses, the postal code field needs to be a plain <input type=text>, with no additional constraints.  I type=zip wouldn't be able to help you at all here.

If the purpose is to address international zip codes, how would the input behave any differently from type=text?  If it behaves the same, why do we need a new one?

(In reply to comment #4)
> If the purpose is to address international zip codes, how would the input
> behave any differently from type=text?  If it behaves the same, why do we need
> a new one?

(In reply to comment #3)
> I'm confused.  Did you read my response?  In it, I described exactly how to
> make an input that only accepts valid US zipcodes.  Is my suggestion inadequate
> in some way?
> 
> You also bring up the issue of international postal codes.  This is a
> substantially different problem, because there is *no* pattern to them.  If
> you're accepting international addresses, the postal code field needs to be a
> plain <input type=text>, with no additional constraints.  I type=zip wouldn't
> be able to help you at all here.

Sorry for taking so long to reply.

My problem is that there is no clean and semantic way to address international zip-codes, and validate them as needed.

The example from Switzerland is that the zip-code must consist 4 numbers (easy to check with regex), but also has to be in between 1000 and 9659. I'm not sure if that an be done with pattern. What I think is needed is a type that allows the attributes pattern, min and max, that way we could address the Swiss problem, and also check validity of, as an example Canadian postcodes consisting letters and numbers.

In case of an numerical postcode, it would be nice if we can set the keyboard to a number-pad making input easier for users on mobile devices. The same is if you need a formfield for credit-card numbers, there is no type that gives the possibility to "force" a number-pad.

At the moment the only type to use is as you say type=text, but that needs JavaScript to check validity in the upper cases.

I hope that clarifies my intentions to open this issue

(In reply to comment #5)
> My problem is that there is no clean and semantic way to address international
> zip-codes, and validate them as needed.

There is no way to automatically validate international postal codes, because the per-country limitations are all over the board (as you note, Switzerland has a somewhat arbitrary range from 1000-9659).  If there is a specific country you need to validate, you can probably do it with @pattern.
 
> The example from Switzerland is that the zip-code must consist 4 numbers (easy
> to check with regex), but also has to be in between 1000 and 9659. I'm not sure
> if that an be done with pattern. What I think is needed is a type that allows
> the attributes pattern, min and max, that way we could address the Swiss
> problem, and also check validity of, as an example Canadian postcodes
> consisting letters and numbers.

<input type=text pattern="([1-8]\d\d\d)|(9[0-5]\d\d)|(96[0-5]\d)">

That pattern should properly limit you to a 4-digit number between 1000 and 9659.
 
> In case of an numerical postcode, it would be nice if we can set the keyboard
> to a number-pad making input easier for users on mobile devices. The same is if
> you need a formfield for credit-card numbers, there is no type that gives the
> possibility to "force" a number-pad.

This is being discussed elsewhere.  Look for the bug about type=numeric.

Wow this is amazing... I did not know that this could be done with regular expressions.
Looks like I have to read up a bit on redex. Anyway this solves the "Swiss problem" and the type=numeric discussion you pointed out is exactly what I tried to explain too.

Anway Problem solved

THX 10 times

mass-moved component to LC1