Re: [whatwg] Why not creating a category for elements candidate for constraint validation?
On Fri, Jul 23, 2010 at 10:01 AM, Mounir Lamouri wrote: > On 07/20/2010 04:07 PM, Simon Pieters wrote: >> On Tue, 20 Jul 2010 15:47:32 +0200, Mounir Lamouri >> 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 has .type.) > > But , , and are barred from > constraint validation and , , and 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, should not be barred and 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
Re: [whatwg] Why not creating a category for elements candidate for constraint validation?
On 07/20/2010 04:07 PM, Simon Pieters wrote: > On Tue, 20 Jul 2010 15:47:32 +0200, Mounir Lamouri > 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 has .type.) But , , and are barred from constraint validation and , , and 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, should not be barred and should. But that's another topic. Thanks, -- Mounir
Re: [whatwg] Why not creating a category for elements candidate for constraint validation?
On Tue, 20 Jul 2010 15:47:32 +0200, Mounir Lamouri 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 has .type.) -- Simon Pieters Opera Software
[whatwg] Why not creating a category for elements candidate for constraint validation?
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? Thanks, -- Mounir
