- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 07 May 2025 16:24:43 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-highlight-api] Should highlightsFromPoint also return ranges under the hit point?`, and agreed to the following: * `RESOLVED: Accept the proposal in the issue.` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> fernando: this is about the return value of highlightsFromPoint<br> <TabAtkins> fernando: original proposal for for highlights that are hit under a certain point<br> <TabAtkins> fernando: after some examples, might be useful to return the *ranges* hit for every highlight that is hit, too<br> <TabAtkins> fernando: so proposing to return, rather than a sequence of highlights, a sequence of highlighthitresults that are the highlight and the range<br> <TabAtkins> fernando: this is useful fro spell checkers, custom find in page, etc where you need to know what word you're interacting with<br> <TabAtkins> fernando: so i'd like to hear your thoughts<br> <emilio> q+<br> <Rossen5> ack ChrisL<br> <Rossen5> ack emilio<br> <schenney> q+<br> <TabAtkins> emilio: seems fine overall<br> <TabAtkins> emilio: is the idea that... presuambly we're not synthesizing ranges, we return the actual Range objects right? just filtering down the ranges that the highlight currently has?<br> <TabAtkins> fernando: yes, correct<br> <TabAtkins> emilio: okay, i think we had similar discussions (unsure if this api or another one), the concern was that it wasn't clear exactly what ranges to return<br> <TabAtkins> emilio: but as long as we're just filtering the existing ranges from the highlight, that's fine<br> <Rossen5> q+ to ask about overlapping ranges<br> <TabAtkins> emilio: one concern is you can't early-out as soon as you hit a highlight, you do need to iterate over the ranges<br> <TabAtkins> emilio: might be a littl eanoying to have to do that work if the user doesn't need it<br> <TabAtkins> emilio: but if you're clickign on one misspelled word, having to walk all the ranges associated with that highlight in author-land seems bad<br> <TabAtkins> emilio: so i think it's probably fine, just a bit unfortunate you'll still have to pay for it if all you need is the highlight itself<br> <TabAtkins> emilio: but the commonc ase is not hitting them anyway<br> <Rossen5> ack schenney<br> <TabAtkins> schenney: i think the issue you're remembering is related to the pseudo-classes on pseudo-elements, if you hovered a [missed due to overtalk]<br> <TabAtkins> emilio: that's right<br> <TabAtkins> schenney: if you set a highlight with a particuilar name, with multiple sub ranges, and you click on any one range you'll get all the ranges for that highlight? or just the ones under the hit point<br> <TabAtkins> fernando: the latter, only the ranges that were hit<br> <Rossen5> q-<br> <TabAtkins> fernando: you can already retrieve all the associated ranges just from the highlight directly<br> <TabAtkins> schenney: okay, i think that addresses the concern i raised on the intent. i'm happy, then<br> <Rossen5> ack fantasai<br> <Zakim> fantasai, you wanted to ask about a11y<br> <TabAtkins> fantasai: two questions<br> <TabAtkins> fantasai: for emilio's question, would it make sense to have two different apis? one that returns the highlight and one that filters the ranges?<br> <dandclark> q+<br> <TabAtkins> fantasai: if there's use-cases for just getting the highlight, the extra compute doesn't have to be done<br> <TabAtkins> fantasai: second, seems like we're envisioning some sophisticated interfaces being built. is there a plan for how this would work for keyboard users?<br> <TabAtkins> fernando: for first, currently there's no extra compute, we already have to go thru the ranges to hit-test anyway<br> <TabAtkins> fernando: but maybe there's another impl that can be done where it's an extra cost<br> <TabAtkins> fernando: for second, could you repeat?<br> <emilio> q+<br> <TabAtkins> fantasai: [repeats the question]<br> <TabAtkins> fernando: the API takes two coords, x y, that can be done with keyboard if you get the caret position<br> <TabAtkins> fantasai: that sounds a lot more complicated. do we think authors will acutally do that?<br> <schenney> q+<br> <TabAtkins> q+<br> <TabAtkins> fernando: hm, that could be something to think about. but i think this is similar to elementsFromPoint... was this a concern there as well?<br> <TabAtkins> fernando: would be interested to know how that api deals with it, it seems like the same idea<br> <TabAtkins> fantasai: so i suggest the spec should include a practical example with this API that shows off keyboard usage<br> <TabAtkins> fantasai: if that ends up being unreasonably complicated, we should solve that somehow<br> <TabAtkins> fantasai: whether that's altering this api or adding a new one<br> <fantasai> But in any case the spec should show off best practices<br> <TabAtkins> emilio: i think the keyboard interface is a lot simploer, you don't need to compute the caret position. the selection api has ranges<br> <TabAtkins> emilio: at least the range api does have an isPointInRange or something<br> <Rossen5> ack emilio<br> <TabAtkins> emilio: so it's actually easier to imlement for keyboard users, they just iterate over the highlights, then the ranges, and see if the caret point is in there<br> <TabAtkins> emilio: also i don't think AbstractRange has that API, only the live ranges. i think we should fix that.<br> <TabAtkins> fantasai: so yeah, i think the spec should just have an example of how to do this properly, so people know how to do it<br> <Rossen5> ack dandclark<br> <TabAtkins> dandclark: i think we shoudl also take a look at what devs are doing now<br> <TabAtkins> dandclark: we're just taking this ability into the engine. should look and see if that's already keyboard accessible.<br> <TabAtkins> fantasai: think the other point from fantasai about two APIs - wasn't sure if we were talkinga bout extra work from author or engine. either case, i think it makes more sense to be just one API.<br> <TabAtkins> s/fantasai/dandclark/<br> <emilio> q+<br> <TabAtkins> dandclark: from engine side we're doing the work anyway, from dev side fi they're getting it all together anyway they can just ignore one<br> <Rossen5> ack schenney<br> <dandclark> q+<br> <TabAtkins> schenney: on the a11y issues, i think it's a broader issue. no way to know in the a11y data if a word or string is highlighted, i think<br> <TabAtkins> schenney: i'll look into that and raise an issue if that is a problem<br> <fantasai> scribe+<br> <TabAtkins> dandclark: exposing a11y of highlights is something we looked at. different platforms have different ways of exposing it, but OSes do have wayss to expose grammar/spelling/emphasis<br> <TabAtkins> dandclark: details escape me, they're different between paltforms, but we do expose things to a degree.<br> <Rossen5> ack TabAtkins<br> <flackr> q+ to ask about generic api combining things you might want to hit test<br> <fantasai> TabAtkins: Want to emphasize that this is essentially identical to elementsFromPoint()<br> <dandclark> TabAtkins: emphasizing that this is identical to elementsFromPoint. Should ensure it's solvable, add example, but that shouldn't be a blocker<br> <dandclark> ...it's doing the same things this other thing is already doing, and that thing is good on its own merits<br> <dandclark> q-<br> <Rossen5> ack emilio<br> <TabAtkins> emilio: one clarification on perf arg<br> <TabAtkins> emilio: i agree it's probably not worth two APIs, the common case needs the hit range anyway<br> <TabAtkins> emilio: my point is just that right now you could stop once you hit *one* range that works, you don't nhave to iterate all the rest<br> <emilio> https://github.com/whatwg/dom/issues/591<br> <TabAtkins> emilio: but i think in the common case you'll do it anyway, so no need for a separate api<br> <TabAtkins> emilio: for keyboards, i just linked to a DOM issue moving a lot of stuff from Range to AbstractRange. should move a lot of the test stuff<br> <TabAtkins> flackr: dunno if i mentioned it in this group, but i said it in the intent thread. i think we need to think about a more generic hit-testing api that combines the variosu things<br> <Rossen5> ack flackr<br> <Zakim> flackr, you wanted to ask about generic api combining things you might want to hit test<br> <TabAtkins> flackr: i think highlightFromPoint, you onlly get a highlight if the element with the highlight woudl have bene hit<br> <TabAtkins> flackr: but elementsFromPoint gives you the list in order<br> <TabAtkins> flackr: could be useful to ahve elements and highlights together, in order. maybe with options to let you test for pointer-events:none, etc<br> <TabAtkins> flackr: so this doesn't need to block this work, but we should pursue a more general hit-test API so we can deal with interleaved things<br> <TabAtkins> +1<br> <TabAtkins> Rossen5: so it sounds like we're agreeing with the proposal<br> <TabAtkins> Rossen5: there's good feedback i'm hoping editors will take back to the spec, for added clarity if nothing else<br> <TabAtkins> Rossen5: how it's different from rangesFromPoint(), how it addresses keyboard a11y, etc<br> <TabAtkins> Rossen5: but that said, any objections to the proposal as outlined?<br> <TabAtkins> RESOLVED: Accept the proposal in the issue.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12031#issuecomment-2859227004 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 7 May 2025 16:24:43 UTC