W3C home > Mailing lists > Public > public-css-archive@w3.org > April 2019

Re: [csswg-drafts] [selectors-4] need "first-matching-sibling" combinator (#3813)

From: v-python via GitHub <sysbot+gh@w3.org>
Date: Mon, 08 Apr 2019 19:27:33 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-480973320-1554751652-sysbot+gh@w3.org>
Thanks for the response, Amelia. My use case isn't one of the "many" you refer to... There could be dozens of items that match the left side, each of which would want to find the first sibling that matches the right side, of which there could be dozens or even hundreds following. So your first pararaph wouldn't apply immediately, and your second is a good example of why.

Interesting comment regarding how much of the right hand side applies: my use case is all on the same level, but now that you mention it, I can see it certainly could be an issue of understanding or documenattion to define the binding.  + doesn't look very far, binds to only one element, and either matches or doesn't based on the rest of the RHS. ~ starts with a set (that happens to also be a list), and can just start tossing items that don't match based on the rest of the RHS. But now I understand why all the current :nth-* items modify a particular selector, instead of using a "rich combinator" type of syntax... 

So another syntax possibliity could be

E:  S1 ~ S2:nth-match( n-expression )

This would clearly define the set of S2 that follows S1 as now, but would limit the scope of the counting to S2, not further to the RHS.  The remainder of the RHS would simply choose whether to apply the rule or not, having identified the candidate sibling, among the set identified by the (unchanged for this syntax) ~ combinator.  Does that simplify the presentation to the user, as well as limit the scoping on the RHS?

-- 
GitHub Notification of comment by v-python
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3813#issuecomment-480973320 using your GitHub account
Received on Monday, 8 April 2019 19:27:34 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 19 October 2021 01:31:07 UTC