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

207 views
Skip to first unread message

Rune Lillesveen

unread,
Nov 18, 2020, 8:20:02 AM11/18/20
to blink-dev

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

TAG review

No review request filed. This is a new highlight element, resolved to be added by the CSSWG: https://github.com/w3c/csswg-drafts/issues/5522, and specified in the css-pseudo specification, similar to existing highlight elements.

TAG review status

Not applicable

Risks


Interoperability and Compatibility

Blink is the first to implement this pseudo element. Supporting author styling for the text fragment highlight is an enhancement that shouldn't cause interoperability issues. There are no known compat issues.

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

This feature is based on the Scroll to Text Fragment feature which already ships and uses default UA highlighting for the same fragments that will be targeted by  ::target-text: https://groups.google.com/a/chromium.org/g/blink-dev/c/zlLSxQ9BA8Y/

Blink currently does not support cursors for highlight pseudo elements, but there is an open issue about blocking resource loading for ::target-text to avoid leak of highlighted text via stylesheets: https://github.com/w3c/csswg-drafts/issues/5731. The current implementation in Blink blocks all resource loading for this pseudo element regardless.


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?


Testharness based tests for parsing and computed style:


For reftests, there is currently no support in the wpt framework for rendering the page in a way that allows text fragment highlighting. This needs to be accepted in some form through a WPT RFC[1]. I have an implementation for the Blink port[2], and an implementation for the upstream wpt runner[3], and a set of reference tests[4] utilizing this.

[1] https://github.com/web-platform-tests/rfcs/pull/71


Tracking bug

https://crbug.com/1136817

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5689463273422848

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/5zkY3e9cpoo


This intent message was generated by Chrome Platform Status.

Yoav Weiss

unread,
Nov 19, 2020, 1:21:08 AM11/19/20
to Rune Lillesveen, blink-dev
On Wed, Nov 18, 2020 at 2:19 PM Rune Lillesveen <fut...@chromium.org> wrote:

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

TAG review

No review request filed. This is a new highlight element, resolved to be added by the CSSWG: https://github.com/w3c/csswg-drafts/issues/5522, and specified in the css-pseudo specification, similar to existing highlight elements.

We don't currently have a process carve-out for CSSWG features when we're the first to ship.
Can you file for a review?
 


TAG review status

Not applicable

Risks


Interoperability and Compatibility

Blink is the first to implement this pseudo element. Supporting author styling for the text fragment highlight is an enhancement that shouldn't cause interoperability issues. There are no known compat issues.

Gecko: No signal
WebKit: No signal

Could you ask for signals

Web developers: No signals

This feature is based on the Scroll to Text Fragment feature which already ships and uses default UA highlighting for the same fragments that will be targeted by  ::target-text: https://groups.google.com/a/chromium.org/g/blink-dev/c/zlLSxQ9BA8Y/

Blink currently does not support cursors for highlight pseudo elements, but there is an open issue about blocking resource loading for ::target-text to avoid leak of highlighted text via stylesheets: https://github.com/w3c/csswg-drafts/issues/5731. The current implementation in Blink blocks all resource loading for this pseudo element regardless.


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?


Testharness based tests for parsing and computed style:


For reftests, there is currently no support in the wpt framework for rendering the page in a way that allows text fragment highlighting. This needs to be accepted in some form through a WPT RFC[1]. I have an implementation for the Blink port[2], and an implementation for the upstream wpt runner[3], and a set of reference tests[4] utilizing this.

[1] https://github.com/web-platform-tests/rfcs/pull/71


Tracking bug

https://crbug.com/1136817

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5689463273422848

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/5zkY3e9cpoo


This intent message was generated by Chrome Platform Status.

--
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/CACuPfeRrbVFhSci1CtkMOUT64O1d%2BPDbqkdFGV3tHTBFAef1mQ%40mail.gmail.com.

Manuel Rego Casasnovas

unread,
Nov 19, 2020, 4:05:12 AM11/19/20
to Yoav Weiss, Rune Lillesveen, blink-dev, David Bokan


On 19/11/2020 07:20, Yoav Weiss wrote:
> TAG review
>
> No review request filed. This is a new highlight element, resolved
> to be added by the
> CSSWG: https://github.com/w3c/csswg-drafts/issues/5522, and
> specified in the css-pseudo specification, similar to existing
> highlight elements.
>
>
> We don't currently have a process carve-out for CSSWG features when
> we're the first to ship.
> Can you file for a review?

I have the feeling that this is a small addition, but it's true that
there were some doubts in the intent-to-prototype in the relationship
with "find in page":
https://groups.google.com/a/chromium.org/g/blink-dev/c/5zkY3e9cpoo/m/yfqYt6hYAwAJ

