Hi David,
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.
Regards,
Maciej
> On Dec 2, 2019, at 12:22 PM, David Bokan <bo...@chromium.org> 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:
> https://github.com/WICG/ScrollToTextFragment
> <https://github.com/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: <>
>
> https://en.wikipedia.org/wiki/Uniform_Resource_Identifier#:~:text=An%20optional%20fragment,element%20into%20view
>
> <https://en.wikipedia.org/wiki/Uniform_Resource_Identifier#:~:text=An%20optional%20fragment,element%20into%20view>
>
> Relevant Links:
>
> <https://github.com/WICG/ScrollToTextFragment/blob/master/README.md>
> Explainer <https://github.com/WICG/ScrollToTextFragment/blob/master/README.md>
> Spec <https://wicg.github.io/ScrollToTextFragment/>
> TAG Review <https://github.com/w3ctag/design-reviews/issues/392>
> (Currently Suspended) Blink Intent Thread
> <https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/zlLSxQ9BA8Y/NLbg84m0EAAJ>
> Issue on Mozilla standards-positions
> <https://github.com/mozilla/standards-positions/issues/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@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
