Yeah, I'd prefer not to prefix :not. (Haha.) In fact :not used to actually support more complex selectors, and I had to dumb it down to pass stupid CSS 2.1 tests that deliberately checked for the lack of complexity... so all we'd be doing is going back to our old behavior. We should probably make sure those tests are not in the current version of the suite though.
dave ([email protected]) On Mar 30, 2011, at 10:50 AM, Simon Fraser wrote: > If the change is backwards compatible (i.e. if you don't break the behavior > described in Selectors 3), then I don't think it needs to be prefixed. > > What have other vendors done? > > Simon > > On Mar 30, 2011, at 12:05 AM, Ojan Vafai wrote: > >> What's the right thing to do for something that is in a CR spec, but the >> draft spec for the next version has it behave differently? Specifically, in >> Selectors 3, :not only accepts a single simple selector. In Selectors 4, it >> accepts a comma separated list of compound selectors (a superset of the >> Selectors 3 behavior). See https://bugs.webkit.org/show_bug.cgi?id=56994. >> >> I see three options: >> 1. Wait until Selectors 4 hits CR before changing :not. >> 2. Implement :-webkit-not to match Selectors 4 and leave :not matching >> Selectors 3. >> 3. Make :not match Selectors 4. >> >> My preference in this instance is option 3. >> >> Ojan >> >> On Tue, Mar 29, 2011 at 7:17 AM, David Hyatt <[email protected]> wrote: >> As was mentioned already, we've been trying to follow the general guideline >> of dropping the prefix when a draft hits CR and keeping it otherwise. An >> exception to this rule is if our syntax has not yet been updated to match >> the CR syntax, in which case we keep the prefix. >> >> dave >> >> _______________________________________________ >> webkit-dev mailing list >> [email protected] >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> >> _______________________________________________ >> webkit-dev mailing list >> [email protected] >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
