Support for new CSS pseudoclasses from HTML5 specs should be added. Among them, ":valid" and ":invalid" have priority.
Can you list all the selectors that need to be added? This bug is kind of vague.
(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.
:required and :optional have now landed on bug 25551. :in-range and :out-of-range are covered by bug 27450.
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.
Created attachment 34943 [details] Patch v1
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 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.
Created attachment 35039 [details] Same as v1: revised changelog
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.
Fixed in r47444.
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.
Reopening until Darin's comment is addressed. I can write a quick patch to rip these two out when I get in today.
(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.
(In reply to comment #13) > A correction is underway. Great! Note that it may not be just those two classes.
(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.
Created attachment 35129 [details] Correction
Fixed in r47514.