https://drafts.csswg.org/css-pseudo/#selectordef-target-text
A highlight pseudo element to allow authors to style scroll-to-text fragments different from the default UA highlighting.
Authors should be able to style the highlighted text from scroll-to-text fragments to have the style match that of the rest of the page. See https://chromestatus.com/feature/4733392803332096 for the scroll-to-text feature.
None
No review request filed. This is a new highlight pseudo element, resolved to be added by the CSSWG, and specified in the css-pseudo specification, similar to existing highlight elements.
Not applicable
Yes
No, tests will be written during the implementation phase.
https://chromestatus.com/feature/5689463273422848
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACuPfeQExMNbir5PvoGkYXWpvu-Ckg6CnKfRwjLGyBsP_xrHTg%40mail.gmail.com.
I'm excited to see this. Can you link to the spec issue / PR where the design was / is being discussed?
I'm specifically curious about the tradeoffs between specifically targeting fragment text vs. including text found via UA features like "find in page". Are they different somehow?
It's still not possible to change the color of the "find in page" highlight right? IIRC the main legitimate use cases for target-text were cases where the highlighting was illegible (eg. background color already yellow or orange), so I would have expected the same problem to exist with "find in page" use cases.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-GF-GX0Ue1kULfqFNfvH5sBS2%2BfvYYBNNvdcDabtXrLA%40mail.gmail.com.
On Thu, Oct 15, 2020 at 8:19 AM Rick Byers <rby...@chromium.org> wrote:I'm excited to see this. Can you link to the spec issue / PR where the design was / is being discussed?https://github.com/w3c/csswg-drafts/issues/5233 is the original issue; https://github.com/w3c/csswg-drafts/issues/5522 is a breakout issue for just text fragments.I'm specifically curious about the tradeoffs between specifically targeting fragment text vs. including text found via UA features like "find in page". Are they different somehow?One way they are different in that UAs often have somewhat complicated UIs for find-in-pagepage. Another is that find in page has the concept of active vs non-active matches. Discussion in issue 5233 went through a lot of discussion of the differences and their potential implications for a new pseudo-element. Given the significantly greater complexity of find-in-page at present, we went with a design just for text fragments instead, at least for now.It's still not possible to change the color of the "find in page" highlight right? IIRC the main legitimate use cases for target-text were cases where the highlighting was illegible (eg. background color already yellow or orange), so I would have expected the same problem to exist with "find in page" use cases.A third difference between text fragments and find-in-page is that the former happens automatically when navigating, whereas the latter is initiated by the user. This is one reason I think there are more complaints about the yellow text fragment highlight than find-in-page colors, because the user and developer probably wouldn't think the latter is "part of the page". (Or it could be just that find-in-page has been around forever, hard to say for sure.)