Re: Form element dependencies

Should the dependency being based on the input state (i.e. empty/filled in,
or checked/unchecked), or on the input validity? Of course if we focused on
the state of radio buttons/checkboxes, state is what matters. Needless to
say, though, <input type="radio">, <input type="checkbox"> and <input
(type=text)> are all instances of the same element, so a dependency on
these controls should also take into account the control type.
Also, should the dependency control the validity check of the control, or
rather its state (enabled/disabled)? Of course I think the latter should be
taken into account. Disabled controls also defy the validity check, though.

A final consideration: disabled controls are enough to "simplify" form use,
as users don't consider them too much. So hiding controls (and labels as
well) is not that important. But if an author wanted to hide disabled
controls along with their label AND other auxiliary elements (some controls
could have disclaimers not included in label elements), making CSS rules
complex and related to the @for attribute is useless.
It would be enough to allow a dependency state also on fieldset elements.
Remember that <fieldset> can be @disabled, too.

2015-03-11 15:43 GMT+01:00 Cameron Jones <cmhjones@gmail.com>:

> On Fri, Mar 6, 2015 at 9:35 PM, sisbluesteel <sisbluesteel@aol.com> wrote:
> >> How many use cases are there for dependent inputs?
> >
> >
> > Some fields may not be wanted to be shown or activated if other fields
> are
> > not  set first. Hiding unneeded fields makes the form look less complex
> and
> > doesn't confuse the users. You see this quite often in login forms and
> > filing in request/ticets. Here's a few examples:
>
> This is a different use case from having the validity of a field being
> dependent on another field. To address that use case - i can't really
> see why a text input, for example, would  require another input to be
> valid to enable or disable its own value entry. Put another way,
> inputs are not calculated fields so i don't think there are
> dependencies between them.
>
> The case of having inputs enabled/disabled based on the state of other
> fields - radio, checkbox or select specifically, is more state
> management than validation.
>
> >
> > The implementation doesn't need to be overly complex. At it's simplest,
> it
> > could be implemented as such:
> >
> > <input type="text" type="date-time" />
> > <input type="text" depends="other-element" />
> >
> > When the other element is not valid, the dependant element has "disabled"
> > -attribute set. The actual hiding/showing can be done with CSS selectors
> > (":disabled").
> >
> >
>
> The first input would necessitate having the @required attribute set
> if it's validity were to be used as a @disabled control.
>
> The problem then arises that the validity of elements would control
> the state of other elements, so it would not be possible for the form
> to be valid given that both states are possible for form submission.
>
> What i think might be possible is to detach the scope from validation
> and instead focus on field state management.
>
> It might be possible to purpose the @for attribute on form controls to
> allow the state of one field to impact the state of another in a
> predefined manner based on the type of field.
>
> So for checkboxes, radios and select options the binary nature of
> their selection could be used to define the state of associated inputs
> or fieldsets. For labels, it might be possible to hook into the CSS
> :disabled selector based on association via the @for attribute.
>
> Cameron
>
>