“required” attribute and alternatives

After some answers received on the Github Issue for HTML I filed, I decided to make the same proposal here, in order to see if there can be some agreeing.

Form validation is not meant to natively handle complex cases, as validity methods allow authors to program complex form validations. But there’s a use-case which could easily be supported, and in a sense it is already supported, that is, alternative “required” controls.

When the required attribute is specified on radio buttons, it is required that one of the alternatives in the radio button group is selected. This cannot be different, for obvious reasons.

There are other cases, though, when an alternative is required. For example when a user is requested to provide either a phone number or an email (in two different fields in order to benefit from “type” constraint validation), or to subscribe a newsletter, specifying at least one interest among a series of alternative with checkboxes (the user can specify more than one).

So, my proposal is to extend the “required” behavior applied to radio groups to every group of form controls sharing the same name attribute value. Adding square brackets to names (<input name="foo[]" />) allows server-side script to process more values sharing the same name, so there will be no issue in submitting more than one checked box or more than one filled-in field.

EDIT: looks like square brackets aren’t even necessary for all server-side script languages (that is for PHP). Of course the whole proposal remains the same.

Did you consider writing a polyfill that implements that functionality? It seems doable and will enable to gauge interest in such a feature.

Yes, a prollyfill/draft seems the best way to go… Write it, see if you can get it to work for your own use cases - share it, get it to work for others, etc. Especially for early authors (pronounced ‘anyone who wants to use this for the next several years’) this is probably necessary anyway. There are still a number of browsers for example - modern ones - that don’t even prevent form submission for required input.

I’m going to work on it by levels. I’ll make a polyfill for handling validation as specified in my post in browsers which actually prevent form submission when required fields are empty/unchecked. Then I’ll make something broader.

What about allowing required on <fieldset>?

Would that mean that all elements inside a fieldset are required, or that at least one element is?

The problem is that in such case the validity state of each element would depend on its ancestor <fieldset> element, if any.

A theoretical question regarding required IDL attribute: when @required is specified on a radio button in a group, this makes the group required, even if the other buttons aren’t specified as required (although this practice is discouraged - however I’d suggest extending this behavior to all groups of elements defined by the same name). However, element.required returns true only for the element which actually has the attribute.

Shouldn’t required be made equal for all buttons in a radio group? Ideally, they are not required, but the group they belong to is (consider that RadioButtonList is listed among form.elements).

However, you can test the polyfill from here: https://github.com/AndySky21/AlternativeRequired.

When applied to a page, element.validity.valueMissing returns true if all controls sharing the same name are empty/unchecked/unselected.

Radio buttons and controls not referring to a form are excluded.

EDIT: now it works better and applies to controls outside a form too (even if it is just a matter of consistency).

EDIT#2 @yoavweiss and @briankardell the polyfill is done and covers my original use case but I’m not completely satisfied. I’m going to try @Tigt 's alternative (required on fieldsets) because it’s more elegant and avoids the issue of multiple controls with the same name. However, polyfill or not, it remains non-native. I hope it arrives further.

EDIT#3 Done. Please help me make people know about it.

I’d like to know what scenario is preferred by those who took part in this thread, a common name attribute vs. allowing required on fieldset elements.

As a side note, I noticed an oddity in how required IDL attribute and :required pseudo-class apply to radio buttons. In short, HTML spec states that a radio button list is required (i.e. one element must be checked) when at least one element has the required content attribute (this led me to my original proposal about required alternatives), even if the spec text advises authors against this practice.

This makes the property and the pseudo class relatively useful, because while scripts and stylesheet could generally consider only the required content attribute, they do not apply to radio buttons in a required radio button list which do not have the attribute set.

I think that IDL property and CSS selectors should reflect the “requiredness” of an element, rather than the presence of the attribute.

I hope to receive some feedback.

Can you provide some sample markup to illustrate the exact type of use-case this is aiming to solve. I’ve found, if you analyze the situation and re-think how you mark things up you can typically come up with a fine alternative without needing to alter the existing form element specifications.

I do think the element.required bit of the other radios in a group should be considered a bug, due to the way radios inherently work.