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<rendering.html#being-rendered>
(e.g. it has the hidden <editing.html#the-hidden-attribute> 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.
The Chrome bug report is here:
http://code.google.com/p/chromium/issues/detail?id=45640
2010/6/4 TAMURA, Kent <tk...@chromium.org>
> 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)
I couldn't find exceptional rules for validating invisible controls in the
current draft.
Chrome 5 was released with a part of interactive validation, and we
received a bug report about validation against invisible form controls.
--
TAMURA Kent
Software Engineer, Google
--
TAMURA Kent
Software Engineer, Google