cc: flackr@,girard@,mehdika@ On Friday, November 5, 2021 at 5:11:18 PM UTC-4 David Bokan wrote:
> (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/37442efa-df85-4b33-a787-4da2e6c17737n%40chromium.org.
