DaveP

HTML5 Input Pattern Support

23 posts in this topic

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.

3 people like this

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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). :)

Share this post


Link to post
Share on other sites

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.

5 people like this

Share this post


Link to post
Share on other sites

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. ;)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

1 person likes this

Share this post


Link to post
Share on other sites
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.

1 person likes this

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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 ;)).

2 people like this

Share this post


Link to post
Share on other sites

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

2 people like this

Share this post


Link to post
Share on other sites

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 :)

Share this post


Link to post
Share on other sites

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 :(

Share this post


Link to post
Share on other sites
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. :)

4 people like this

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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. 

4 people like this

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.