Bug 27357 - Support :valid/:invalid CSS selectors
Summary: Support :valid/:invalid CSS selectors
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: CSS (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P3 Enhancement
Assignee: Michelangelo De Simone
URL: http://www.whatwg.org/specs/web-apps/...
Keywords:
Depends on:
Blocks: HTML5Forms 34733
  Show dependency treegraph
 
Reported: 2009-07-16 16:18 PDT by Michelangelo De Simone
Modified: 2010-02-09 22:02 PST (History)
3 users (show)

See Also:


Attachments
Patch v1 (27.57 KB, patch)
2009-08-16 18:21 PDT, Michelangelo De Simone
no flags Details | Formatted Diff | Diff
Same as v1: revised changelog (27.59 KB, patch)
2009-08-18 05:59 PDT, Michelangelo De Simone
no flags Details | Formatted Diff | Diff
Correction (1.39 KB, patch)
2009-08-19 10:35 PDT, Michelangelo De Simone
darin: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Michelangelo De Simone 2009-07-16 16:18:04 PDT
Support for new CSS pseudoclasses from HTML5 specs should be added. Among them, ":valid" and ":invalid" have priority.
Comment 1 Peter Kasting 2009-07-16 16:32:56 PDT
Can you list all the selectors that need to be added?  This bug is kind of vague.
Comment 2 Michelangelo De Simone 2009-07-16 16:48:55 PDT
(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.
Comment 3 Peter Kasting 2009-07-20 11:43:08 PDT
:required and :optional have now landed on bug 25551.

:in-range and :out-of-range are covered by bug 27450.
Comment 4 Peter Kasting 2009-07-20 12:33:02 PDT
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.
Comment 5 Michelangelo De Simone 2009-08-16 18:21:34 PDT
Created attachment 34943 [details]
Patch v1
Comment 6 Michelangelo De Simone 2009-08-16 18:26:04 PDT
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.
Comment 7 Adele Peterson 2009-08-17 18:17:46 PDT
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 @@
> +2009-08-16  Michelangelo De Simone  <micdesim@gmail.com>
> +
> +        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  <nikolas.zimmermann@torchmobile.com>
>  
>          Reviewed by George Staikos.
Comment 8 Michelangelo De Simone 2009-08-18 05:59:36 PDT
Created attachment 35039 [details]
Same as v1: revised changelog
Comment 9 Peter Kasting 2009-08-18 12:49:41 PDT
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.
Comment 10 Peter Kasting 2009-08-18 12:50:17 PDT
Fixed in r47444.
Comment 11 Darin Adler 2009-08-18 23:44:23 PDT
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.
Comment 12 Peter Kasting 2009-08-19 09:50:59 PDT
Reopening until Darin's comment is addressed.  I can write a quick patch to rip these two out when I get in today.
Comment 13 Michelangelo De Simone 2009-08-19 10:09:53 PDT
(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.
Comment 14 Darin Adler 2009-08-19 10:17:07 PDT
(In reply to comment #13)
> A correction is underway.

Great! Note that it may not be just those two classes.
Comment 15 Michelangelo De Simone 2009-08-19 10:25:14 PDT
(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.
Comment 16 Michelangelo De Simone 2009-08-19 10:35:29 PDT
Created attachment 35129 [details]
Correction
Comment 17 Peter Kasting 2009-08-19 10:58:35 PDT
Fixed in r47514.