|Summary:||Support :valid/:invalid CSS selectors|
|Product:||WebKit||Reporter:||Michelangelo De Simone <michelangelo>|
|Component:||CSS||Assignee:||Michelangelo De Simone <michelangelo>|
|Severity:||Enhancement||CC:||darin, pkasting, tkent|
|Version:||528+ (Nightly build)|
|Bug Depends on:|
|Bug Blocks:||19264, 34733|
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
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 <firstname.lastname@example.org> > + > + 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 <email@example.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 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