2014-09-09 10:04, [email protected] 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/
