[whatwg] Form validation against invisible controls
pkasting at google.com
Thu Jun 3 17:09:29 PDT 2010
On Thu, Jun 3, 2010 at 3:48 PM, Aryeh Gregor
<Simetrical+w3c at gmail.com<Simetrical%2Bw3c at gmail.com>
> On Thu, Jun 3, 2010 at 12:11 PM, 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 rendered (e.g. it has
> >> the hidden attribute set) then user agents may report a script error.
> > The Chrome bug report is
> > here: http://code.google.com/p/chromium/issues/detail?id=45640
> I think this isn't a feasible strategy to pursue. You'd have to
> carefully define what's "not being rendered", and it will violate
> layering massively. CSS should not be able to override constraints
> set in HTML. The latter are part of the semantics of the form, and
> the former is supposed to only control presentation.
> If the user can't actually change the form to match requirements,
> that's a bug in the page. The browser should not try to guess what
> the page really meant using some inevitably complicated heuristic. It
> should respect what the page says, and make it not work. If the
> browser has a UI for form validation errors, it can use that to tell
> the user what the problem is in terms that the page author can
> understand, so the user can report it and the page can be fixed.
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.
I agree that it would be a mistake to exclude "invisible" elements from
validation, as that would be a rathole (and seems conceptually wrong to me).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the whatwg