Re: Form element dependencies

The idea is quite good and as I said before it allows authors building
forms which not only display/hide some elements when unnecessary (i.e. when
they depend on other elements which haven't been selected), but in such a
way that form validation applies nonetheless.

Just one note:
1. maybe a brand-new attribute name should be used. @for is already
specified on label and output elements with very different meanings, so I
believe it would be too much.
2. maybe elements or fieldsets could depend also on <option> elements
inside a <select>? Or would it be too difficult/useless?

2015-03-14 16:06 GMT+01:00 <chaals@yandex-team.ru>:

> Without wanting to comment on the particular proposed solution, the use
> case I understand for this is that for people with various cognitive
> disabilities (i.e. most of us) it is helpful not to have a monster form in
> front of us if we are only going to need to fill in 1/4 of it.
>
> There is a corresponding use case for a form that has been stripped down
> to the "now task", which is "show me all the things you are going to ask,
> so I can abandon now instead of halfway through when I discover something I
> can't answer. For commercial reasons a lot of people who should do this
> won't (basically, they get some of your information instead of none, by
> leading you down the garden path), but for user-friendliness others will
> work hard to get this right.
>
> The approach being outlined here seems far better for dealing with the use
> cases than the common practice of stepping people through pages each of
> which has a few things on it.
>
> cheers
>
> Chaals
>
> 14.03.2015, 00:43, "sisbluesteel" <sisbluesteel@aol.com>:
>
> So,
>
>  As a summary: In it's simplest, form dependencies, or form control state
> management would be utilised as follows:
>
> <input type="radio" for="dependant_text />
> <input type="radio" for="dependant_fieldset_a" />
> <input type="checkbox" for="dependant_fieldset_b" />
> <select>
>
>     <option>1</option>
>     <option for="dependant_date">2</option>
>     <option>3</option>
>
> </select>
>
> <input type="text" id="dependant_text" />
> <input type="date" id="dependant_date" />
>
> <fieldset id="dependant_fieldset_a">
>
>     <label>Text:</label><input type="text"  />
>     <label>Number:</label><input type="number" />
>
> </fieldset>
>
> <fieldset id="dependant_fieldset_b">
>
>     <label>Options:</label><select>
>         <option>a</option>
>         <option>b</option>
>     </select>
>
> </fieldset>
>
> Where the @for attribute controls the target element's availability
> (Triggering @disabled attribute). Hiding disabled control can be done using
> CSS as usual and doesn't require any added functionality(
> '.some-element:disabled { display: none }' ).
>
> Only new functionality added are: Allowing the @for attribute for input- (
> Of type: radio, checkbox) and option -controls and setting the target's (
> input, select, fieldset) @disabled attribute on/off when the states change.
>
> On 11.03.2015 18:32, Andrea Rendine wrote:
>
> 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
>
>
>
> --
> Charles McCathie Nevile - web standards - CTO Office, Yandex
> chaals@yandex-team.ru - - - Find more at http://yandex.com
>
>