[whatwg] Why not creating a category for elements candidate for constraint validation?

[Mounir Lamouri]

On 07/20/2010 04:07 PM, Simon Pieters wrote:
> On Tue, 20 Jul 2010 15:47:32 +0200, Mounir Lamouri
> <mounir.lamouri at gmail.com> wrote:
> 
>> Hi,
>>
>> I'm wondering why there is no categories for elements candidate for
>> constraint validation. In the current state of the specs, all listed
>> elements are candidate for constraint validation except when they are
>> barred from constraint validation. Barring an element from constraint
>> validation when it is in a certain state seems good but having elements
>> always barred from constraint validation seems a bad idea. It makes them
>> having the entire constraint validation API for nothing.
>>
>> Wouldn't that be preferable to have the constraint validation API
>> implemented only on elements that can actually use it? I think it would
>> probably be less confusing.
>>
>> So, anyone knows if there is a reason (too much categories already?
>> easier describe in the specs?) to have this done this way or if it could
>> be possible to have this new category?
> 
> I believe some elements have the API but are barred because it makes it
> easier to loop through form.elements and do the validation stuff without
> checking if the validation stuff is available on the element. (Same
> reason <textarea> has .type.)

But <keygen>, <object>, <fieldset> and <output> are barred from
constraint validation and <textarea>, <button>, <input> and <select> are
not [1]. Half of the elements have a useless API, that sounds too much
for me. I think it's not so complicated to loop through the form
elements and checking if it implements a part of the constraint
validation api or checking the tag name.

There is another reason why all these elements implement an API they do
not use?

[1] In my opinion, <output> should not be barred and <button> should.
But that's another topic.

Thanks,
--
Mounir