Re: Form element dependencies

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 
> <mailto:cmhjones@gmail.com>>:
>
>     On Fri, Mar 6, 2015 at 9:35 PM, sisbluesteel <sisbluesteel@aol.com
>     <mailto: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
>
>