(Note - this is an extension to the already shipped "scroll-to-text"/text directive feature) Contact [email protected], [email protected]
Explainer https://github.com/WICG/scroll-to-text-fragment/blob/main/fragment-directive-api.md SpecificationTODO: None yet SummaryWe propose exposing JavaScript APIs for working programmatically with text directives (a.k.a. Scroll-to-text highlights) The new API enables authors to better work with text directives when they are used to navigate to their page: - Exposes the previously unavailable text directive (everything in the URL fragment after “:~:”) in the URL to page authors via a structured API - Exposes the DOM Range being highlighting - Allows programmatically adding and removing text directive highlights It also enables authors to *create* deep link navigations: - Allows the browser to generate a text directive URL from an arbitrary DOM Range, making it easier for authors to create deep links to their own content. Blink componentBlink>Scroll <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EScroll> MotivationWe’ve seen a few use cases crop up for working with text fragments: - Being able to attach commentary/UI to a targeted text range [received as part of Mozilla’s feedback on the core text directive <https://github.com/mozilla/standards-positions/issues/194#:~:text=prototyping%20on%20balance.-,The%20marginalia%20use%20case%20described%20at,-https%3A//indieweb.org> feature] - Tools that wish to create text directive links of their own find it difficult <https://github.com/WICG/scroll-to-text-fragment/issues/160> since the rules around matching text are rather complicated <https://wicg.github.io/scroll-to-text-fragment/#find-a-range-from-a-text-directive> (necessarily so). This API allows such tools/pages to give the browser a Range and receive a text directive string in return. - Pages that use <https://github.com/ampproject/amphtml/issues/32139> a cross-origin iframe to host content and want to enable text highlighting can coordinate between the embedder and embeddee by passing the text directive string to the embeddee and having it set the text directive on itself. The text directive is currently exposed (accidentally) on the performance API <http://crbug.com/1096983> which pages can to read to achieve this behavior. An explicit API would allow us to remove the performance API hack which may enable more privacy-sensitive features <https://github.com/bokand/web-annotations/blob/main/URL-based-annotation.md> to use the fragment directive mechanism. Initial public proposal https://github.com/WICG/scroll-to-text-fragment/issues/160 Search tagstext <https://chromestatus.com/features#tags:text>, scroll <https://chromestatus.com/features#tags:scroll>, fragment <https://chromestatus.com/features#tags:fragment>, directive <https://chromestatus.com/features#tags:directive>, fragmentDirective <https://chromestatus.com/features#tags:fragmentDirective>, document <https://chromestatus.com/features#tags:document> TAG reviewTODO: None yet TAG review statusPending Risks No compat risk as this is a new API. Usual interop risk of other vendors not implementing. Given this is extending a feature other vendors don’t yet implement, there’s some risk here this makes it more difficult to reach interop. We plan to mitigate this with detailed spec text and extensive web-platform tests. One thing to highlight - the fragment directive (everything after `:~:` in the URL) is stripped from the URL during page load. This is done for compatibility, to ensure that target pages are not confused by the fragment directive. A page can already tell where the user gets scrolled to, and what text is at that location, so explicitly exposing the text directive data in an API doesn’t reveal anything new or sensitive to the page. Interoperability and Compatibility TODO Gecko: No signal WebKit: No signal Web developers: No signals Other signals: Debuggability Authors working with text directives today have no visibility into their inner workings. This API improves the situation and will allow us to provide some more useful output (e.g. by explaining in an exception why a TextDirective fails to parse). Is this feature fully tested by web-platform-tests <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> ?Yes - we’ve added tests to wpt_internal <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/wpt_internal/fragment-directive/> which can be simply upstreamed when shipping. Will continue to add extensive tests as the feature develops. Flag name--enable-blink-features=TextFragmentAPI Requires code in //chrome?False Tracking bughttps://crbug.com/1214791 Estimated milestones No milestones specified Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5073715822854144 This intent message was generated by Chrome Platform Status <https://www.chromestatus.com/>. -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANMmsAtH833s%3D22PRGKbtZ%3DeqapemAG_xCQCDEVsj4WJYBOkhA%40mail.gmail.com.
