Bug 27357 – Support :valid/:invalid CSS selectors

• Status: RESOLVED
• Resolution: FIXED
• Component: CSS

[Michelangelo De Simone]

Support for new CSS pseudoclasses from HTML5 specs should be added. Among them, ":valid" and ":invalid" have priority.

[Peter Kasting]

Can you list all the selectors that need to be added?  This bug is kind of vague.

[Michelangelo De Simone]

(In reply to comment #1)

> Can you list all the selectors that need to be added?  This bug is kind of
> vague.

:out-of-range
:in-range
:valid
:invalid
:default

(:required and :optional are waiting for review).

As far as I can say it's not extremely ctitical at this time but for :valid and :invalid it's possibile to rely on validity.valid and willvalidate.

[Peter Kasting]

:required and :optional have now landed on bug 25551.

:in-range and :out-of-range are covered by bug 27450.

[Peter Kasting]

Bug 27458 now covers :default.

Narrowing the scope of this to just cover the selectors not covered elsewhere.

:valid/:invalid should be pretty easy to support given the existing validity machinery.

[Michelangelo De Simone]

Created attachment 34943 [details]
Patch v1

[Michelangelo De Simone]

A note worth to be mentioned is that "willValidate" is missing from official Object's idl, Hixie and I discussed about it in #webkit and it's gonna be added soon.

[Adele Peterson]

Comment on attachment 34943 [details]
Patch v1

r=me.  A few comments about the log.

> diff --git a/WebCore/ChangeLog b/WebCore/ChangeLog
> index da90953..e7dbea2 100644
> --- a/WebCore/ChangeLog
> +++ b/WebCore/ChangeLog
> @@ -1,3 +1,44 @@
> [phone]  Michelangelo De Simone  <[e-mail]>
> +
> +        Reviewed by NOBODY (OOPS!).
> +
> +        https://bugs.webkit.org/show_bug.cgi?id=27357
> +        Support for :valid and :invalid CSS selectors, from HTML5 specs.
> +        http://www.whatwg.org/specs/web-apps/current-work/#selector-valid
> +
> +        Tests: fast/css/pseudo-invalid-001.html
> +               fast/css/pseudo-invalid-002.html
> +               fast/css/pseudo-valid-001.html
> +               fast/css/pseudo-valid-002.html
> +               fast/css/pseudo-valid-003.html
> +               fast/css/pseudo-valid-004.html
> +               fast/css/pseudo-valid-005.html
> +               fast/css/pseudo-valid-006.html
> +               fast/css/pseudo-valid-007.html
> +
> +        * css/CSSSelector.cpp:
> +        (WebCore::CSSSelector::extractPseudoType): extracts new pseudos

should say "pseudo-classes" instead of "pseudos" throughout the log

> +        * css/CSSSelector.h:
> +        (WebCore::CSSSelector::):
> +        * css/CSSStyleSelector.cpp:
> +        (WebCore::CSSStyleSelector::canShareStyleWithElement): style sharing
> +        mechanism rests for valid/invalid form control elements

I think you want to say something like "Make sure we don't share style between form controls that have different validity states" 

> +        (WebCore::CSSStyleSelector::SelectorChecker::checkOneSelector): applies
> +        style associated to new pseudos
> +        * dom/Element.h:
> +        (WebCore::Element::willValidate): pushed up in hiearchy

typo.

> +        (WebCore::Element::isValidFormControlElement): checks for valid form
> +        control elements (wraps ValidityState::valid())
> +        * html/HTMLFormControlElement.cpp:
> +        (WebCore::HTMLFormControlElement::willValidate): minor clean up
> +        (WebCore::HTMLFormControlElement::isValidFormControlElement): ditto
> +        * html/HTMLFormControlElement.h:
> +        * html/HTMLKeygenElement.h:
> +        (WebCore::HTMLKeygenElement::willValidate): added
> +        * html/HTMLObjectElement.h:
> +        (WebCore::HTMLObjectElement::willValidate): added
> +        * html/HTMLObjectElement.idl:
> +
>  2009-08-16  Nikolas Zimmermann  <[e-mail]>
>  
>          Reviewed by George Staikos.

[Michelangelo De Simone]

Created attachment 35039 [details]
Same as v1: revised changelog

[Peter Kasting]

Comment on attachment 35039 [details]
Same as v1: revised changelog

Because adele r+ed the original patch with a couple of comments, I'm going to land this patch, since it only differs from that one in terms of addressing those comments.

[Peter Kasting]

Fixed in r47444.

[Darin Adler]

Why did you add willValidate overrides to HTMLKeygenElement and HTMLObjectElement that always return false, just like the willValidate function in the Element base class? These have no effect and just clutter up the code.

[Peter Kasting]

Reopening until Darin's comment is addressed.  I can write a quick patch to rip these two out when I get in today.

[Michelangelo De Simone]

(In reply to comment #11)

> Why did you add willValidate overrides to HTMLKeygenElement and
> HTMLObjectElement that always return false, just like the willValidate function
> in the Element base class? These have no effect and just clutter up the code.

A correction is underway.

[Darin Adler]

(In reply to comment #13)
> A correction is underway.

Great! Note that it may not be just those two classes.

[Michelangelo De Simone]

(In reply to comment #14)

> Great! Note that it may not be just those two classes.

Uhmmm, as far as I can see the unnecessary overridden methods are just those two; willValidate() should be true only when FormControlElements are validable and most of the stuff was already there (I addressed it in #20101 last year).

Adding those two method has been a mistake due to rush.:) It'll be solved in minutes, just the time to double check layouttests.

[Michelangelo De Simone]

Created attachment 35129 [details]
Correction

[Peter Kasting]

Fixed in r47514.