2014-09-10 9:19, [email protected] wrote:
The new concept of a 'maximum' *required* value that you have
introduced, as I understand, means that the user would be *restricted*
to x number of fields. So with a 'maximum' value set at 4, would that
mean that the user cannot fill in all 5 input text elements? Would one
always be left out, regardless?
I have suggested an attribute specifying a maximum *allowed* value.
Simply so that for a <fieldset> or maybe another container, min=m
specifies that the number of controls with values must be at least m,
and max=n specifies that the number of controls with values must be at
most n.
If there are 5 text fields inside a container with max=4, then at least
one field must be left empty.
What happens if we were now to assign the boolean 'required' attribute
into three (3) of these input text elements? How should user agents
treat these fields?
There would be no change in the current function of the ’required’
attribute. Constraint validation would check that those fields are not
empty. It would also count the total number of nonempty fields and check
that it is at most 4.
Keep in mind that we have already stated a 'minimum' of two (2) fields
that should be filled in, with the 'minimum' attribute.
That would just be an extra constraint. It would be redundant, though,
since the individual 'required' attributes already imply the same
requirement.
When I first though of my proposal, I did not consider limiting /
restricting available fields. I'm not sure what the real-world
scenarios for limiting fields by a maximum value would be.
For example, an order form lets you order a product and select up to 4
extra widgets for it for no extra cost. This could use checkboxes
normally, but the principle is the same. It could also use text input
boxes if this is a more convenient way to the user to select the
widgets, but then you would not need a max attribute, as you would just
provide 4 fields.
Also, I found out just today that 'min' and 'max' attributes already
exist, so we shouldn't simply call them 'min' and 'max' if they were
to be implemented.
Well, reusing the names might indeed be confusing, as the meanings are
different.
Perhaps 'minreq' and 'maxreq' would be better names for these attributes.
Rather, 'minfields' and 'maxfields'.
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.
Not sure what you mean by problem with the 'select' element; while it
is an element that represents multiple options to choose from,
That exactly is the problem. A <select> element is for 1-out-of-many or
many-out-of-many choices from a given set of alternatives. The same can
be achieved using a set of radio buttons (for 1-out-of-many) or a set of
checkboxes (for many-out-of-many, i.e. when <select> has the 'multiple'
attribute). Yet, to change the presentation from e.g. a dropdown menu to
a list of radio buttons with labels, you need to rewrite the markup
completely. Thus, a 'minfields' or 'maxfields' attribute should be
applicable to a <select> too. Technically, we could always wrap a single
<select> inside a <fieldset>, but that would be rather arbitrary.
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).
Hmm, so the 'disabled' attribute isn't something with 'functional
impact'?
It has functional impact, but it is then the attribute that matters.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
