[whatwg] Form validation against invisible controls
dhtmlkitchen at gmail.com
Thu Jun 3 19:30:22 PDT 2010
On 6/3/10, TAMURA, Kent <tkent at chromium.org> wrote:
> Oh, I'm sorry. I have found a sentence about visibility in the draft.
>> If one of the controls is not being
> (e.g. it has the hidden <editing.html#the-hidden-attribute> attribute set)
> then user agents may report a script error.
That's about <input type="hidden">
> This sentence is about process against controls of which validation result
> is invalid.
> I think UA doesn't need to validate such controls.
You lost me on that one.
> The Chrome bug report is here:
That bug is describing an error when validating a control that cannot
have focus. That's more specific from a control that is not visible.
Is the issue in defining what is and what isn't focusable?
> 2010/6/4 TAMURA, Kent <tkent at 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
More information about the whatwg