This repository has been archived by the owner. It is now read-only.

Respect constraints on custom element form fields #6

Closed
rnicholus opened this Issue Jun 28, 2014 · 12 comments

Comments

Projects
None yet
2 participants
@rnicholus
Copy link
Owner

rnicholus commented Jun 28, 2014

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

This comment has been minimized.

Copy link
Owner Author

rnicholus commented Aug 18, 2014

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

This comment has been minimized.

Copy link
Contributor

feltnerm commented Aug 18, 2014

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

This comment has been minimized.

Copy link
Owner Author

rnicholus commented Aug 18, 2014

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 rnicholus added this to the 1.2.0 milestone Aug 22, 2014

@rnicholus rnicholus changed the title Respect required attributes on custom element form fields Respect constraints on custom element form fields Aug 27, 2014

@rnicholus

This comment has been minimized.

Copy link
Owner Author

rnicholus commented Aug 27, 2014

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

This comment has been minimized.

Copy link
Owner Author

rnicholus commented Sep 27, 2014

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

This comment has been minimized.

Copy link
Owner Author

rnicholus commented Oct 11, 2014

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

This comment has been minimized.

Copy link
Owner Author

rnicholus commented Oct 11, 2014

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

This comment has been minimized.

Copy link
Owner Author

rnicholus commented Oct 12, 2014

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

This comment has been minimized.

Copy link
Owner Author

rnicholus commented Oct 12, 2014

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

This comment has been minimized.

Copy link
Owner Author

rnicholus commented Oct 13, 2014

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

@rnicholus rnicholus modified the milestones: 1.2.0, 1.3.0 Oct 22, 2014

@rnicholus

This comment has been minimized.

Copy link
Owner Author

rnicholus commented Oct 25, 2014

<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

This comment has been minimized.

Copy link
Owner Author

rnicholus commented Oct 25, 2014

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.

rnicholus pushed a commit that referenced this issue Oct 25, 2014

Ray Nicholus
feat(validation): validate custom form fields
Custom form fields will be validated, assuming they include
a hidden input that mirrors the validity of the custom form field.
A reference to the CE should be present on the hidden input via a
customElementRef property.

ref #6

rnicholus added a commit that referenced this issue Dec 5, 2014

@rnicholus rnicholus closed this in 8ccffd6 Dec 6, 2014

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.