707885 - Hidden form elements shouldn't validate

Status: UNCONFIRMED

(Core :: DOM: Core & HTML, defect)

Description

[mbrevda]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_2) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.121 Safari/535.2

Steps to reproduce:

1. Create a form element with the "required" attribute
2. Hide the element
3. hit submit

See here: http://jsfiddle.net/H7GGe/1/


Actual results:

Hidden fields are subject to validation


Expected results:

Fields that aren't being rendered should not be subject to validation. A script error is probably more appropriate (as a field that is required should never be hidden and is probably a programing design error if it is);

See here:
http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#concept-input-required

and here:
http://code.google.com/p/chromium/issues/detail?id=87882

Comment 1

[Boris Zbarsky [:bzbarsky]]

The spec you link to says nothing about display:none inhibiting constraint validation.  At some point there was some discussion about that on the mailing list, but I can't recall what the final decision was... Mounir?

Comment 2

[mbrevda]

Though I included the link:
http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#interactively-validate-the-constraints

"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."

Comment 3

[Boris Zbarsky [:bzbarsky]]

That just says we may (but not must) log a message to the error console that there is a non-validating element with display:none.  This mayb be a good idea.  But the form is still not allowed to submit, as far as I can tell.

Comment 4

[Mounir Lamouri (:mounir)]

Basically, it's hard for us to have a clear idea of an element being visible or not. What we could try to do is to guess if it's visible and put a doorhanger on the submit button (or the element that originated the submission) that says we believe there is a hidden invalid element and ask the user if he wants to submit anyway but that would creates unexpected behavior.

I believe script error isn't the good way to go because the user will just not understand what's happening and obviously websites with that kind of issues haven't been tested with html5 forms validation.

Comment 5

[Boris Zbarsky [:bzbarsky]]

We can't tell with 100% certainty that an element is visible.

But there are lots of cases in which we can detect that it's _not_ visible.  So if we think that the slippery slope is worth getting on, we could add something that works for display: none, at least.  Certainly detecting that is easy (modulo SVG).

Comment 6

[mbrevda]

My main goal here is cross browser consistency. While the webkit guys almost convinced me that its ok to submit the form, I think that is wrong - as Boris pointed out. I (personally) dont care much for the script error - although it would be nice.

Hence, I would suggest an error of sorts that points out the the element is hidden (if thats feasible), but DON'T submit the form (which is the current behavior).

Comment 7

[Christopher Schultz]

Presumably, you are using Javascript to "hide" the element. Why not disable it at the same time? Disabling the element should also disable any validation that might be performed on the field.

Comment 8

[mbrevda]

Disabled fields aren't POST'd back to the server. Just because a field is hidden for a better UX, doesn't make it unimportant!

Comment 9

[Boris Zbarsky [:bzbarsky]]

If it's being posted, why shouldn't it be validated?  Seems like the whole point of validation is to not post invalid data!

Comment 10

[mbrevda]

How can something hidden be validated?! The user can't see it, hence they shouldn't be notified to fixed something that they cant.

Comment 11

[Boris Zbarsky [:bzbarsky]]

So fundamentally, this is a bug on the author's part.  The only question is what the right behavior is: submit bogus data, or don't submit.

Comment 12

[Christopher Schultz]

(In reply to mbrevda from comment #8)
> Disabled fields aren't POST'd back to the server. Just because a field is
> hidden for a better UX, doesn't make it unimportant!

If the field is important, then it ought to be validated, no?

Plus, how is the UA supposed to know if the field is hidden? What does hidden mean? display=none? White text on white background (or really foreground=background)? opacity=0.0? Some absolute element occupies a superset of the x,y coordinates of the element but has a superior z-index? The element is an chimpanzee walking through a basketball game?

My (presumably irrelevant) position is that this isn't the browser's problem, it's the application's.

Comment 13

[Mounir Lamouri (:mounir)]

In my opinion, the real way to fix that bug is with bug 630495. Unfortunately, the work there seems to be a bit frozen... In a nutshell, the idea is to, as far as we can, warn the user that submitting the form isn't doable because of a bug in the page. Optionally, we could add an option that says "Do you still want to submit the form, knowing that it might lead to unexpected results?".

Comment 14

[mbrevda]

(In reply to Christopher Schultz from comment #12)
> If the field is important, then it ought to be validated, no?

Indeed. Unless the UI is structured in such a way that would prevent the user from validating. In which case, duh, we CAN'T validate. Hence, there is no point in prompting.

It's nice when the browser is smart and all you need to require a field is a require attr. But at the same time, it needs to be sane. The user can validate a field if he can't see it. Putting a "This field is invalid" bubble in the corner of the screen helps no one.

I don't have a list of all the cases where a field should be considered hidden, but display:none is a non-brainer.

I think a chimpanzee walking through a basketball game is the opposite of hidden, it's really obvious. I also think it requires validation every time. But thats just me...