W3C home > Mailing lists > Public > public-html@w3.org > March 2015

Re: Form element dependencies

From: sisbluesteel <sisbluesteel@aol.com>
Date: Fri, 06 Mar 2015 23:35:55 +0200
Message-ID: <54FA1DBB.3020608@aol.com>
To: Cameron Jones <cmhjones@gmail.com>
CC: "public-html@w3.org LIST" <public-html@w3.org>
> 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:

Amazon Web Services
https://portal.aws.amazon.com/gp/aws/developer/registration/index.html

(Registration) The radio buttons enable/disable the second text field.

Openstreetmap
https://www.openstreetmap.org/user/new

(User account creation) Select "Alternatively, use a third party to 
login" and after that "Third Party Authentication" select-element will 
show/hide username -field.

Github
https://github.com/new

(Repository creation form, the page works only when logged in) Switching 
between "public" and "private" radio buttons enables/disables some fields.


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").

On 05.03.2015 14:59, Cameron Jones wrote:
> On Wed, Mar 4, 2015 at 7:53 PM, sisbluesteel<sisbluesteel@aol.com>  wrote:
>> Indeed,
>>
>> But I think this feature should be in the HTML specification. Here's a few
>> proposals how this could be implemented:
> I'm not sure the added complexity is warranted given that the
> functionality can be implemented using JS at present.
>
> How many use cases are there for dependent inputs?
>
> Front-end validation is additionally largely just an optimization as
> the primary location for validation will always be on the server-side
> to ensure conformance of rules as a necessity for security. There is
> always some validation which can't be performed client-side, unique
> database fields are one example. The point is that HTML will never be
> able to model the entirety of validation rules declaratively.
>
> Cameron
>
>> 1a) Attributes (data-* -like)
>>
>>    Don't know if this is a good idea, as the attribute name is not fixed. I'm
>> not sure if the XML representation can be validated so that the dependencies
>> actually point to existing elements.
>>
>>   Here the dependencies are expressed as either one of these attributes:
>>
>>      "dependency": The value must be the name (attribute) of the dependency.
>> This means that this element is valid/active only if the dependency is valid
>>      "dependency-*": The "dependency-" -prefix must be followed by the name
>> (attribute) of the dependency. The value must be the dependency's required
>> element value (e.g. If the dependency is a select-element).
>>
>>   <select name="example-select-dependency">
>>     <option value="1">1</option>
>>     <option value="2">2</option>
>>     <option value="3">3</option>
>>   </select>
>>   <input type="checkbox" name="example-checkbox-dependency" />
>>   <input
>>      type="text"
>>      name="example-checkbox-dependant-text"
>>      depends="example-checkbox-dependency"
>>    />
>>   <input
>>      type="text"
>>      name="example-select-dependant-text"
>>      depends-example-select-dependency="3"
>>    />
>>
>> 1b) Attributes with custom value syntax
>>
>>   This alternative specifies an attribute called "dependency" which value
>> requires special parsing:
>>
>> The value must  start with the name (attribute) of the dependency,
>> optionally followed by a colon (":") which must be followed with the
>> required value of the dependency element.
>>
>>   <select name="example-select-dependency">
>>     <option value="1">1</option>
>>     <option value="2">2</option>
>>     <option value="3">3</option>
>>   </select>
>>   <input type="checkbox" name="example-checkbox-dependency" />
>>   <input
>>      type="text"
>>      name="example-checkbox-dependant-text"
>>      depends="example-checkbox-dependency"
>>    />
>>   <input
>>      type="text"
>>      name="example-select-dependant-text"
>>      depends="example-select-dependency:3"
>>    />
>>
>> 2) Dependencies as elements
>>
>>   This implementation apes the datalist-element's syntax. This might not be
>> desirable because dependencies probably shouldn't be rendered by a user
>> agent (At least not visual ones), as opposed to datalist options.
>>
>> Form elements can have a "dependencies" -attribute which must contain an id
>> referencing a dependencies -element. "dependencies"-element must have
>> "dependency"-elements as children. Each "dependency" -element must have at
>> least a "name" -attribute which denotes the name of the dependency element.
>> Optional attribute "value" must contain the required element value of the
>> dependency.
>>
>>   <select name="example-select-dependency">
>>     <option value="1">1</option>
>>     <option value="2">2</option>
>>     <option value="3">3</option>
>>   </select>
>>   <input type="checkbox" name="example-checkbox-dependency" />
>>   <input type="text"
>>      name="example-checkbox-dependant-text"
>>      dependencies="dependencies-example-checkbox-dependant-text"
>>    />
>>   <input
>>      type="text"
>>      name="example-select-dependant-text"
>>      dependencies="dependencies-select-radio-dependant-text"
>>    />
>>
>> <dependencies id="dependencies-example-checkbox-dependant-text">
>>          <dependency name="example-checkbox-dependency" />
>> </dependencies>
>>
>> <dependencies id="dependencies-example-select-dependant-text">
>>          <dependency name="example-select-dependency" value="b" />
>> </dependencies>
>>
>>
>>
>> On 04.03.2015 16:47, Cameron Jones wrote:
>>> On Thu, Feb 26, 2015 at 12:17 PM, Sis Bluesteel<sisbluesteel@aol.com>
>>> wrote:
>>>> Hello,
>>>>
>>>> With HTML5 form validation comes a possibility to validate user written
>>>> data
>>>> without any server intervention (Before actually sending the whole form
>>>> data) or custom client-side scripting. However, currently there is no
>>>> predefined functionality in the markup or Javascript for form element
>>>> dependencies. And with 'dependencies', I mean an element's
>>>> validity/availability being triggered by another element's validity. Has
>>>> this been considered at any point?
>>>>
>>>> Please redirect me to the right mailing list if this not the right place
>>>> for
>>>> this kind of discussion.
>>>>
>>>> Cheers,
>>> There is the "Constraint Validation API" which models the validity of
>>> inputs based on their settings:
>>>
>>>
>>> http://www.w3.org/html/wg/drafts/html/master/#the-constraint-validation-api
>>>
>>> The method to use for dependencies would be to check another input's
>>> validity as part of the dependent input's checks.
>>>
>>> Thanks,
>>> Cameron Jones
Received on Friday, 6 March 2015 21:36:31 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:46:12 UTC