Re: [selectors] Previous-sibling combinator?

I feel like ~ should have been used for previous-sibling, since it's
sometimes used as a negation operator. And then just use ++ or ~~ to
indicate the "all after/before" combinators. The ship has long sailed for
that, though, unless we're planning on breaking backwards compat.

I like the idea of requiring spaces around the dash - it'll actually force
people to write nicely spaced out CSS combinators, haha - but it does break
typical naming conventions. Hm. I'm still for it, though.

Or we could use more wordy things such as :siblings, :siblings:before,
:siblings:after, similarly to the jQuery .siblings() function (do any
frameworks have CSS-ified syntax for all-siblings yet?).



On Sat, Feb 7, 2015 at 9:45 PM, Brad Kemper <brad.kemper@gmail.com> wrote:

>
> > On Feb 3, 2015, at 8:17 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> >
> > That said, I'm not certain this should be a combinator at all.  We can
> > instead put :has() in the fast profile if we limit it to only
> > containing + (and > ?) combinators.
>
> I'm for that, but I'd add the "following sibling" combinator (~) also, to
> get everything that has subsequent siblings. That should be no worse that +.
>
> Then to get something that has any P siblings, you would do this:
>
> :matches(:has(*~P), P~*)
>
> And these two would be equivalent:
>
> :matches(:has(*~), ~*)
> :not(:only-child)
>
>
>