- From: <tristanlbailey@sgsoftware.com.au>
- Date: Tue, 09 Sep 2014 16:34:06 +0930
- To: public-html-comments@w3.org
Thank you for your replies. It would seem that I have posted to the right place. 2014-09-08 13:08, Jens O. Meiert wrote: > No other comment other than saying that a summary of the suggestion > could have well gone into the email, too :) Since I am new to posting on a public 'mailing list', I now realise that it would have been better to provide more information in my initial message. Thanks for addressing this by quoting my attachment. 2014-09-08 13:31, Jukka K. Korpela wrote: > More exactly, the attribute would have an integer value and its value > would specify the minimum number of fields that need to be filled in. I stated this in the first paragraph, third sentence of the attachment: "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. > The most important thing with extension proposals is usually the > existence and relevance of use cases. I think for this, use cases are > easy to imagine and describe. A very simple and common case is that the > user is expected to provide at least one way of contacting him. Another > scenario is a form where the user can select (say) up to three optional > items from a list. Agreed. I tried to provide life-like scenarios in my code examples, although the first code example is lacking somewhat in this regard. > The next question is implementability. This does not sound excessively > complicated, even though it introduces yet another aspect that browsers > would need to consider in form validation. Understood. The simpler something is, the easier it is to implement. The proposal as it currently stands, is quite simple, but is still subject to modification. > I don't think the name "required" would be suitable, since an attribute > with that name is already in use as a so-called boolean attribute, and > an attribute with a different set of values would be confusing. Understandable. However, it would not be so confusing if the proposal is implemented into the standard. It should not be difficult to interpret the use of the required attribute as having a different behaviour, when used with the 'fieldset' element, to using it with the other elements. I may need to be advised on whether or not this attribute should be part of an attribute 'class', such as "Global attributes". It is similar in both behaviour and context to the existing 'required' attribute of input elements (also 'select' and 'textarea' elements, as I have recently discovered). Do all HTML element attributes of the same name need to accept the exact same data types, and have the exact same behaviour / functionality where ever declared? Would having an attribute with the same name but somewhat different behaviour and type be a problem for the DOM? > On the functional side, it would be logical to have also an attribute > for specifying the maximum number of fields that must be filled in. I > wonder if "min" and "max" might be suitable names for such attributes. I don't understand this "min / max" concept in context with this proposal. Could you perhaps elaborate, by providing examples? Please also refer back to my previous statement on use of the word "minimum". > 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... 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. > Introducing a new element for grouping sounds awkward. Introducing the > attribute for the <div> element would be somewhat odd too. I defaulted to considering the extension of an existing HTML element, to avoid the need to create a new HTML element. The 'fieldset' element does not have much functionality to it at the moment, and considering that it groups field elements together, it made more sense to use it than any other form-related element. > But before going into such issues, a discussion about the usefulness of > a feature at an abstract level is needed: should there be a possibility > in HTML to specify that some minimum number of fields among some > designated set of fields must have values, to pass form data validation > in a browser? And should there be a corresponding way of specifying the > maximum too? Please check over my code examples to make sure you know exactly what I'm getting at, such as when the number specified is greater than or less than the actual number of descendant elements with the current 'required' attribute, within the same 'fieldset' element. The concept of min/max attributes is confusing me. Thanks for your time, - Tristan
Received on Tuesday, 9 September 2014 07:04:46 UTC