[whatwg] Form validation against invisible controls

On Wed, 04 Aug 2010 23:32:46 +0200, Ian Hickson <ian at hixie.ch> wrote:

>
> 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)

site has now changed.

>> barnesandnoble.com (using required on visible elements that are  
>> supposed to be
>> empty on submit...)

https://cart4.barnesandnoble.com/account/request.aspx?stage=mainStage -  
click "Create an Account". Will fail unless you fill in the fields in the  
form to the left (which is really unrelated)

>> bookryanair.com (using required=false - this usage has also been found  
>> in JS
>> libraries)

site changed

>> ingdirect.com.au (using required on a visible field, but then emptying  
>> the
>> field with JS before submit)

https://www.ingdirect.com.au/client/index.aspx - type any "client number"  
and a 4 digit access code. Click log in. The client number field is then  
emptied by js before submitting but has required=true, causing error

>> usairways.com (using required on hidden elements)

The original issue seems to be gone (unable to search for flights from  
front page), but there is another one also related to WF2. Enter jfk in  
 from or to fields, wait for the autocompletion and select "New York, NY  
(JFK) (John F. Kennedy International Airport)" by hitting enter. Then you  
will get a maxlength error.

>> 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?

See above. If testing in Opera, set  
opera:config#UserPrefs|BrowserJavaScript to 0.

-- 
Ola P. Kleiven, Core Compatibility, Opera Software

Received on Thursday, 5 August 2010 05:20:53 UTC