- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 06 Jul 2022 23:36:59 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[selectors] Child & descendant pseudo element combinators`, and agreed to the following: * `RESOLVED: Start selectors 5 with the experimental work from this issue` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [selectors] Child & descendant pseudo element combinators<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/7346<br> <dael> TabAtkins: We've had for a little while a minor problem where pseudo elements inside pseudo elements have been tricky to target<br> <dael> TabAtkins: Repeatedly written incorrect rules that do not correctly target. *::marker doesn't hit inside ::before<br> <dael> TabAtkins: This will get more problematic over time as we add things like shared element transitions with a family of nested pseudo elements. Targetting a grandchild of a transistion element you have the name the transition tag regardless of where because can't meaningfully use target<br> <dael> TabAtkins: You can't save effort with nesting either<br> <Rossen_> q?<br> <dael> TabAtkins: Jake came up with the idea of having a combinator that can select into pseudo tree as a descdendant combinator. You say a name and you find it regardless of how nested it is<br> <dael> TabAtkins: Suggested syntax is :> for child pseudo combinator and :>> for the new descendant that goes asdeep as needed<br> <astearns> 'arrow' being '>', not '->'<br> <dael> TabAtkins: Specifics is when you use this combinator pseudo elements are elements with tag that is their element. :: is not part of the name<br> <heycam> q+<br> <dael> TabAtkins: I think that's the specifics. Allows us to greatly simplify and write code targetting, for example, ::marker<br> <dael> TabAtkins: Thoughts?<br> <dael> heycam: Can you summerize why not possible to use regular child and descendants once past first ::? If we're considering things inside top level can we use regular tag name matching?<br> <fantasai> heycam++<br> <dael> TabAtkins: Issue with doing that, first is would not let you generically select into psuedo trees. That feels not great that you have to enter the pseudo tree with a specific name and then you can do arbitary.<br> <Rossen_> ack heycam<br> <dael> TabAtkins: Slightly more important issue is it presupposes we don't event use child relationships in any other way which I'm not certain we want to guarantee. Some pseudo elements refer to real elements like ::slotted. Right now can't access further into tree but I don't know why we wouldn't do that in the future<br> <fantasai> See also https://www.w3.org/TR/2014/WD-css-scoping-1-20140403/#fragment-scoping<br> <dael> TabAtkins: instead idea here is there's a separate relationship and this combinator only goes across pseudo/child relationship<br> <dael> heycam: Makes sense<br> <dael> fantasai: one specific area we thought about this is ::page or ::colun type things and being able to pick elemental fragments in that fragmented region.<br> <dael> fantasai: We had thought about doing something where you can style black and white columns differently which needs you to enter the tree<br> <dael> Rossen_: fantasai I saw your last comment lifting BradK's old response. Is this something we want to repeat here?<br> <dael> fantasai: I think I was pulling up old comments. Haven't thought deeply to have a conclusion. Idea of going deeper into pseudo tree makes sense. I think bradk comment was we ID psuedo elements with a name that begins ::. The pseudo element is named :: which is how we know it's not real. This prop breaks that naming association<br> <dael> fantasai: I think it's a comment worth thinking about.<br> <dael> fantasai: Idea of using combinator syntax I can see benefits to it. I'm trying to think what's a way of keeping these considerations and bring together. Maybe instead of :> we do ::> so maybe still association with pseudo element so at least you've got two :s<br> <dael> TabAtkins: Using ::>?<br> <dael> fantasai: Yeah<br> <dael> TabAtkins: That would be fine. I suggested : to suggest pseudo, but more explict ::> is fine<br> <vmpstr> q+<br> <dael> TabAtkins: Obvious solution is :: as combinator and for reasons I explored years ago that's unfortunately impossible due to selector syntax. But it would be fine with ::> and ::>><br> <Rossen_> ack vmpstr<br> <dael> vmpstr: I wanted to ask how would this interact with :has?<br> <dael> vmpstr: Presumably to know if there is a pseudo element you need up to date style and I don't think we do this now. And with :has you can make it display:none<br> <dael> TabAtkins: Good question. B/c pseudo elements always exist or conditionally exist I suggest answer is :has can't see pseudo elements when you select that deep. We can address it in the future if there's a need, but I would say we should make it invalid to use the combinator<br> <dael> fantasai: Should we also make pseudo elements invalid in has in general?<br> <Rossen_> ч?<br> <dael> TabAtkins: I don't know<br> <dael> fantasai: Has the same problem<br> <Rossen_> q?<br> <dael> TabAtkins: Not sure you can write selectors that are problematic. If you can we should<br> <dael> fantasai: I suggest we make both invalid for now<br> <dael> Rossen_: Additional feedback for TabAtkins or Jake?<br> <dael> fantasai: I'd like to have a few more people weigh in but this overall makes sense to do this<br> <dael> TabAtkins: I can start laying down details in spec and we can get eyes once there's text. As long as no obvious objection now I'm happy<br> <dael> Rossen_: Not hearing any such objection from dozen or so people on the call<br> <dael> Rossen_: Let's move forward with spec. Once you have that hopefully more people will provide feedback<br> <dael> fantasai: RElated question, do we want to take a cut of selectors 4 to CR and redraft selectors 5?<br> <dael> TabAtkins: Think so and happy to put this in selectors 5<br> <dael> fantasai: Okay. Let's do that and you and I can work on taking a cut of selectors 4<br> <dael> TabAtkins: sgtm<br> <dael> Rossen_: Let's resolve on starting selectors 5 with the experimental work from this issue<br> <dael> Rossen_: Obj?<br> <dael> RESOLVED: Start selectors 5 with the experimental work from this issue<br> <dael> Rossen_: For selectors 4, any resolution for that at this point?<br> <dael> fantasai: We were going to make it invalid to use a pseudo element inside :has<br> <dael> Rossen_: Is this part of the issue or part of moving selectors 4?<br> <dael> fantasai: Related to this issue b/c this issue brought what happens if you put pseudo element in :has<br> <dael> jensimmons: We should open a new issue for that and give it more time<br> <dael> jensimmons: I don't think we should do it ahead of time b/c we think this is going to go through. We should look at present state<br> <astearns> +1 to a separate issue to discuss async and bring it back for a resolution<br> <dael> fantasai: Yes, looking at current and think it's a problem for the same reason as in context of this discussion. I think it's something we didn't consider. Allowing url:has(::marker) is confusion and shouldn't be possible<br> <fantasai> ol:has(li::marker) is confusing and shouldn't be possible<br> <dael> jensimmons: Cool. How about open an issue for next week's agenda<br> <dael> Rossen_: I don't mind that at all since the proposed resolution also didn't come through to me clearly from the previous converation<br> <dael> Rossen_: Do we want to fork that into a new issue and slot it for next week? It will fit nicely with some other items we're skipping this week<br> <dael> fantasai: Okay<br> <dael> Rossen_: Next week we can take all the resolutions to move selectors 4 forward<br> <dael> Rossen_: fantasai will you open?<br> <dael> fantasai: Sure<br> <dael> Rossen_: Anything else on this issue?<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/7463<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7346#issuecomment-1176857832 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 6 July 2022 23:37:03 UTC