HTML5 Input Pattern Support

[DaveP]

While I more than welcome the inclusion of 'Required' and 'Placeholder' support for input fields, I think one element that would be very useful would be 'Pattern' support. (Just in case anyone isn't aware, modern browsers can validate input based on a regex.)

Of course client side validation is no substitute for server side validation, but the same regex can be used server side, too.

[interrobang]

I don't have this as a requirement on any current projects, but this would be a great addition!

Some nice patterns: http://html5pattern.com

[Martijn Geerts]

Thank you for mentioning it. Learning every day

[ryan]

I'll be thrilled to add this. I guess I figured HTML5 pattern support wasn't so standard yet, but apparently it is. It also looks to me like HTML5 patterns are PCRE compatible (?) which is great, because we can use the same pattern both client and server side.

[netcarver]

Ryan, IIRC, they are almost so -- but I thought that in HTML5 you needed to omit the delimiters that PCRE expects. I might be wrong (probably so) and I don't have time to dig through the documentation right now.

[diogo]

It also looks to me like HTML5 patterns are PCRE compatible (?)

Hm, not really:

If specified, the attribute's value must match the Javascript Pattern production. [ECMA262]

http://www.w3.org/TR/html5/common-input-element-attributes.html#attr-input-pattern

[DaveP]

I'll be thrilled to add this. I guess I figured HTML5 pattern support wasn't so standard yet, but apparently it is. It also looks to me like HTML5 patterns are PCRE compatible (?) which is great, because we can use the same pattern both client and server side.

That's great - thanks Ryan.

As for browser support, my experimentation over the last few days suggests that they are supported by at least the latest versions of Chrome, Firefox and Opera on Windows. Not IE, obviously. Safari on Mac doesn't seem to either, oddly.

PCRE compatibility I'm less sure about. What I do know is that this regex generator produces patterns that work, and delights like

[A-PR-UWYZ0-9][A-HK-Y0-9][AEHMNPRTVXY0-9]?[ABEHMNPRVWXY0-9]? {1,2}[0-9][ABD-HJLN-UW-Z]{2}|GIR 0AA)

work (UK post code).

[apeisa]

IE10 supports.

[ryan]

Pattern support is now in place for text fields (dev branch). The pattern applies both client side (HTML5 pattern attribute) and server side, for the validation.

I looked through all of those patterns are html5pattern.com and couldn't find any that weren't PCRE compatible. So if it's not 100% compatible, I sure can't tell the difference. My guess is that HTML5 patterns are compatible with PCRE, but some of the more advanced PCRE stuff (maybe atomic grouping or negative lookbehind?) might not be compatible with HTML5.

[DaveP]

Pattern support is now in place for text fields (dev branch). The pattern applies both client side (HTML5 pattern attribute) and server side, for the validation.

You're a machine, Ryan.

IE10 supports.

Just found that there is a preview that supports Win7, so downloaded it earlier (huge download) but it requires a restart so it'll have to wait.

[Martijn Geerts]

This is awesome. Now thinking maybe we should have the option in config to restrict certain browsers that are not compatible with HTML5.

After setting $config->allowOnlyModernBrowsers = true; ( or something ) PW admin restricts access & give alternatives.

[netcarver]

Hi @Martijn

These HTML5 extended attributes should be totally transparent to browsers that don't support them so I don't think there would be any need for PW to have to treat them differently as you'd still have to do server side validation/checking on entered values anyway.

[ryan]

These HTML5 extended attributes should be totally transparent to browsers that don't support them so I don't think there would be any need for PW to have to treat them differently as you'd still have to do server side validation/checking on entered values anyway.

This is correct, the pattern is validated at server side too, so the HTML5 attribute is just a "nice to have". Though the fact that it's there provided good motivation for adding pattern support to the text field. Previously I thought regular expressions were too cryptic and code-oriented to expect from most users. But hey, if HTML5 is suggesting it and most browsers are implementing it, then we absolutely should. Personally I love regular expressions, but don't know many web developers that know how to use them. But it looks like that's changing, and sites like that html5pattern.com are great resources too.

[Martijn Geerts]

Oké, tnx for your reply netcarver & ryan. I love regular expressions to, this will be a big + for me. I didn't understand at first (my poor reading skills) that the regex that the developer would add was also applied server side.

This is huge !!!

[Pete]

Regular expressions are like a different language to me I'm much more comfortable with regular espresso's

maybe atomic grouping or negative lookbehind?

You threw this in to trip people up right? This sounds made up (but I'm certain it isn't ).

[ryan]

You threw this in to trip people up right? This sounds made up

Atomic Grouping

http://www.regular-expressions.info/atomic.html

Negative Lookbehind (and family)

http://www.regular-expressions.info

[netcarver]

There's also "possessive quantifiers" and "illogical shift upwards". Oops, scratch the last one, that's a machine code mnemonic a bit like "halt and catch fire".

[onjegolders]

Can you nasty people all stop hurting my poor little head with all these new ridiculously complicated languages!

It was only just over a year ago I coded my first little box with a red border in CSS

[Pete]

Pass as to why those links don't work by the way ryan - no matter what I do to them it doesn't format properly

[ryan]

Pass as to why those links don't work by the way ryan - no matter what I do to them it doesn't format properly

Ironically, odds are it's due to a broken regular expression in IPB's code.

[Ivan Gretsky]

The server-side validation via pattern does not seen to work. At least I can save a page via api with field value not matching field pattern (I set the pattern without php delimiters like "/"). Should I call some validation method explicitly?

[ryan]

Ivan, the input pattern is part of the input module (InputfieldText), and performed as part of the input validation. When assigning values from the API side, it is not considered user submitted input, so the Inputfield is not involved, and likewise the pattern is not a factor. When editing a field, you'll see "Details" and "Input" tab. All the settings on the Details tab are specific to the Fieldtype in use, whereas all settings on the Input tab are specific to the Inputfield. While we could move a setting like that to the Fieldtype, it's not ideal because plenty of other Inputfields extend InputfieldText, and are able to likewise benefit from the pattern support that it provides. Further, Fieldtypes are most efficient when they only perform very quick validations (like validation for type) since the Fieldtype's validation/sanitization occurs every time a value is populated to the page from the API (like every time a page is loaded), and validating a regex pattern is a relatively slow process. 

[Thor]

On 7/27/2015 at 6:03 AM, ryan said:

Ivan, the input pattern is part of the input module (InputfieldText), and performed as part of the input validation. When assigning values from the API side, it is not considered user submitted input, so the Inputfield is not involved, and likewise the pattern is not a factor. When editing a field, you'll see "Details" and "Input" tab. All the settings on the Details tab are specific to the Fieldtype in use, whereas all settings on the Input tab are specific to the Inputfield. While we could move a setting like that to the Fieldtype, it's not ideal because plenty of other Inputfields extend InputfieldText, and are able to likewise benefit from the pattern support that it provides. Further, Fieldtypes are most efficient when they only perform very quick validations (like validation for type) since the Fieldtype's validation/sanitization occurs every time a value is populated to the page from the API (like every time a page is loaded), and validating a regex pattern is a relatively slow process. 

Good to know. Maybe this should be clarified somewhere in the admin side or docs. While I already imagined this (pattern works on users input, but not when using the API directly in your code), I can imagine that some people will make the mistake of assuming it works with the API as well. And get data with GET or POST from another system thinking that PW is going to validate the data now and it's secure when it's not the case.

So great to read this post and that you are still required to make your own server-side validation if the user is not directly submitting the data. 

Using the API, of course, its assumed its safe and validated as users can't tamper with server/file code, but more than one person probably thinks the pattern/regex validation works globally in PW.