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



Reply via email to