Feedback on Blink's text fragment directive proposal

# David Bokan (12 days ago)

Hello webkit-dev,

I'd like to solicit feedback as well as an official position from Webkit on our proposal for the text fragment directive: WICG/ScrollToTextFragment.

In summary: this is a feature that allows authors and users to craft URLs to pages and specify a snippet of text on the page as a subresource (visually highlighting it and scrolling it into view). Analogous to element-id based fragment anchors but for text.

You can try this out today in Chrome Beta by enabling chrome://flags/#enable-text-fragment-anchor. Here's an example link:

en.wikipedia.org/wiki/Uniform_Resource_Identifier#:~:text=An%20optional%20fragment,element%20into%20view

Relevant Links:

WICG/ScrollToTextFragment/blob/master/README.md

Explainer WICG/ScrollToTextFragment/blob/master/README.md

Spec wicg.github.io/ScrollToTextFragment

TAG Review w3ctag/design-reviews#392 (Currently Suspended) Blink Intent Thread groups.google.com/a/chromium.org/forum/#!msg/blink-dev/zlLSxQ9BA8Y/NLbg84m0EAAJ

Issue on Mozilla standards-positions mozilla/standards-positions#194

We've been using the GitHub repo for issue tracking but happy to take feedback (official or otherwise) in any form.

Thank you!

Contact us to advertise here
# Frédéric Wang (4 days ago)

On 02/12/2019 21:22, David Bokan wrote:

Hello webkit-dev,

I'd like to solicit feedback as well as an official position from Webkit on our proposal for the text fragment directive: WICG/ScrollToTextFragment.

In summary: this is a feature that allows authors and users to craft URLs to pages and specify a snippet of text on the page as a subresource (visually highlighting it and scrolling it into view). Analogous to element-id based fragment anchors but for text.

You can try this out today in Chrome Beta by enabling chrome://flags/#enable-text-fragment-anchor. Here's an example link:

en.wikipedia.org/wiki/Uniform_Resource_Identifier#:~:text=An%20optional%20fragment,element%20into%20view

Relevant Links:

WICG/ScrollToTextFragment/blob/master/README.md Explainer WICG/ScrollToTextFragment/blob/master/README.md Spec wicg.github.io/ScrollToTextFragment TAG Review w3ctag/design-reviews#392 (Currently Suspended) Blink Intent Thread groups.google.com/a/chromium.org/forum/#!msg/blink-dev/zlLSxQ9BA8Y/NLbg84m0EAAJ Issue on Mozilla standards-positions mozilla/standards-positions#194

We've been using the GitHub repo for issue tracking but happy to take feedback (official or otherwise) in any form.

Thank you! David


webkit-dev mailing list webkit-dev at lists.webkit.org lists.webkit.org/mailman/listinfo/webkit-dev

Hi,

I think some of the webkit-dev members have already replied on the Blink thread. Just to repeat here, I think the concerns Igalia had regarding the lack of details to implement the algorithm have been addressed in the latest versions of the spec. We haven't checked again if the WPT coverage is good enough now though.

# Maciej Stachowiak (3 days ago)

Apple folks have discussed this internally. In general, we think this is useful functionality to expose. Some points of feedback (let me know if any of these should be filed as an issue against the spec):

(1) We’re concerned about compatibility issues in a world where some browsers support this but not all. Aware browsers will strip :~:, but unaware browsers won’t. I saw that on the blink-dev ItS thread, it was mentioned that at least one site (webmd.com) totally breaks if any fragment ID is exposed to the page. This makes it difficult to create a link that uses this feature but which is safe in all browsers:

- Since there is no feature detection mechanism, it’s hard for a webpage to know whether it should issue such a link. It would have to be based on UA string checks, which is regrettable.
- A link meant for a supporting browser can end up in a non-supporting browser, at the very least by copy paste from the URL field, and perhaps through other features to share a link.

It seems like the spec doesn’t provide a solution for this. We think some form of feature detection would slightly improve the situation. Other than that, We're not sure how to avoid potential breakage. Maybe evangelize WebMD if that’s the only major site that breaks on unexpected fragments?

(2) The portions of this Community Group report that monkey patch other standards (HTML, URL and CSSOM View I think?) should be turned into PRs against those specifications. Monkeypatching other specs is not a good way to build specifications for the long term.

(3) Text fragment trumping a regular fragment ID seems a bit strange. The more natural semantic would be that the text search starts at the fragment, so if there are multiple matches it’s possible to scroll to a more specific one. It’s not clear why the fragment is instead entirely ignored.

We would frame these more as points of concern than opposition to the whole idea, but it seems wise to address them before shipping.