> Gecko: No signal
> WebKit: No signal
>
>
> Could you ask for signals <https://bit.ly/blink-signals>?

More than signals for this specific pseudo-element, I think it'd be more
interesting to revisit the situation regarding scroll-to-text fragment
feature as a whole. Adding bokan@ in CC as he could explain the current
situation. Next is what I found reviewing some links.

Mozilla classified it as "“non-harmful” bordering on harmful (could be
convinced)" around 1 year ago (see
https://github.com/mozilla/standards-positions/issues/194#issuecomment-568581041).

The webkit-dev thread has been active very recently, with Apple showing
some support but also concerns (see
https://lists.webkit.org/pipermail/webkit-dev/2020-November/031572.html).

The TAG review also expressed some concerns back in May (see
https://github.com/w3ctag/design-reviews/issues/392#issuecomment-635036739).

Also it looks like the spec should be eventually be merged into the HTML
spec, if other vendors are happy about it and show implementation
interest. Maybe an option for trying to achieve that consensus would be
to prepare a PR for HTML spec and discuss things there.

This might be a separated this discussion, but as this pseudo-element is
totally related with scroll-to-text fragment, I think it's good to
clarify the situation of the main feature before adding new things on top.

Bye,
Rego

Rune Lillesveen

unread,
Nov 19, 2020, 9:59:17 AM11/19/20
to Manuel Rego Casasnovas, Yoav Weiss, blink-dev, David Bokan
On Thu, Nov 19, 2020 at 10:05 AM Manuel Rego Casasnovas <re...@igalia.com> wrote:


On 19/11/2020 07:20, Yoav Weiss wrote:
>             TAG review
>
>     No review request filed. This is a new highlight element, resolved
>     to be added by the
>     CSSWG: https://github.com/w3c/csswg-drafts/issues/5522, and
>     specified in the css-pseudo specification, similar to existing
>     highlight elements.
>
>
> We don't currently have a process carve-out for CSSWG features when
> we're the first to ship.
> Can you file for a review?

I have the feeling that this is a small addition, but it's true that
there were some doubts in the intent-to-prototype in the relationship
with "find in page":
https://groups.google.com/a/chromium.org/g/blink-dev/c/5zkY3e9cpoo/m/yfqYt6hYAwAJ

>     Gecko: No signal
>     WebKit: No signal
>
>
> Could you ask for signals <https://bit.ly/blink-signals>?

More than signals for this specific pseudo-element, I think it'd be more
interesting to revisit the situation regarding scroll-to-text fragment
feature as a whole. Adding bokan@ in CC as he could explain the current
situation. Next is what I found reviewing some links.

Yes, the scroll-to-text fragment itself seems to be the controversial part.

Mozilla classified it as "“non-harmful” bordering on harmful (could be
convinced)" around 1 year ago (see
https://github.com/mozilla/standards-positions/issues/194#issuecomment-568581041).

The webkit-dev thread has been active very recently, with Apple showing
some support but also concerns (see
https://lists.webkit.org/pipermail/webkit-dev/2020-November/031572.html).

The TAG review also expressed some concerns back in May (see
https://github.com/w3ctag/design-reviews/issues/392#issuecomment-635036739).

Also it looks like the spec should be eventually be merged into the HTML
spec, if other vendors are happy about it and show implementation
interest. Maybe an option for trying to achieve that consensus would be
to prepare a PR for HTML spec and discuss things there.

This might be a separated this discussion, but as this pseudo-element is
totally related with scroll-to-text fragment, I think it's good to
clarify the situation of the main feature before adding new things on top.

Makes sense.

Yoav Weiss

unread,
Nov 23, 2020, 2:53:58 AM11/23/20
to Rune Lillesveen, Manuel Rego Casasnovas, blink-dev, David Bokan
On Thu, Nov 19, 2020 at 3:59 PM Rune Lillesveen <fut...@chromium.org> wrote:
On Thu, Nov 19, 2020 at 10:05 AM Manuel Rego Casasnovas <re...@igalia.com> wrote:


On 19/11/2020 07:20, Yoav Weiss wrote:
>             TAG review
>
>     No review request filed. This is a new highlight element, resolved
>     to be added by the
>     CSSWG: https://github.com/w3c/csswg-drafts/issues/5522, and
>     specified in the css-pseudo specification, similar to existing
>     highlight elements.
>
>
> We don't currently have a process carve-out for CSSWG features when
> we're the first to ship.
> Can you file for a review?

I have the feeling that this is a small addition, but it's true that
there were some doubts in the intent-to-prototype in the relationship
with "find in page":
https://groups.google.com/a/chromium.org/g/blink-dev/c/5zkY3e9cpoo/m/yfqYt6hYAwAJ

>     Gecko: No signal
>     WebKit: No signal
>
>
> Could you ask for signals <https://bit.ly/blink-signals>?

More than signals for this specific pseudo-element, I think it'd be more
interesting to revisit the situation regarding scroll-to-text fragment
feature as a whole. Adding bokan@ in CC as he could explain the current
situation. Next is what I found reviewing some links.

Yes, the scroll-to-text fragment itself seems to be the controversial part.
 
Maybe the best path forward is to update the scroll-to-text signal requests as well as the TAG review with this additional style, and see if anyone has specific feedback on it, beyond what's already discussed at the CSSWG.

Rune Lillesveen

unread,
Nov 23, 2020, 7:06:11 AM11/23/20
to Yoav Weiss, Manuel Rego Casasnovas, blink-dev, David Bokan

David Bokan

unread,
Nov 23, 2020, 2:22:51 PM11/23/20
to Rune Lillesveen, Yoav Weiss, Manuel Rego Casasnovas, blink-dev
I've pinged the Mozilla standards-position thread as well with updates to their more general points. Will update if anything comes of that.

I'm also continuing to follow up on the webkit-dev thread but still waiting on the latest round of feedback as I believe I've addressed all their so-far stated concerns.

yo...@yoav.ws

unread,
Dec 3, 2020, 3:12:55 PM12/3/20
to blink-dev, David Bokan, yo...@yoav.ws, Manuel Rego, blink-dev, Rune Lillesveen
LGTM1 

Thanks for notifying the relevant threads!

Manuel Rego Casasnovas

unread,
Dec 3, 2020, 3:14:35 PM12/3/20
to David Bokan, Rune Lillesveen, Yoav Weiss, blink-dev
Thanks for the updates. I think the concerns are on the main feature and
not this specific pseudo-element.

So LGTM1 from me.

Bye,
Rego

On 23/11/2020 20:22, 'David Bokan' via blink-dev wrote:
> I've pinged the Mozilla standards-position thread as well with updates
> to their more general points. Will update if anything comes of that.
>
> I'm also continuing to follow up on the webkit-dev thread but still
> waiting on the latest round of feedback as I believe I've addressed all
> their so-far stated concerns.
>
> On Mon, Nov 23, 2020 at 7:06 AM Rune Lillesveen <fut...@chromium.org
> <mailto:fut...@chromium.org>> wrote:
>
> On Mon, Nov 23, 2020 at 8:53 AM Yoav Weiss <yo...@yoav.ws
> <mailto:yo...@yoav.ws>> wrote:
>
>
>
> On Thu, Nov 19, 2020 at 3:59 PM Rune Lillesveen
> <fut...@chromium.org <mailto:fut...@chromium.org>> wrote:
>
> On Thu, Nov 19, 2020 at 10:05 AM Manuel Rego Casasnovas
> <re...@igalia.com <mailto:re...@igalia.com>> wrote:
>
>
>
> On 19/11/2020 07:20, Yoav Weiss wrote:
> >             TAG review
> >
> >     No review request filed. This is a new highlight
> element, resolved
> >     to be added by the
> >     CSSWG:
> https://github.com/w3c/csswg-drafts/issues/5522
> <https://github.com/w3c/csswg-drafts/issues/5522>, and
> <https://lists.webkit.org/pipermail/webkit-dev/2020-November/031610.html>
>
> --
> 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
> <mailto:blink-dev+...@chromium.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANMmsAt7nzx9BpLMfc-RjmvgdcQ7914imTfZVutWYfFWVvbFUQ%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANMmsAt7nzx9BpLMfc-RjmvgdcQ7914imTfZVutWYfFWVvbFUQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.

Manuel Rego Casasnovas

unread,
Dec 3, 2020, 3:15:39 PM12/3/20
to David Bokan, Rune Lillesveen, Yoav Weiss, blink-dev


On 03/12/2020 21:14, Manuel Rego Casasnovas wrote:
> Thanks for the updates. I think the concerns are on the main feature and
> not this specific pseudo-element.
>
> So LGTM1 from me.

Oops, this should be counted as LGTM2, after Yoav's mail.

Daniel Bratell

unread,
Dec 3, 2020, 3:42:40 PM12/3/20
to Manuel Rego Casasnovas, David Bokan, Rune Lillesveen, Yoav Weiss, blink-dev
LGTM3

/Daniel
Reply all
Reply to author
Forward
0 new messages