Intent to Prototype: CSS ::target-text pseudo-element

[Rune Lillesveen]

Contact emails

fut...@chromium.org

Specification

https://drafts.csswg.org/css-pseudo/#selectordef-target-text

Summary

A highlight pseudo element to allow authors to style scroll-to-text fragments different from the default UA highlighting.

Blink component

Blink>CSS

Motivation

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.

Initial public proposal

None

TAG review

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.

TAG review status

Not applicable

Risks

Interoperability and Compatibility

No known compat or interop issues.

Gecko: No signal
WebKit: No signal
Web developers: No signals

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

No, tests will be written during the implementation phase.

Tracking bug

https://crbug.com/1136817

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5689463273422848

This intent message was generated by Chrome Platform Status.

[Rick Byers]

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.

Thanks,

   Rick

--
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.

[Chris Harrelson]

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.)

Chris

 

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.

[Rick Byers]

On Thu, Oct 15, 2020 at 11:26 AM Chris Harrelson <chri...@chromium.org> wrote:

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.)

Fair enough, thanks for the summary of the debate :-)