Respect constraints on custom element form fields

[rnicholus]

We'll need to pay special attention to required attributes on custom elements, such as <file-element>. These are not standard form fields, so this will be a bit more difficult.

The checkValidity method on the HTMLFormElement won't validate custom elements. We'll need to augment this (if possible) or be aware of custom element form fields and implement some convention to determine if any required custom element form fields are invalid. The other tricky part will be dealing with this in the UI. I'm not sure if there is a way to "trick" the browser into displaying a native validation error message for a custom form field. If not, we'll have to have our own UI to handle this.

This is mentioned in rnicholus/file-input#8.

[rnicholus]

Any thoughts on displaying a visual notification when a custom element form field is determined to be invalid?

Options:

1. No UI & expect the integrator to observe the invalid event and alert the user appropriately.
2. Include CSS as part of this CE that styles the invalid CE. Perhaps a red X or some sort of border.
3. Add a hidden text input next to the custom element. If the CE fails validation, add a required attribute to this hidden text input and re-submit (which will force the browser to display a validation warning next to the CE).

The last two options are a bit kludgey. But, I do like option 3 as we delegate to the browser for the UI (if the browser does provide a UI). With the proper CSS, I suspect we can make this work with option 3.

[feltnerm]

My vote is for 1, with an eye for eventually implementing 3.

1 because this is the simplest API and enables the most flexibility to the user.

3 because I think relying on the browser for UI is a good option, if possible.

It'd be nice if polymer had a convention for errors on elements... seems like core-input fires an input-invalid event...

[rnicholus]

ajax-form probably should use a similarly named event. "invalid" is too generic and could possibly collide with another event unrelated to core-ajax.

[rnicholus]

It seems reasonable to expect that the custom element will provide it's own markup for exposing validation errors, such as <paper-input>. So, we only need to agree on two things:

1. A property on the custom form field that reveals its validity.
2. A way to force the custom form field to let the user know that the element is invalid.

Regarding the first item, <paper-input> exposes an invalid property. It seems reasonable to make this the de-facto standard for custom form fields. <file-input> needs to be updated to follow this convention.

The second item needs further discussion. I believe <paper-input> updates UI validation cues in real-time, without any way to defer this behavior until the moment the field is "submitted". It may be annoying for some users to receive this feedback before the form is "submitted". If any custom form fields provide this behavior, we will need some method to be exposed that updates validation cues in the UI for this field.

[rnicholus]

Somewhat dependent on rnicholus/file-input#16.

We'll just check an invalid property for custom elements just before form submit, and assume that all input-like CEs have this property. <paper-input>/<core-input> have this property. <file-input> will as well in 1.0.

[rnicholus]

Now that <file-input> is updated, I can begin work on this.

• Check the invalid property of all custom elements before submitting the form.

I'll also ensure ajax-form works properly with Polymer 0.4.2.

[rnicholus]

Hmm, this is proving to be a bit difficult, at least in Firefox, where, on submit, an invalid <paper-input> doesn't trigger an invalid event, isn't (ever) detectable via an :invalid pseudoclass, but results in a browser-blocked submit, preventing any efforts at notifying the user via a custom event after a submit attempt. So, in effect, it doesn't appear to implement the constraints API, but it behaves as if it does on submit in one way. This isn't an issue in Chrome. Haven't tested other browsers yet.

[rnicholus]

Further investigation suggests that Firefox is the only browser where an "invalid" event is not triggered (or maybe just not consumable) on form submit if <paper-input> is the only invalid element in the <form>. It seems like this is a critical issue that must be solved to complete this case, so I'll have to investigate further and perhaps propose an adjustment to <paper-input> or <core-input>.

[rnicholus]

Even further investigation shows that this is not a Firefox-specific issue. In fact, it is common to all browsers that do not implement the web components spec. So, in Chrome, if a core-input/paper-element is included in a form field, and the field is invalid, the form submits anyway. In all other browsers, form submission is prevented, but the "invalid" event is either not fired by the underlying input, or it is squelched by platform.js.

Next step is to confirm that Polymer is squelching this invalid event and determine why the browser is not seeing the field as invalid in non-polyfilled browsers (Chrome) on form submit.

[rnicholus]

Now blocked/dependent on rnicholus/file-input#19. <core-input> will need to follow suit as well.

[rnicholus]

<file-input> 1.1.0 was just released with support needed to allow ajax-form to respect its validation constraints. I'll move forward and update ajax-form now to follow the expected conventions outlined above for custom element form fields that have validation constraints.

[rnicholus]

I have most of this completed in my local workspace. All that's left is a bit more manual testing, some more unit tests, and an update of the docs.

I know this works with file-input, but I'll probably modify paper/core-input as well. If that pans out, I'll run a PR past the Polymer folks and see what they think about adopting/promoting these conventions in other custom fields.