Re: [csswg-drafts] [css-overflow-5] Making ::scroll-marker existence unconditional? (#11600)

The CSS Working Group just discussed `[css-overflow-5] Making ::scroll-marker existence unconditional?`.

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> TabAtkins: Currently per spec, the existence of ::scroll-marker-group is dependent on container having a non-none value for scroll-marker-group property<br>
&lt;fantasai> TabAtkins: The ::scroll-marker pseudos are dependent on their ::scroll-marker-group existing<br>
&lt;astearns> https://drafts.csswg.org/selectors/#has-allowed-pseudo-element<br>
&lt;fantasai> TabAtkins: This means existence of ::scroll-marker is style-dependent, so can't appear as argument of :has()<br>
&lt;fantasai> TabAtkins: that's problematic<br>
&lt;fantasai> TabAtkins: e.g. Adam Argyle wanted to mark ::scroll-marker based on whether before or after current<br>
&lt;emilio> q+<br>
&lt;fantasai> TabAtkins: My proposal is that scroll-markers always exist, they just don't generate boxes unless various conditions are met<br>
&lt;flackr> +1<br>
&lt;fantasai> TabAtkins: that way you can always test whether scroll marker pseudo<br>
&lt;fantasai> TabAtkins: in :has() because it's always there<br>
&lt;dbaron> (I wonder if we should rename the "has-allowed pseudo-element" term to instead use words that describe the characteristic that makes the pseudo-element allowed within has.)<br>
&lt;astearns> ack emilio<br>
&lt;TabAtkins> (i'm fine with a rename)<br>
&lt;fantasai> emilio: Wasn't super clear to me if this is intended to change existence of ::scroll-marker-group<br>
&lt;fantasai> TabAtkins: I don't have a strong opinion on that. don't think there's a need to check :has there<br>
&lt;astearns> +1 dbaron, we should make it look less like a different pseudo<br>
&lt;fantasai> TabAtkins: but if we want to make things box-dependent ...<br>
&lt;fantasai> emilio: Also, why aren't we setting the pseudo-class on the originating element instead?<br>
&lt;fantasai> emilio: That seems simpler, less performance concerns.<br>
&lt;fantasai> emilio: We don't want to generate these, so I'd rather not... If we can apply to the pseudo-class to the originating element that's better<br>
&lt;fantasai> TabAtkins: That would solve this use case, and any case we care about<br>
&lt;fantasai> TabAtkins: Rob, did you have a reason why we can't set :target-current on the element?<br>
&lt;fantasai> flackr: What is :target-current depends on set of things that are ?? targets<br>
&lt;kbabbitt> s/??/eligible/<br>
&lt;fantasai> flackr: Something can be :target-current if it's the closest thing to the scrollport<br>
&lt;fantasai> flackr: but if there is another potential target, then that thing would be :target-current instead<br>
&lt;fantasai> flackr: So idk how you'd define that to work on regular elements without knowing whether they are targets<br>
&lt;fantasai> flackr: A thing becomes a target by having a scroll-marker<br>
&lt;fantasai> emilio: Doesn't that make it trivially cyclic?<br>
&lt;fantasai> emilio: If you can set a:has(::scroll-marker)::scroll-marker { display: none; }<br>
&lt;fantasai> flackr: yeah, that would be cyclic<br>
&lt;fantasai> TabAtkins: by definition<br>
&lt;kbabbitt> s/display:/content:/<br>
&lt;fantasai> TabAtkins: I'm trying to avoid that situation by generating the element by virtue of it being a link<br>
&lt;fantasai> flackr: Targets aren't links, they're htings you're linking to. Can be any element<br>
&lt;fantasai> emilio: [missed]<br>
&lt;astearns> s/aren't links/aren't necessarily links/<br>
&lt;fantasai> emilio: That pseudo-class also depends on styles<br>
&lt;fantasai> flackr: Yes, because determining current target depends on which things are targets which is based on style<br>
&lt;fantasai> flackr: Maybe this is just something that we cna't allow<br>
&lt;fantasai> TabAtkins: Seems like :target-current is cyclic and can't be allowed in :has()<br>
&lt;fantasai> TabAtkins: Right now restricted because currently only allowed on the pseudo-element<br>
&lt;fantasai> fantasai: It's also allowed on regular element<br>
&lt;fantasai> fantasai: That's one of the core features of this spec!<br>
&lt;fantasai> flackr: For those cases I don't think it's trivially cyclic<br>
&lt;astearns> ack fantasai<br>
&lt;TabAtkins> fantasai: I think the use-case should be solved<br>
&lt;TabAtkins> fantasai: by ahving more pseudo-classes<br>
&lt;TabAtkins> fantasai: :target-current, :target-past, :target-future<br>
&lt;fantasai> TabAtkins: I wanted to solve use case in a straightforward way<br>
&lt;fantasai> fantasai: The proposed solution is not straightforward...<br>
&lt;TabAtkins> astearns: so we'll take this back to the issue<br>
&lt;jfkthame> present-<br>
&lt;fantasai> s/:target-future/:target-future, so we could solve this use case more directly/<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11600#issuecomment-2773078652 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 2 April 2025 16:09:57 UTC