# Nick Burris (3 days ago)

Thanks for the reply! David's away this week, my responses are inline:

(1) We’re concerned about compatibility issues in a world where some browsers support this but not all. Aware browsers will strip :~:, but unaware browsers won’t. I saw that on the blink-dev ItS thread, it was mentioned that at least one site (webmd.com) totally breaks if any fragment ID is exposed to the page. This makes it difficult to create a link that uses this feature but which is safe in all browsers:

- Since there is no feature detection mechanism, it’s hard for a webpage to know whether it should issue such a link. It would have to be based on UA string checks, which is regrettable.
- A link meant for a supporting browser can end up in a non-supporting browser, at the very least by copy paste from the URL field, and perhaps through other features to share a link.

It seems like the spec doesn’t provide a solution for this. We think some form of feature detection would slightly improve the situation. Other than that, We're not sure how to avoid potential breakage. Maybe evangelize WebMD if that’s the only major site that breaks on unexpected fragments?

There is a feature detection mechanism that we have specified and implemented, see #19. Feature detection can be done by checking typeof(window.location.fragmentDirective) == 'object'. Indeed, there is still a compat concern as described in the intent to ship, since these links will exist in the wild. Since WebMD is the only broken site we've come across, I agree it would be good to make sure they're aware of this. I'll reach out.

(2) The portions of this Community Group report that monkey patch other standards (HTML, URL and CSSOM View I think?) should be turned into PRs against those specifications. Monkeypatching other specs is not a good way to build specifications for the long term.

Agreed - we're wrapping up on some smaller remaining issues and our next step is to turn this into PRs.

(3) Text fragment trumping a regular fragment ID seems a bit strange. The more natural semantic would be that the text search starts at the fragment, so if there are multiple matches it’s possible to scroll to a more specific one. It’s not clear why the fragment is instead entirely ignored.

We wanted to keep this simple to ensure links are robust (generally they will be generated algorithmically, where one can ensure the text directive is unique in the page). If we add the dimension of relying on starting at a fragment, that fragment or the text could move in the page and break the link, even if the desired text is still present on the page. Feel free to open a Github issue if you think this is worth discussing more!

Thanks, Nick

# Maciej Stachowiak (a day ago)

On Dec 11, 2019, at 12:48 PM, Nick Burris <nburris at chromium.org> wrote:

Hi Maciej, Thanks for the reply! David's away this week, my responses are inline: (1) We’re concerned about compatibility issues in a world where some browsers support this but not all. Aware browsers will strip :~:, but unaware browsers won’t. I saw that on the blink-dev ItS thread, it was mentioned that at least one site (webmd.com webmd.com) totally breaks if any fragment ID is exposed to the page. This makes it difficult to create a link that uses this feature but which is safe in all browsers:

- Since there is no feature detection mechanism, it’s hard for a webpage to know whether it should issue such a link. It would have to be based on UA string checks, which is regrettable.
- A link meant for a supporting browser can end up in a non-supporting browser, at the very least by copy paste from the URL field, and perhaps through other features to share a link. 

It seems like the spec doesn’t provide a solution for this. We think some form of feature detection would slightly improve the situation. Other than that, We're not sure how to avoid potential breakage. Maybe evangelize WebMD if that’s the only major site that breaks on unexpected fragments?

There is a feature detection mechanism that we have specified and implemented, see #19. Feature detection can be done by checking typeof(window.location.fragmentDirective) == 'object'. Indeed, there is still a compat concern as described in the intent to ship, since these links will exist in the wild. Since WebMD is the only broken site we've come across, I agree it would be good to make sure they're aware of this. I'll reach out.

Great. (Why only add it to the Location interface and not also URL?

(2) The portions of this Community Group report that monkey patch other standards (HTML, URL and CSSOM View I think?) should be turned into PRs against those specifications. Monkeypatching other specs is not a good way to build specifications for the long term.

Agreed - we're wrapping up on some smaller remaining issues and our next step is to turn this into PRs.

Glad to hear it.

(3) Text fragment trumping a regular fragment ID seems a bit strange. The more natural semantic would be that the text search starts at the fragment, so if there are multiple matches it’s possible to scroll to a more specific one. It’s not clear why the fragment is instead entirely ignored.

We wanted to keep this simple to ensure links are robust (generally they will be generated algorithmically, where one can ensure the text directive is unique in the page). If we add the dimension of relying on starting at a fragment, that fragment or the text could move in the page and break the link, even if the desired text is still present on the page. Feel free to open a Github issue if you think this is worth discussing more!

WICG/ScrollToTextFragment#75

Want more features?

Request early access to our private beta of readable email premium.