- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 29 Jan 2025 22:11:53 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-highlight-api] Should pseudo-classes work with Custom Highlights`, and agreed to the following:
* `RESOLVED: We intend to allow user interaction pseudos after highlight pseudos`
<details><summary>The full IRC log of that discussion</summary>
<kbabbitt> schenney: point made is taht you may want difference selection or highlight<br>
<kbabbitt> ... if element is hovered vs not<br>
<kbabbitt> ... or matched in any other selector that modifies state based on actions<br>
<kbabbitt> ... proposal is to allow some syntax e.g. article::highlight::hover<br>
<lea> q?<br>
<kbabbitt> ... which is currently not allowed<br>
<TabAtkins> this is in fact already allowed <https://drafts.csswg.org/selectors/#pseudo-element-states><br>
<kbabbitt> ... comments o n issue that this is a good idea<br>
<kbabbitt> ... propose using standard syntax<br>
<TabAtkins> q+<br>
<kbabbitt> ... article::highlight::hover<br>
<kbabbitt> ... don't know if we need to restrict the set or not<br>
<kbabbitt> ... but support the idea, it has clear use cases<br>
<emilio> q+<br>
<astearns> ack TabAtkins<br>
<fantasai> https://www.w3.org/TR/selectors-4/#pseudo-element-states<br>
<kbabbitt> TabAtkins: this is already allowed by spec<br>
<fantasai> "A pseudo-element may be immediately followed by any combination of the user action pseudo-classes, in which case the pseudo-element is represented only when it is in the corresponding state. Whether these pseudo-classes can match on the pseudo-element depends on the pseudo-class and pseudo-element’s definitions: unless otherwise-specified, none of these pseudo-classes will match on the pseudo-element."<br>
<kbabbitt> ... selectors spec says that user action pseudos are allowed after any pseudo element<br>
<emilio> q+ later<br>
<kbabbitt> plus combination pseudos e.g. where<br>
<emilio> ack emilio<br>
<kbabbitt> s/plus/TabAtkins: plus/<br>
<kbabbitt> ... so this should already work<br>
<astearns> ack fantasai<br>
<Zakim> fantasai, you wanted to correct TabAtkins ;)<br>
<schenney> q+<br>
<kbabbitt> fantasai: to be more precise, we currently say that user action pseudo classes are valid<br>
<kbabbitt> ... but whether they match needs to be defined in pseudo elem definition<br>
<kbabbitt> emilio: these pseudos don't have boxes per se<br>
<kbabbitt> TabAtkins: true<br>
<astearns> ack emilio<br>
<florian> q<br>
<florian> q?<br>
<kbabbitt> emilio: what is the expected behavior when ... assuming you make this work...<br>
<kbabbitt> ... when you hover over a highlight that may look contiguous but not be in the DOM<br>
<kbabbitt> ... you expect hover to apply to whole highlight, to fragment hovered...<br>
<kbabbitt> ... e.g. in spell check I'd expect each region to be individually hoverable<br>
<kbabbitt> ... so hovering over one word woud onlyupdate style on that word<br>
<kbabbitt> TabAtkins: those are separate pseudos<br>
<kbabbitt> emilio: but same highlight<br>
<kbabbitt> schenney: that's second part of issue<br>
<kbabbitt> ... highlight with a particular name applied to multiple ragnes<br>
<kbabbitt> ... e.g. code highlighting, variable highlight applied to all variables<br>
<kbabbitt> ... want to control whether hover affects one or all<br>
<kbabbitt> ... use cases for both<br>
<bramus> q?<br>
<kbabbitt> ... there is a proposal for adding another pseudo called range<br>
<kbabbitt> ... highlight::hover::range<br>
<kbabbitt> ... woudl apply to highlight everything<br>
<kbabbitt> ... without ::range would just affect the one being hovered<br>
<kbabbitt> TabAtkins: other way around<br>
<kbabbitt> schenney: that's also in there and we should consider<br>
<kbabbitt> emilio: if you're doing visual selection you may have multiple ranges<br>
<kbabbitt> ... I'm not sure how it would work for the use case you described<br>
<kbabbitt> ... when you hover over a variable, you want all uses of that variable to be highlighted<br>
<kbabbitt> ... but not all uses of all variables<br>
<kbabbitt> ... would you have one highlight for each token?<br>
<kbabbitt> schenney: good point<br>
<kbabbitt> emilio: so that use case wouldn't be solved<br>
<kbabbitt> florian: you could have a separate highlight per variable<br>
<TabAtkins> like, in "foo[bar<i>baz</i>]" (where [] indicates the highlight), that's two *fragments* but presumably one *highlight* and one *range*, right?<br>
<kbabbitt> emilio: but then you'd need separate styles<br>
<kbabbitt> florian: might be how you set it up if that's what you want to do<br>
<kbabbitt> schenney: you could go to js if you need this more complex behavior<br>
<kbabbitt> emilio: but you'd need some sort of toggle for this to work<br>
<kbabbitt> ... idea is that dom is just plain text<br>
<kbabbitt> ... so you can't just put classes around it<br>
<bramus> q+<br>
<kbabbitt> ... to me it seems like enough questions that proposal should be refined<br>
<astearns> ack schenney<br>
<kbabbitt> schenney: I would be fine resolving that we implement and update spec necessary to support selection::hover<br>
<kbabbitt> ... with separate issue for what to do with highlights<br>
<kbabbitt> bramus: regarding last use case emilio mentioned:<br>
<astearns> ack bramus<br>
<kbabbitt> ... a while ago we discussed incubating custom highlight pointer events<br>
<TabAtkins> yeah, the ::range idea from <https://github.com/w3c/csswg-drafts/issues/7647#issuecomment-2442125272> doens't seem unreasonable to me<br>
<kbabbitt> ... could solve this, detect if yore hovering a highlight<br>
<kbabbitt> emilio: I think we added or decided on adding some elementFromPoint kind of API<br>
<kbabbitt> ...main question is: when you have a single ... you need some sort of logical range concept<br>
<kbabbitt> ... or at the very least, if you have a single DOM range split across lines<br>
<kbabbitt> ... or across elements<br>
<TabAtkins> ::highlight(foo):hover {...} styles all ::highlight(foo) highlights when one is hovered, ::highlight(foo)::range:hover {...} styles only the one Range that is actually being hovered<br>
<kbabbitt> .. or if you have shadow DOM or multiple DOM ranges<br>
<kbabbitt> ... but one logical visual range<br>
<kbabbitt> ... those two things should behave as a unit<br>
<kbabbitt> ... don't see how you can do that just with CSS<br>
<kbabbitt> ... I would think about implementing this use case with two kinds of custom highlightws<br>
<kbabbitt> .... highlight variable and highlight variable hover<br>
<kbabbitt> ... using script to tweak the ranges that are hovered<br>
<kbabbitt> ... but you need some sort of what range is my pointer over<br>
<lea> TabAtkins: I don't see how. `a:hover` doesn't highlight all links when one is hovered<br>
<kbabbitt> ... or what ranges intersect with this point<br>
<kbabbitt> ... I thnk we resolved on that but don't recall detials<br>
<kbabbitt> ... you could use mouse move<br>
<kbabbitt> ... or implement this using script<br>
<TabAtkins> lea, th eidea is that the ::highlight(foo) *is* the entire set at once (rather than N distinct pseudo-elements)<br>
<kbabbitt> florian: if you hpver pver highlight pseudo that has ll variables<br>
<kbabbitt> ... but only highlight x<br>
<kbabbitt> ... instead of having premade x, y, z<br>
<kbabbitt> emilio: main issue is I don't see how you can make ... other than hovering any range highlights ll rangees<br>
<kbabbitt> ... whcih is not what people expect<br>
<kbabbitt> ... I don't see how you get right behavior in some common cases<br>
<lea> TabAtkins: is that a distinction that the current syntax exposes in any way? If not, perhaps we should revisit that. Maybe it should be N distinct pseudo-elements?<br>
<kbabbitt> ... I would prefer to make sure we have right APIs to implement this kind of stuff<br>
<schenney> q+<br>
<kbabbitt> ... rather than allow hover and make that mean something likely not what author wants<br>
<astearns> ack dbaron<br>
<kbabbitt> dbaron: if we're supporting things like hover we need to define what the rectangles that matter are<br>
<TabAtkins> lea, it's currently not exposed, somewhat intentionally. (this ties into what emilio was talking about, where even when you *do* have one "logical" highlight, it might still have to be multiple Range objects)<br>
<kbabbitt> ... guessing same bounds as painted by background property<br>
<kbabbitt> ... also fantasai said earlier that I agree with what the spec is, but cannot find it...<br>
<kbabbitt> ...which is that user action pseudo classes are allowed after a bunch of kinds of pseudo elements<br>
<fantasai> https://drafts.csswg.org/selectors-4/#pseudo-element-states<br>
<fantasai> Still there ^<br>
<lea> I suspect the mental model of authors is closer to the N pseudo-elements one. fwiw `::range` seems _incredibly_ confusing.<br>
<astearns> ack schenney<br>
<kbabbitt> schenney: having heard the discussion, to dbaron's point, rectangle that triggers hover would trigger pseudo styling<br>
<kbabbitt> dbaron: don't think that's what you want<br>
<kbabbitt> ... if you want hover style for selection<br>
<kbabbitt> .. you have hello world and user hioghlight llo<br>
<emilio> Right<br>
<kbabbitt> ... mouse over hello, don't want to highlight world<br>
<TabAtkins> in particular, the common case we want to address is a big plaintext chunk of code with highlights sprinkled over it<br>
<kbabbitt> schenney: what I suggest is we try and implement and see what comes up<br>
<TabAtkins> so it does need to be hover over the range's own "rectangle"<br>
<emilio> q+<br>
<emilio> q-<br>
<dbaron> s/mouse over hello, don't want to highlight world/mouse over world, don't want llo to have the hover style/<br>
<kbabbitt> fantasai: for figuring out if you're hovering, area we use is what gets painted by highlight background<br>
<astearns> ack fantasai<br>
<Zakim> fantasai, you wanted to react to schenney to clairify<br>
<kbabbitt> ... there are restrictions in spedc that prevent author from depending on where that background is painted<br>
<kbabbitt> ... but for triggering a hover it's fine<br>
<TabAtkins> q+<br>
<fantasai> s/where/exactly where/<br>
<emilio> q+ to say that all behaviors here are implementable, but not sure if useful :)<br>
<astearns> ack lea<br>
<kbabbitt> lea: +1 to the feature, utility seem sobvious<br>
<kbabbitt> ... strongly hopinh we can find a way to use current syntax<br>
<kbabbitt> ... e.g. ::range on pseudo element looks confusing<br>
<kbabbitt> ... authors will copy-paste without undertstanding<br>
<kbabbitt> ... worries me how many of these we add to spec<br>
<kbabbitt> ... it turns out the reason we need this inthe frst place is because highlight pseudo represents entire set at once<br>
<kbabbitt> ... but this distinction is not exposed<br>
<kbabbitt> ... so we could revisit<br>
<TabAtkins> (my q+ is also about this topic fwiw)<br>
<kbabbitt> ... and say it applies to range and not set of ranges<br>
<kbabbitt> ... if that's more understandable maybe a good way forward<br>
<astearns> ack TabAtkins<br>
<kbabbitt> TabAtkins: the reason highlight pseudo applies to full set of ranges is because of what fantasai said<br>
<kbabbitt> ... we purposely limit how much we expose exact composition of the highlight boxes<br>
<kbabbitt> ... one logical highlight range might end up having to be implemented as multiple range objects<br>
<kbabbitt> ... exposing that distinction to authors such taht you can't highlight entire range at once isn't great<br>
<kbabbitt> ... also not great that you'll always highlight all ranges even if they're multiple distinct things<br>
<kbabbitt> ... that's why I lean towards idea that we have the ability to distinguish between all highlights at once with a given name ..<br>
<florian> q?<br>
<florian> q+<br>
<kbabbitt> ... and indivudal ranges with that highlight name plus ability to logically group ranges in JS API<br>
<kbabbitt> astearns: may be that we can resolve our intent to allow hover and such<br>
<kbabbitt> ... but working out how all of this works may be better taken back to issue<br>
<astearns> ack emilio<br>
<Zakim> emilio, you wanted to say that all behaviors here are implementable, but not sure if useful :)<br>
<kbabbitt> emilio: the only logical sensible default I see is highlighting all the ranges<br>
<kbabbitt> ...again there are use case where that's not wanted<br>
<kbabbitt> ... personal preference is to first figure out how to do what authors want<br>
<kbabbitt> ... highlighting only one range doesn't get you right behavior in some common cases<br>
<astearns> ack dbaron<br>
<kbabbitt> dbaron: my intuition is the opposite of emilio's<br>
<kbabbitt> ... highlighting jut one range is what people want most of the time<br>
<kbabbitt> ... I might have different sense of use cases<br>
<kbabbitt> ... other possibility althugh it's not great<br>
<kbabbitt> ... there's an underlying model where there are separate highlights<br>
<kbabbitt> ... that can consist of multiple ranges<br>
<kbabbitt> ... but not expose that complexity through JS APIs<br>
<kbabbitt> ... authors could use that if built in highlights like selection work that way<br>
<kbabbitt> ... even if we don't want to expose complexity<br>
<kbabbitt> ... sometimes selection might generate multiple ranges<br>
<kbabbitt> emilio: my intuition of what authors want might be same as dbaron's<br>
<kbabbitt> ... hovering one word to highlight that word<br>
<kbabbitt> ... but in selection case it's more tricky<br>
<kbabbitt> ... ::selection:hover<br>
<kbabbitt> ... with disjoint selection I would expect hover to apply to all of selection<br>
<kbabbitt> dbaron: I think it might make sense to model things like bidi visual selection using the thing I just described<br>
<kbabbitt> emilio: my concern with making it behave single range by default is it breaks those sorts of use cases<br>
<kbabbitt> ... anything selecting across shadow boundaries needs multiple ranges<br>
<kbabbitt> ... there are situations where right behavior is selecting multiple ranges<br>
<kbabbitt> ... that's why I mentioned that the only somewhat reasonable default is to highlight multiple ranges if you have hover<br>
<kbabbitt> ... even if that's not what authors want in some cases<br>
<astearns> ack fantasai<br>
<kbabbitt> fantasai: one thing that's awkward is p::selection only pertains to part of paragraph taht's not inside any other element<br>
<kbabbitt> ... but that's not going to be how authors perceive it<br>
<kbabbitt> ... so we have to somehow propagate hover state up through highlight pseudos<br>
<kbabbitt> ... to get highlight to work as expected<br>
<astearns> ack florian<br>
<dbaron> maybe it propagates the same way :hover state on elements does?<br>
<kbabbitt> florian: I was going in same direction as dbaron<br>
<kbabbitt> ... and a bhit further, expose in JS API<br>
<kbabbitt> ... could intrudoce new type of range which is composite range<br>
<kbabbitt> ... register that as a chunk<br>
<kbabbitt> ...any range registered in a highlight gets highlighed one by one<br>
<kbabbitt> ... but the thing fantasai just said, if I understood, threw me off<br>
<kbabbitt> ... if they're scoping p::highight:hover what are they going after?<br>
<kbabbitt> ... maybe it just works out but I haven't worked it out yet<br>
<kbabbitt> astearns: can we resolve our intent to allow hover and other user interaction pseudos<br>
<kbabbitt> ...but go back to issue to figure out details?<br>
<kbabbitt> schenney: works for me<br>
<kbabbitt> Proposed: We intend to allow user interaction pseudos after highlight pseudos<br>
<kbabbitt> RESOLVED: We intend to allow user interaction pseudos after highlight pseudos<br>
<dbaron> https://w3c.github.io/selection-api/#dom-selection<br>
<dbaron> sort of looks like the multiple-Range API already!<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7647#issuecomment-2622975763 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 29 January 2025 22:11:54 UTC