Amphtml: bind to form validation state

[ericlindley-g]

/cc @choumx

[choumx]

@ericlindley-g Do we have any more context for this FR?

[ericlindley-g]

Just that it would be nice to be able to coordinate multiple aspects of page state with validation state (as opposed to strictly relying on pseudo-classes in the form itself.

Though I have to admit that after reading the amp-form docs again, I'm realizing that I'm not aware of a specific use case that wouldn't be addressed by the existing mechanism. Sorry to go back and forth on this, but maybe we should get a concrete example before diving into this one?

/cc @cvializ

[ericlindley-g]

Actually, I may have found a whole set of use cases :) I don't want to share proprietary brands, so will ping you offline

[choumx]

Looks like what we want is for amp-form to dispatch events when validation state changes, e.g.

<form on="validation:AMP.setState({isFormValid: event.isValid})">
  <!-- Event can also be fired by form children. -->
  <input type="text" name="name" required pattern="\w+\s\w+" on="validation:myPopup.show">
</form>

If so, we just need to decide what other data to surface on event.

A few questions for design review:

1. Which new events? E.g. separate valid & invalid events, and/or validation for both?
2. Should these events bubble? A valid event from an input element probably shouldn't also be triggered on its parent form that contains other, possibly invalid, inputs.
3. What data for new events? The type of validation error would be useful: valueMissing, typeMismatch, patternMismatch.

More abstract questions:

• Any use case for mutation of validation attributes via amp-bind?
• Too many events? Is there a more ergonomic/declarative way?

[ericlindley-g]

Sounds good — and bear in mind that we should support validation via XHR as well

[choumx]

11056 adds a valid and invalid events to forms that are fired in accordance with its reporting strategy. E.g. *-on-submit will fire events on submit and as-you-go will fire events on input/blur.

This should satisfy the core of this FR. We can add additional functionality (e.g. passing the error type in the event) in the future as new FRs arise. Closing and will follow-up with documentation shortly.