setCustomValidity() seems pointless on <fieldset>

[domenic]

Constraint validation only checks submittable elements. So if you do fieldset.setCustomValidity("Something is wrong!") this has no impact on preventing form submission.

I think constraint validation should also check fieldsets?

There might be other elements with the constraint validation API added to them but outside the submittable elements list...

[annevk]

The idea was that because it's a Listed element it should have the same general-purpose APIs as the other Listed elements: https://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-August/064766.html. I'm not sure how much sense this makes though.

I'm also not sure how much sense it would make for constraint validation to check fieldset elements. They are not form controls after all.

[domenic]

I'm also not sure how much sense it would make for constraint validation to check fieldset elements. They are not form controls after all.

https://jsbin.com/nucekozegi/1/edit?html,output (see #6868 for motivation) is an example where I think it would make sense. I.e. saying "something in how you've input into this fieldset is invalid", when it might not be possible to pinpoint specific elements.

[robertwbradford]

FWIW, we often have forms where one of two fields is required (e.g., first or last name, phone or email, etc.). Since a <fieldset> is the right semantics for grouping fields, it seems like it would be appropriate to set the custom validity at the fieldset level—and be able to use myFieldset.validity and myFieldset.validationMessage for displaying feedback to the user.

[jfbrennan]

Fieldset supports :invalid and other Constraint Validation stuff, so it stands to reason a developer should be able to setCustomValidity().

Addresses are a good example where a combination of address fields may satisfy the application's requirements. Independent validation of individual fields in this use case is not really helpful because their validity depends on what else has been done in other fields:

• address line 1 (required if line 2 is empty)
• address line 2 (required if line 1 is empty)
• city (required if zip code is empty)
• state (required if zip code is empty)
• zip code (required if city or state are empty)

The application could run that custom validation logic on submit and set an appropriate message based on what it finds using fieldset.setCustomValidity(message), which triggers :invalid on the fieldset and other Constraint Validation features.

[Superpat]

Another example would be date inputs. For credit card date expiry the type="month" input is not ideal since it doesn't reflect the format that is on the card.

A fieldset containing two textual inputs separated by a / makes an ideal input (static input masking is simpler to implement). But validating that a month is in the future implies parsing both dates and I don't want the validity popup to show for the inputs individually, I want it to popup on the fieldset.