W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2010

[whatwg] :valid / :invalid only works in forms

From: TAMURA, Kent <tkent@chromium.org>
Date: Sun, 14 Feb 2010 14:43:05 +0900
Message-ID: <b7b4ecf81002132143q61e980b0k1459465669e0ac73@mail.gmail.com>
I agree with Erik.  It's useful if the pseudo classes work without a <form>
element and name attribute. <input> element is often used without a <form>
element in web applications.

A related topic:
http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#definitions
<http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#definitions>
> Note: An element can still suffer from these states even when the
> element is disabled; thus these states can be represented in the
> DOM even if validating the form during submission wouldn't indicate
> a problem to the user.

This paragraph mentions only "disabled". But it means ValidityState also
works without a form element, without a name attribute, or with a readonly
attribute, right?

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.

On Sat, Feb 13, 2010 at 02:56, Erik Arvidsson <arv at chromium.org> wrote:

> At the moment an input element needs to part of a form and have a name
> attribute for the CSS pseudo classes :valid and :invalid to be
> applied. [1] These limitations forces people to make their DOM more
> complicated just to be able to use these pseudo classes. It might have
> made sense to have these limitations in a world where JavaScript was
> not available but in many modern web apps there is no need for forms
> nor name attributes.

> Can we please remove these limitations?

> Erik Arvidsson


> [1] https://bugs.webkit.org/show_bug.cgi?id=34733#c7 (included below
> for completeness)


> http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#association-of-controls-and-forms
> > Constraint validation: If an element has no form owner, it is barred
> > from constraint validation.


> http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#naming-form-controls
> > Constraint validation: If an element does not have a name attribute
> > specified, or its name attribute's value is the empty string, then
> > it is barred from constraint validation.


> http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#pseudo-classes
> > :valid
> > The :valid pseudo-class must match all elements that are candidates for
> > constraint validation and that satisfy their constraints.
> >
> > :invalid
> > The :invalid pseudo-class must match all elements that are candidates
> > for constraint validation but that do not satisfy their constraints.


> http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#candidate-for-constraint-validation
> > A listed form-associated element is a candidate for constraint
> > validation except when a condition has barred the element from
> > constraint validation.




-- 
TAMURA Kent
Software Engineer, Google



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100214/107acdaa/attachment-0001.htm>
Received on Saturday, 13 February 2010 21:43:05 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:21 UTC