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

Re: Proposal of extension to element in HTML

From: <tristanlbailey@sgsoftware.com.au>
Date: Tue, 09 Sep 2014 16:34:06 +0930
To: public-html-comments@w3.org
Message-ID: <cd36c14d3d48dd0399f7923427a26729@sgsoftware.com.au>
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 

> 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

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