- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 08 Jan 2025 17:39:10 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[selectors] :local-link should have a more precise name`. <details><summary>The full IRC log of that discussion</summary> <kbabbitt> keithamus: headline features for these is that there needs to be a way to differentiate links on a different origin vs different parts of a hierarchical navigation<br> <kbabbitt> ... e.g. on github.com/settings there might be sublinks on that, we have a big menu, a little visual treatment to show what page you're on<br> <kbabbitt> ... many sites do this, this selector attempts to abbreviate that<br> <kbabbitt> ... look at URL of current page, parts of it<br> <kbabbitt> ... selectors-5 currently just has local-link as a selector<br> <kbabbitt> ... I would like to extend that<br> <kbabbitt> ... jyasskin had some great commentary on that<br> <kbabbitt> ... resolution I'm looking for is: what selectors to enable, what to name them<br> <astearns> ack fantasai<br> <kbabbitt> ... not sure if I made sufficient justification for :local-link(n) but happy to make it<br> <fantasai> https://www.w3.org/TR/2013/WD-selectors4-20130502/#local-pseudo<br> <kbabbitt> fantasai: we had much more control in original version of spec<br> <kbabbitt> ... there was a proposal to cut it down to a more minimal set<br> <kbabbitt> ... if there's interest in making it more powerful that would be fine<br> <kbabbitt> ... but this issue is asking for a renaming<br> <kbabbitt> keithamus: topic is around the renaming but I'd like to discuss in context of if we had a suite of these selectors<br> <jyasskin> And fwiw, the :local-link(n) is still in https://drafts.csswg.org/selectors-5/#local-pseudo. It was removed from level 4.<br> <kbabbitt> ... there's a chance to approach this with a look at all of them and get some symmetry<br> <jyasskin> +1<br> <kbabbitt> ,,, to that end, we have [missed]-target already, should we have same-*? same-target, same-origin, same-path?<br> <kbabbitt> fantasai: difference between origin and domain?<br> <jyasskin> q+<br> <kbabbitt> keithamus: I don't think there's a distinction between those. there is between path and target<br> <kbabbitt> s/[missed-]/:/<br> <kbabbitt> fantasai: for matching fragment, there was proposal in the thread for :target<br> <kbabbitt> ... expanding out to all those things [missed]<br> <fantasai> s/:target/:target-link/<br> <kbabbitt> keithamus: symmetry would be :target-link, :local-link, ...<br> <kbabbitt> ... would :local-link still exist as matching origin?<br> <kbabbitt> ... or would we have :origin-link?<br> <kbabbitt> fantasai: previous proposal had :local-link(n) where n=0 represents same domain, 1 represents same first segment, etc.<br> <kbabbitt> ... one thing it didn't handle was query parameter, etc<br> <kbabbitt> keithamus: yes which is doable but difficult with one single selector<br> <kbabbitt> ... because if you have an arbitrary path it can grow to an arbitrary number<br> <fantasai> 1. :target-link matches including fragment<br> <fantasai> 2. :local-link matches page URL ignoring fragment<br> <keithamus0> q?<br> <fantasai> 3. :local-link(<integer>) matches domain + number of path segments<br> <astearns> ack jyasskin<br> <kbabbitt> astearns: jyasskin had concerns about using local in name<br> <kbabbitt> jyasskin: local is not great for this purpose because of what it means in the rest of platform<br> <kbabbitt> ... we want CSS to be consistent with those<br> <kbabbitt> ... and not confuse people wrt other parts of platform<br> <kbabbitt> fantasai: I think we have a structure and need better names<br> <kbabbitt> jyasskin: origin vs domain - domain isn't great but there is a site concept in other parts of platform which could be used here<br> <kbabbitt> ... not clear it's needed but could be right term<br> <kbabbitt> keithamus0: one suggestion in thread is same-path, same-site<br> <kbabbitt> ... same-path paramaterized with an integer<br> <kbabbitt> ... and then same-target<br> <kbabbitt> jyasskin: not sure target is exactly right, not sure [?] is what you want to match in a link, but it's not terrible<br> <kbabbitt> astearns: context is that keithamus0 is implementing local-link<br> <kbabbitt> ... looking to ensure whatever gets implemented can get extended<br> <kbabbitt> keithamus0: I've prototyped parameterized version in Chrome<br> <kbabbitt> ... that's the version most useful to github<br> <jyasskin> s/not sure [?] is what you want to match in a link/:target matches the thing referred to by the active fragment, so it might not be the right name when matching a link/<br> <kbabbitt> ... bare one could visually treat intra-page navigations as inter-page navigations<br> <kbabbitt> ... lot of posts about cross-origin links<br> <kbabbitt> fantasai: what if we called it match-link?<br> <kbabbitt> ... but that doesn't quite capture what you're matching<br> <kbabbitt> keithamus0: I like the idea of saying dash-whatever, it matches the problem space<br> <fantasai> `:self-link(<integer>)`<br> <kbabbitt> fantasai: also suggestion of self-link<br> <kbabbitt> keithamus0: does self-path(3) ...<br> <kbabbitt> fantasai: you don't need to distinguish in that case<br> <kbabbitt> jyasskin: is it self-origin, self-path, ...?<br> <kbabbitt> fantasai: parameter 0 means site, 1 means site + 1 path segment<br> <kbabbitt> jyasskin and then keyword for fragment, paremeters, etc?<br> <kbabbitt> fantasai: yes<br> <jyasskin> :self-link(path(3)) ?<br> <kbabbitt> keithamus0: how would keywords look? positional parameters?<br> <jyasskin> :self-link(site)<br> <kbabbitt> ... would both be preculded?<br> <flackr> q+<br> <fantasai> :self-link(<integer> | target || query)<br> <kbabbitt> astearns: like self a little more than same<br> <astearns> ack flackr<br> <kbabbitt> flackr: self-link is from the proposal to generate pseudo-element links from current element<br> <jyasskin> q+<br> <kbabbitt> ... in that discussion we talked about approaching it from different direction<br> <kbabbitt> ... if we choose self-link here, we need to make sure we have something that makes sense in that other context<br> <kbabbitt> fantasai: maybe that one can be anchor-link?<br> <fantasai> ::anchor-link ?<br> <kbabbitt> flackr: maybe<br> <astearns> ack jyasskin<br> <kbabbitt> jyasskin: hearing a bunch of concerns from CSS experts<br> <kbabbitt> ... shying away from same-path, same-site, same-origin terminology<br> <kbabbitt> ... where they've been used in other parts of platform, curios why that is<br> <kbabbitt> fantasai: we do want to have an integer parameter, right? once you have that, that gets you site + path without a keyword<br> <kbabbitt> jyasskin: it gets you origin + prefix of path<br> <kbabbitt> fantasai: or a keyword or default value or something that specifies full path<br> <kbabbitt> jyasskin: we still need something that specifies whole query<br> <kbabbitt> astearns: I was a little concerned about adding path and site and origin<br> <kbabbitt> ... not sure authors have those concepts in mind<br> <kbabbitt> fantasai: we can add keywords corresponding to them if that would be more user friendly<br> <kbabbitt> astearns: would it make sense to hold off on this and have a discussion in upcoming f2f<br> <dbaron> (it might also help the discussion to define path and origin for the rest of the group)<br> <kbabbitt> jyasskin and keithamus0 both remark that they won't be able to be there<br> <jyasskin> Re dbaron: and site, query, and fragment.<br> <kbabbitt> keithamus0: I think there's a good direction for the semantics but naming is where we got stalled<br> <dbaron> (oops, I meant to say "site and origin" :-)<br> <kbabbitt> fantasai: suggest we sketch it out and put some suggestions down<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10975#issuecomment-2578250055 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 17:39:11 UTC