[whatwg] Form validation against invisible controls

Wed Aug 4 14:32:46 PDT 2010

On Fri, 4 Jun 2010, TAMURA, Kent 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)

The problem with that is that they still get submitted, so it seems weird 
to not validate them. It seems authors should be careful not to make the 
hidden controls be invalid.

On Thu, 3 Jun 2010, Tab Atkins Jr. wrote:
> 
> Adding @hidden to the list of things that skip validation is good.

I considered it, but really we should also also stop submission in that 
case, and that seems like it's starting to make things a little less 
intuitive than I'd like. It's really up to the author to make sure that 
something that's irrelevant (hidden="") is not part of a form that is 
user-submittable.

> Adding display:none is not.  That's a big layering violation that we 
> authors have to suffer through with screen readers already.  I'd greatly 
> prefer not muddying the waters there.

Indeed.

On Fri, 4 Jun 2010, TAMURA, Kent wrote:
>
> Oh, I'm sorry.  I have found a sentence about visibility in the draft.
> 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#constraint-validation
> >
> > If one of the controls is not being rendered (e.g. it has the hidden 
> > attribute set) then user agents may report a script error.
> 
> This sentence is about process against controls of which validation 
> result is invalid.
>
> I think UA doesn't need to validate such controls.

I think, as the sentence above suggests, it's better to report this as a 
page error than to not validate the control. Chrome already reports this 
problem in the console.

> The Chrome bug report is here:
> http://code.google.com/p/chromium/issues/detail?id=45640

The bug there is that Chrome is filling in a control that isn't visible, 
and, even worse, that it is filling it with a value that the user couldn't 
himself enter manually. That's a bug (two bugs in fact), but it has 
nothing to do with reporting validation errors -- the error should not be 
able to occur.

On Thu, 3 Jun 2010, Peter Kasting wrote:
> 
> I posted this on the Chromium bug, but I take the sentence Kent quotes 
> to affect only the UI shown on a validation failure, not the actual 
> results of validation.  That is, if a control fails validation and has 
> the "hidden" attribute, validation still fails, but the UA may display a 
> message indicating the page has an error in addition to/instead of the 
> normal validation failure message.

Indeed.

On Mon, 14 Jun 2010, TAMURA, Kent wrote:
>
> There are some objections against omitting invisible controls from form 
> validation. However, it is a real issue with existing sites and users 
> can't submit such forms at all though they can submit it with non-HTML5 
> browsers.
> 
> My conclusion is it's better to disable interactive form validation for 
> existing sites as possible. e.g. disabling interactive form validation 
> for documents without "<!DOCTYPE html>".

Just don't autofill controls with invalid values, and don't autofill 
hidden controls. :-)

On Mon, 14 Jun 2010, Ola P. Kleiven wrote:
> 
> The following sites have workarounds in Opera's browser.js to allow form
> submit:
> 
> airgreenland.com (using required on hidden elements)
> barnesandnoble.com (using required on visible elements that are supposed to be
> empty on submit...)
> bookryanair.com (using required=false - this usage has also been found in JS
> libraries)
> ingdirect.com.au (using required on a visible field, but then emptying the
> field with JS before submit)
> usairways.com (using required on hidden elements)
> 
> Most of these have been using it for several years and have not 
> responded to change requests from our side.

Do you have more specific URLs I could look at for these?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'