A highlight pseudo element to allow authors to style scroll-to-text fragments different from the default UA highlighting.
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.
Contact emails
fut...@chromium.orgSpecification
https://drafts.csswg.org/css-pseudo/#selectordef-target-textSummary
A highlight pseudo element to allow authors to style scroll-to-text fragments different from the default UA highlighting.
Blink component
Blink>CSSTAG 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 applicableRisks
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 signalsThis 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)?
YesIs this feature fully tested by web-platform-tests?
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/71Tracking bug
https://crbug.com/1136817Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5689463273422848Links to previous Intent discussions
Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/5zkY3e9cpooThis 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.
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.
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.