I've emailed John Resig and a contact at MSDN for their respective test suites. I haven't heard back from them. I'll ping.
The change is backwards compatible. As far as I know, no other vendors have modified :not, but I haven't checked. The spec just got this wording last week. Ojan On Thu, Mar 31, 2011 at 4:25 AM, David Hyatt <[email protected]> wrote: > 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
