- From: Robert Flack via GitHub <sysbot+gh@w3.org>
- Date: Tue, 29 Apr 2025 14:11:35 +0000
- To: public-css-archive@w3.org
> So the proposal is that we solve this case by instead specifying :target-past and :target-future. These match any scroll markers before or after the current scroll marker (or, if no scroll marker is current, before/after the break where a current marker could theoretically be. This sounds good to me. > However, this doesn't solve the "style the target element when the marker is hover" use-case Adam brought up afterwards. Yeah, this would be really nice to have. I think it is necessarily cyclic, to the concern @emilio raised. We'd have to handle it in a similar way to some of these other new properties like scroll state queries where we update it after the first lifecycle and rerun if the current target has changed (for the first time this frame). -- GitHub Notification of comment by flackr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11600#issuecomment-2839086144 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 29 April 2025 14:11:36 UTC