W3C home > Mailing lists > Public > public-html-comments@w3.org > September 2014

Re: Proposal of extension to element in HTML

From: Jukka K. Korpela <jukka.k.korpela@kolumbus.fi>
Date: Tue, 09 Sep 2014 10:37:17 +0300
Message-ID: <540EAE2D.3000003@kolumbus.fi>
To: public-html-comments@w3.org
2014-09-09 10:04, tristanlbailey@sgsoftware.com.au wrote:
> "The attribute can accept an optional valid non-negative integer 
> greater than zero."
>
> The value should not be regarded as a 'minimum' number of fields that 
> need to be filled in, as the value doesn't imply a minimum; it 
> specifies an exact amount of required fields, which can *override* the 
> number of required fields declared implicitly, through the use of the 
> existing 'required' attribute in each descendant input element.

Oh, then I misunderstood I guess. I'm not sure I follow the logic then. 
If the exact number of required fields is n, doesn't this mean that n 
fields must be filled, without excluding the possibility of filling in 
other fields? This sounds like a minimum number of fields to me.

> I don't understand this "min / max" concept in context with this 
> proposal. Could you perhaps elaborate, by providing examples?

I think it is an obvious generalization of the idea. Given a set of 
fields, you may want to set a requirement that at most n fields may be 
filled in, e.g. at most 3 checkboxes can checked to select some nice 
stuff. You may also want to set a requirement that at least m fields 
must be filled in, e.g. the user must write at least 2 names in a 
survey. Assuming we use max and min attributes for this, one can also 
make combined requirements, including a requirement like m=4 n=4, which 
says that exactly 4 fields must be filled in.

I think this should not relate to the "required" attribute at all. It 
should remain in its current meaning. Well, there would be the 
unavoidable logical connection that if the element contains more 
elements with the "required" attribute than is the value of the max 
attribute, this should be treated as an error (at the markup level).

There would be a problem with the <select> element, since it can 
logically correspond to a set of fields. Just as we often wish to set a 
minimum or maximum number of text fields filled in or checkboxes 
checked, we may wish to set a minimum or maximum number of options to be 
selected in a <select multiple>. Well, I guess <select> could have min 
and max attributes of its own.

> Using <fieldset> in this context is problematic, since it has default
>> rendering that suggests close association between fields.
>
> Not sure what you mean by this...

Take a look at the default rendering of <fieldset> in popular browsers.

> Input elements can be of varying types, and select and textarea 
> elements can also be used with the required attribute, all of which 
> can be presented under one 'fieldset' element.

Yes, <fieldset> can be used rather freely, but its apparent intended use 
is to group fields that are closely related, like a set of radio buttons 
or a set of <input type=text> elements for a postal address. It has no 
functional impact (in HTML as currently defined and implemented).

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/
Received on Tuesday, 9 September 2014 07:37:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:30 UTC