Figure out new syntax for validate

[wichert]

The validate plugin currently still uses an old syntax style and is undocumented. It also does not support HTML5 validation. I propose that we revisit the purpose of this plugin.

Where possible I think we should use HTML5 validation approach such as the required attribute. We can use polyfills such as h5validate to do that.

For conditional requires we need an extended syntax that is more natural than what we currently have. It might make sense if this supports the same syntax as the depends pattern.

[cornae]

All of it makes a lot of sense to me. It would be good to create a demo page in a branch with all validation possibilities.

Op 15 okt. 2012 om 17:02 heeft Wichert Akkerman notifications@github.com het volgende geschreven:

The validate plugin currently still uses an old syntax style and is undocumented. It also does not support HTML5 validation. I propose that we revisit the purpose of this plugin.

Where possible I think we should use HTML5 validation approach such as the required attribute. We can use polyfills such as h5validate to do that.

For conditional requires we need an extended syntax that is more natural than what we currently have. It might make sense if this supports the same syntax as the depends pattern.

—
Reply to this email directly or view it on GitHub.

[chaoflow]

"Cornelis G. A. Kolbach" notifications@github.com writes:

All of it makes a lot of sense to me. It would be good to create a
demo page in a branch with all validation possibilities.

+1

And I'd like to keep the current validation pattern but mark it as
deprecated.

Op 15 okt. 2012 om 17:02 heeft Wichert Akkerman notifications@github.com het volgende geschreven:

The validate plugin currently still uses an old syntax style and is undocumented. It also does not support HTML5 validation. I propose that we revisit the purpose of this plugin.

Where possible I think we should use HTML5 validation approach such as the required attribute. We can use polyfills such as h5validate to do that.

For conditional requires we need an extended syntax that is more natural than what we currently have. It might make sense if this supports the same syntax as the depends pattern.

—
Reply to this email directly or view it on GitHub.

---

Reply to this email directly or view it on GitHub:
#68 (comment)

Florian Friesdorf flo@chaoflow.net
GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083
Jabber/XMPP: flo@chaoflow.net
IRC: chaoflow on freenode,ircnet,blafasel,OFTC

[wichert]

Is the old pattern used anywhere? I can not find a single reference to it anywhere.

[chaoflow]

Wichert Akkerman notifications@github.com writes:

Is the old pattern used anywhere? I can not find a single reference to
it anywhere.

yes - star

Florian Friesdorf flo@chaoflow.net
GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083
Jabber/XMPP: flo@chaoflow.net
IRC: chaoflow on freenode,ircnet,blafasel,OFTC

[wichert]

On Oct 29, 2012, at 13:37 , Florian Friesdorf notifications@github.com wrote:

Wichert Akkerman notifications@github.com writes:

Is the old pattern used anywhere? I can not find a single reference to
it anywhere.

yes - star

Where in star? A grep did not reveal anything for me.

[chaoflow]

Wichert Akkerman notifications@github.com writes:

On Oct 29, 2012, at 13:37 , Florian Friesdorf notifications@github.com wrote:

Wichert Akkerman notifications@github.com writes:

Is the old pattern used anywhere? I can not find a single reference to
it anywhere.

yes - star

Where in star? A grep did not reveal anything for me.

Might be only in the templates - need to check myself.

Florian Friesdorf flo@chaoflow.net
GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083
Jabber/XMPP: flo@chaoflow.net
IRC: chaoflow on freenode,ircnet,blafasel,OFTC

[wichert]

@chaoflow Have you checked?

[chaoflow]

removed from index for now ae19f1c

[domenkozar]

Btw, check http://parsleyjs.org/documentation.html

[chaoflow]

@wichert: please go ahead and make a validation we can be proud on, maybe involving parsleyjs?

[chaoflow]

milestone 1.1 would also be nice

[chaoflow]

https://groups.google.com/forum/#!topic/patternslib/GIbMiD9rulk

[wichert]

A blocker here is deciding how handle the DOM. There are several things we need to decide on:

1. Which classes do we set if validation has not happened yet, when validation has failed and when validation has succeeded
2. On which elements do we set these classes?
3. How are error messages added to the DOM?
4. How should custom error messages be specified? Keep in mind that standard i18n tools will require a separate attribute or element to be used for these.

@cornae can you make a proposal, preferably in the form of example markup?

[wichert]

My suggestions:

1. No class if validation has not happened yet, pat-validate-success if validation has succeeded and pat-validate-error if validation has failed.
2. Both on the input element and its label, same as we do in several other patterns do.
3. Perhaps an <em class="error">...</em> after the input element. How about multiple error messages for the same input?
4. No idea I'm afraid. This becomes more complicated if there are more possible errors (for example separate texts for required and minimum-value checks).