- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 19 Jul 2023 22:44:24 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-syntax] Make it easier to express ranges for <An+B> selectors`, and agreed to the following: * `RESOLVED: Work on the problem of expressing ranges of children in selectors in a more intuitive way.` * `SUMMARY: Will discuss syntax further in issue.` <details><summary>The full IRC log of that discussion</summary> <dbaron> SebastianZ: I previously suggested a new syntax for expressing An+B selectors in :nth-child() etc.<br> <dbaron> SebastianZ: We were discussing this, we had 2 proposals. They seem orthogonal; we could have both. But I think one I suggested initially is targeting the most common use cases.<br> <TabAtkins> q+<br> <dbaron> SebastianZ: Tab was also mentioning some things.<br> <dbaron> SebastianZ: reusing the range syntax from Media Queries, with one addition: adding a "last" keyword to count from the last element instead of the first.<br> <dbaron> TabAtkins: The problem we're trying to solve is that right now a selector targeting a range of elements (e.g., 3rd through 7th), it's possible to write using two :nth-child()s, but it's not obvious how, and tricky.<br> <dbaron> TabAtkins: So the first thing we should agree on is whether to agree on developing a syntax to enable expressing ranges more easily.<br> <dbaron> TabAtkins: And if so we have some suggestions to go over and possibly decide between.<br> <dbaron> TabAtkins: I think it's a reasonably common case (e.g., "select the first 3 elements")<br> <Rossen_> ack TabAtkins<br> <SebastianZ> See also https://github.com/w3c/csswg-drafts/issues/4140#issuecomment-517857973<br> <dbaron> TabAtkins: you have to write :nth-child(3-n) or :nth-child(-n+3). I'd prefer n <= 3, like you'd write elsewhere.<br> <dbaron> TabAtkins: do we think this is worth adding to selectors?<br> <dbaron> florian: yes<br> <miriam> +1<br> <oriol> +1<br> <dbaron> fantasai: not sold on the syntax, but seems reasonable to come up with something<br> <fremy> I have written code that would have benefited from this, so sympathetic<br> <dbaron> +1 to working on the problem<br> <dbaron> RESOLVED: Work on the problem of expressing ranges of children in selectors in a more intuitive way.<br> <emilio> q+<br> <dbaron> TabAtkins: a few suggestions for syntax.<br> <dbaron> TabAtkins: oriol suggested a different approach from what TabAtkins and SebastianZ are thinking about.<br> <dbaron> TabAtkins: If you're expressing a range, do you want a range on the "n' variable or a range on the output?<br> <dbaron> TabAtkins: You want a range on the output rather than the input.<br> <oriol> q+<br> <dbaron> TabAtkins: If your range was 2n and your range is 1-5, are you selecting 2,4,6,8,10 or 2,4 ?<br> <fantasai> TabAtkins: In this case you want 2,4<br> <fremy> can you type this, @TabAtkins<br> <TabAtkins> 2n <= 5, for example, will return 2,4<br> <TabAtkins> if a "<= 5" condition can return 6,8,10 I think that's super weird<br> <astearns> range-limited output?<br> <dbaron> TabAtkins: this ties in to what syntax we're using<br> <dbaron> TabAtkins: I think if you see 2n <= 5, you expect all the values of 2n that result in a value <= 5.<br> <fremy> q?<br> <fremy> q+<br> <dbaron> emilio: Before anything else, can we agree on making it part of :nth-child() rather than inventing new pseudo-classes. I think it makes sense as part of :nth-child().<br> <Rossen_> ack emilio<br> <dbaron> TabAtkins: I think basically building this into An+B is good.<br> <Rossen_> ack oriol<br> <myles> q+<br> <dbaron> oriol: I prefer my proposal -- when I started ??? with the An+B syntax, I first assumed that "n" would be strictly positive, then I thought all integers -- there's an implicit condition that "n" is nonnegative. I think this implicit condition may be confusing. I was thinking my proposal adding an explicit condition to n could make things more clear.<br> <fremy> (I'm in the queue for a different topic, so I would not want to interrupt the decision on ruling out new pseudo-classes)<br> <fremy> q- later<br> <dbaron> oriol: That said, it may be true that the other proposal maybe covers more frquent cases in a shorter way.<br> <dbaron> oriol: You can convert from the other proposal to mine by adding another :nth-child() pseudo-class. I'm not opposed to the other one.<br> <dbaron> oriol: I think this is a good point covers ???.<br> <Rossen_> q?<br> <dbaron> s/covers/that my proposal covers/<br> <TabAtkins> my actual proposed syntax kinda splits the difference tho, I suppose: ranges must be simple, just a number and n. So `:nth-child(n <= 5)` only, not `2n <= 5`. If you want to both, `:nth-child(n <= 5):nth-child(2n)` or `:nth-child(n <= 5 of 2n)`<br> <dbaron> myles: I think we've been reinventing list comprehensions that are in many proper prorgramming languages. We should take something that already exists.<br> <dbaron> TabAtkins: This is reinventing the range operators that some operators... different syntax space from list comprehensions.<br> <dbaron> myles: I'm not saying to dump python's list comprehensions in CSS -- but I'm saying for input vs. output do what the programming languages do.<br> <dbaron> TabAtkins: I disagree with that on principle -- it's more like a range than a list comprehension.<br> <Rossen_> ack myles<br> <dbaron> TabAtkins: the syntax affects whether your ranges are on the input on the output.<br> <dbaron> TabAtkins: Different languages make map-then-filter or filter-then-map easier, and I don't think there's a clear reason to prefer one based on precedent.<br> <SebastianZ> q+<br> <dbaron> TabAtkins: my preferred syntax proposal makes this moot. Rather than full An+B combined with ranges is that when we do ranges, you're limited to N on one side, a number on one side , and a sign in the middle. IF you want An+b stuff as well, you can do the same ?? as if you're combining 2 conditions together. Not ??? An ???. I proposed we only allow n <= 5. You can decide whether you allow the first 5 children that are also<br> <Rossen_> q?<br> <dbaron> ... even or the first five even children, depneding on how you write it.<br> <dbaron> hober: If I understand, I think I agree.<br> <TabAtkins> `:nth-child(n <= 5):nth-child(2n)` or `:nth-child(n <= 5 of 2n)`<br> <dbaron> TabAtkins: We can rely on existing CSS facilities.<br> <ntim_> q+<br> <ntim_> +1 to fremy<br> <dbaron> fremy: I think we're not going to have consensus today. But I want say I agree with following other languages. I think we shuold have multiple filters, applied in order author wrote them. I find it hard to understand "2n+3 < 5", no idea what it selects. I think we ned something more clear.<br> <dbaron> fremy: :nth-child(2n) is for the even things, and then say first three.<br> <dbaron> fremy: I think this reads better than the mathematic formula.<br> <dbaron> fremy: I think 2n+1<5 is too difficult to understand.<br> <ntim_> I agree 2n+5 < 5 is hard to understand<br> <Rossen_> ack SebastianZ<br> <Rossen_> ack fremy<br> <dbaron> SebastianZ: I want to note first proposed syntax also involves "last" keyword as said in beginning, which allows counting from the end. From 3 rd element to 3rd-last element, style everything. Wouldn't be psosible with second proposed syntax.<br> <dbaron> TabAtkins: We could have negative indexes mean what they do in most programming languages.<br> <dbaron> fantasai: but we don't do that now<br> <fantasai> Like, I really love negative indexes representing from the end. But we don't do that now, and so I think it would be confusing to have it work fo rome things and not others<br> <plinss> we do use it in grid<br> <dbaron> SebastianZ: With the proposal of the "last" keyword we can also express ranges to an nth-last child. Tab said probably possible with second proposed syntax, but I don't think possible, but I disagree, since we're there focusing on the "n" which means the number of elements.<br> <TabAtkins> once we drain the queue, i propose we take this back to the issue for syntax discussion<br> <Rossen_> q?<br> <dbaron> oriol: with my proposal "n" is just the ? in the expression<br> <astearns> s/?/entity<br> <dbaron> oriol: Going from the index of the last child ..<br> <dbaron> oriol: if we want to express conditions to the end, constrain on the output seems more suited<br> <fantasai> plinss, good point :) but not in :nth-child(), and in fact some of the :nth-child() patterns rely on us not processing negative indexes :/<br> <dbaron> ntim_: +1 to fremy about 2n+1 < 5 being hard to understand.<br> <dbaron> ntim_: hope we don't end up with that<br> <Rossen_> ack ntim_<br> <Rossen_> ack fantasai<br> <fremy> Can I suggest maybe to do like we did before in such cases, make a list of use cases, and then write how each proposal writes that range?<br> <dbaron> fantasai: I was going to suggest table discussion until friday. Tomorrow we'll have time for people to workshop ideas. We should do that tomorrow.<br> <dbaron> TabAtkins: This is going too long, we should go back to the issue.<br> <myles> ScribeNick: myles<br> <dbaron> SUMMARY: Will discuss syntax further in issue.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4140#issuecomment-1642860839 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 19 July 2023 22:44:27 UTC