[whatwg] Why not creating a category for elements candidate for constraint validation?
Jonas Sicking
jonas at sicking.cc
Fri Jul 23 13:29:34 PDT 2010
On Fri, Jul 23, 2010 at 10:01 AM, Mounir Lamouri
<mounir.lamouri at gmail.com> wrote:
> 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.
It probably results in less code if a handful of implementations have
to add a few stubbed functions, than if millions of pages all will
have to check if constraint validation is there before using it.
Not to mention that I trust you (a implementor) to get this right, a
lot more than I trust thousands of webauthors to get this right.
/ Jonas
More information about the whatwg
mailing list