12988 2011-06-18 13:33:56 +0000 I'm a bit in trouble on what type to apply for zip- postcodes. I would use type=number, but then I cant use the maxlenght attribute. While using type=text there are no max min attributes. No matter what type I choose, none of them works for zip- postcodes 2011-08-04 05:06:44 +0000 1 1 1 Unclassified HTML WG LC1 HTML5 spec unspecified Other other RESOLVED WORKSFORME http://www.whatwg.org/specs/web-apps/current-work/#text-state-and-search-state P3 normal --- 1 contributor ian axelwinter ayg jackalmage mike public-html-admin public-html-wg-issue-tracking public-html-bugzilla oldest_to_newest 49830 0 contributor 2011-06-18 13:33:56 +0000 Specification: http://www.whatwg.org/specs/web-apps/current-work/ Multipage: http://www.whatwg.org/C#text-state-and-search-state Complete: http://www.whatwg.org/c#text-state-and-search-state Comment: I'm a bit in trouble on what type to apply for zip- postcodes. I would use type=number, but then I cant use the maxlenght attribute. While using type=text there are no max min attributes. No matter what type I choose, none of them works for zip- postcodes. I would suggest to add a type=zip to the specifications. Posted from: 178.198.193.207 User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1 49836 1 jackalmage 2011-06-18 16:47:29 +0000 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. 49838 2 axelwinter 2011-06-18 17:16:40 +0000 (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. 49839 3 jackalmage 2011-06-18 17:24:07 +0000 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. 49864 4 ayg 2011-06-19 22:18:12 +0000 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? 49906 5 axelwinter 2011-06-20 09:07:15 +0000 (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 49927 6 jackalmage 2011-06-20 17:35:39 +0000 (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. 49941 7 axelwinter 2011-06-20 20:11:44 +0000 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 53103 8 mike 2011-08-04 05:06:44 +0000 mass-moved component to LC1