[whatwg] Form validation against invisible controls

I would also go with not using the visual state of an element as an indication of whether it needs to be validated or not but rather an additional attribute link the @hidden attribute proposed earlier.

I do see though that one might ask the question, how will I indicate an error on a specific field if that field is visually hidden? Good question but, that should be left up to the developer to handle and not the UA. Currently I reckon this is a problem as the UA decides where to place its validation, hoping there will be a way to override this behavior, if desired, in future.

Schalk

-----Original Message-----
From: whatwg-bounces@lists.whatwg.org [mailto:whatwg-bounces@lists.whatwg.org] On Behalf Of Tab Atkins Jr.
Sent: Thursday, June 03, 2010 5:55 PM
To: Jo?o Eiras
Cc: TAMURA, Kent; whatwg; Ian Hickson
Subject: Re: [whatwg] Form validation against invisible controls

On Thu, Jun 3, 2010 at 8:42 AM, Jo?o Eiras <joaoe at opera.com> wrote:
> On Thu, 03 Jun 2010 16:16:00 +0100, TAMURA, Kent <tkent at chromium.org> wrote:
>
>>
>>
>>> > An element is a "candidate for constraint validation" if 1. it is 
>>> > a validatable type,
>>> >    e.g. true if <input type=number>, false if <input type=reset> 
>>> > 2. has no "disabled" attribute, 3. has no "readonly" attribute, 4. 
>>> > inside of a <form> element, 5. has non-empty "name" attribute, and 
>>> > 6. not inside of a <datalist> element.
>>> >
>>> > I hope ValidityState and the pseudo classes ignores 2-6.
>>
>>> The pseudo-classes do not ignore 2, 3, and 6. (4 and 5 are now 
>>> removed.)
>>
>>
>> I'd like to propose to add another condition:
>>  7. it is visible (computed 'display' property of CSS isn't 'none' 
>> and no 'hidden' content attribute)
>>
>
> You'd need to check the visibility or display also of all ancestors, 
> that opacity is not 0, that the bounding box has enough size to render 
> the form to the user and etc.
> That's quite complicated to specify.
>
> Would be easier to tell that user agents might chose to ignore form 
> controls that they do not *paint* if that is possible for the UA to implement.

That's even worse - that defeats the time-honored trick to hide something visually without hiding it in any other way of absolutely positioning it off the screen.  It might even mean that elements currently off the screen (but that can be scrolled to) wouldn't validate.

~TJ

Received on Monday, 7 June 2010 04:53:29 UTC