Need a way to feature detect

[bokand]

In #15 we're discussing ways to spec the feature such that it doesn't break pages that use the hash fragment for their own purposes. If we succeed in doing that, this means that UAs implementing this feature can follow links with the targetText to pages that would otherwise break with a hand-crafted fragment. The canonical example from that issue is https://www.webmd.com/skin-problems-and-treatments/lice-treatment#anything.

However, this would mean that a page sending a user to https://www.webmd.com/skin-problems-and-treatments/lice-treatment##targetText=sometext will load and work correctly in UAs that support the feature, but completely break the page for UAs that don't.

We should support some method of feature detection so pages can check whether adding a targetText has the potential to break the link and avoid adding it for UAs that don't support it.

[bokand]

I propose adding an object on window.location that will only be present if the UA supports targetText. We should call this selector to allow future extension beyond just text. It would also give us a place to add APIs to allow adding APIs such as letting the page know whether the selector was successfully matched and scrolled.

[domenic]

I'm curious why selector and not fragmentDirective? I think the spec concepts and developer-facing API should align, if possible.

I'll note that I am pretty sure you can feature detect in a roundabout way by doing something like:

<span hidden id="targetTextTest">put-a-guid-here</span>
<script>
window.location = "###targetText=put-a-guid-here";

if (document.querySelector("#targetTextTest").matches(":target")) {
  // feature is supported
}
</script>

(Possible modifications: if we don't plan to scroll to hidden things, then just make it 0x0, or transparent. Also, clean up after the feature detection, e.g. by removing the targetText from the window.location and removing the element from the DOM. Also, #1 implies we might change it to :target-within instead of :target.)

[bokand]

I'm curious why selector and not fragmentDirective? I think the spec concepts and developer-facing API should align, if possible.

I agree, will change it.

I'll note that I am pretty sure you can feature detect in a roundabout way by doing something like

That won't work because, to mitigate concerns around cross-origin information exfiltration, we restrict the contexts around which the directive will be activated. This includes requiring a user-gesture. It's discussed in more detail in https://github.com/WICG/ScrollToTextFragment#security but I just realized we didn't put it in the spec so I filed #46 to followup on that.