- From: Jeffrey Yasskin via GitHub <sysbot+gh@w3.org>
- Date: Wed, 08 Jan 2025 19:30:30 +0000
- To: public-css-archive@w3.org
Based on today's discussion, and incorporating some of @LeaVerou's framework for thinking about this from https://github.com/w3c/csswg-drafts/issues/10975#issuecomment-2442121401: We have ~8 kinds of things that authors might want to match. They don't all need to be in the first Selectors level that includes any of them, but the design should incorporate future expansion at least this far. See https://www.rfc-editor.org/rfc/rfc3986#section-3 for a diagram of how URLs decompose into these parts (except "site"), even though https://url.spec.whatwg.org/ overrides that for the detailed parsing rules in browsers. See https://web.dev/articles/same-site-same-origin for the distinction between sites and origins. 1. Same [site](https://html.spec.whatwg.org/multipage/browsers.html#same-site) 1. Same [origin](https://html.spec.whatwg.org/multipage/browsers.html#origin) 1. Same origin + a prefix of the [path segments](https://url.spec.whatwg.org/#url-path) 1. Same origin + [full path](https://url.spec.whatwg.org/#concept-url-path) 1. Same origin + full path + [parts of the query](https://httpwg.org/http-extensions/draft-ietf-httpbis-no-vary-search.html) 1. Same origin + full path + [exact query](https://url.spec.whatwg.org/#concept-url-query) 1. Same origin + full path + parts of the query + [fragment](https://url.spec.whatwg.org/#concept-url-fragment) 1. Same origin + full path + exact query + fragment I think I see that @keithamus cares most about "Same origin + a prefix of the path segments", "Same origin + full path", and possibly "Same origin" for the initial prototype and use case, so those are the most important to get the exact names agreed on. * These could be captured with a family of selectors (`:same-origin-link`, `:current-path-link`, `:self-page-link`, etc.) or with a single selector that takes parameters (`:self-link(site)`, `:self-link(path-prefix(3))`, `:self-link(fragment)`). * The selector[s] could include the term `link` to make it clear that they only apply to links, or they could omit that. * Some of the options could use `0` or an omitted parameter to imply other options: If `:current-path(N)` means "same origin + a prefix of the path segments", then `:current-path(0)` could mean "same origin", and `:current-path` (without a parameter) could mean "same origin + full path". There's an [argument](https://github.com/w3c/csswg-drafts/issues/10975#issuecomment-2442121401) that `(0)`, especially, is not ergonomic enough. * Some of the behavior could change depending on whether components of the matched link are empty. Personal opinion: this could be good as a shorthand, but would be bad if authors can't explicitly pick a behavior. * "exact query" and "parts of the query" could perhaps be combined if we assume pages that want non-exact query matching send a [`No-Vary-Search` header](https://httpwg.org/http-extensions/draft-ietf-httpbis-no-vary-search.html) and we're willing to have the "equivalent modulo search variance" algorithm there control CSS matching. * The [Github example](https://github.com/w3c/csswg-drafts/issues/10975#issuecomment-2394764465) cares about a substring of a particular query parameter (`is%3Aclosed` inside `q`) and so is probably too complex to capture here. One could imagine, though, wanting to style based on an `&is=closed` parameter even though other parameters are relevant to caching. We have a couple collisions with terms elsewhere in CSS or the platform: * "local", as described in the [OP](https://github.com/w3c/csswg-drafts/issues/10975#issue-2557192616). * "self-link", with https://github.com/w3c/csswg-drafts/issues/10498, although I think the last comment points toward not using that name. cc/ @tabatkins Did I miss any aspects of the design space? -- GitHub Notification of comment by jyasskin Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10975#issuecomment-2578471249 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 8 January 2025 19:30:30 UTC