Re: Proposal of extension to element in HTML

2014-09-10 9:19, tristanlbailey@sgsoftware.com.au 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/

Received on Saturday, 13 September 2014 16:17:56 UTC