Support the fragmention syntax as fallback

[kevinmarks]

Thank you for your link to Fragmention, and I appreciate the work here. As discussed in the original fragmention post linking by cited text is very resilient.

Have you looked at supporting the Fragmention model as a fallback - ie not requiring #targetText= as a prefix, but if there are multiple space separated words in the fragment, doing a search for them? (after any other special fragment resolution code runs).

[bokand]

I think this makes a lot of sense. Lets see where the proposed syntax falls first and we can see what a reasonable fallback looks like.

[bokand]

One issue with this would be that it would be more likely to create broken links as a result of pages that don't handle user-specified fragments. I've since been convinced this is a real problem, e.g. https://www.webmd.com/skin-problems-and-treatments/lice-treatment breaks when anything is specified in the fragment.

#15 tracks how to fix this. This isn't particular to fragmentation - the issue exists with id-based fragments but I worry that text based fragments will be easier to share/link so could exacerbate the situation

I think if we land on something like https://example.com%%targetText=.... allowing space separated words to fallback to a simple text search sgtm.

[kevinmarks]

If the page breaks when anything is specified in the fragment, even an id that is in the page, then that is an example of bad code, not a flaw with fragments, or extensions to fragment syntax. It's always possible to link with a fragment that does not exist.

[remy]

Jumping on this particular issue so that I can include @kevinmarks for feedback from Fragmentions idea too.

Is there any conceivable reason why selecting text wouldn't update the URLs hash fragment? It immediately exposes the functionality to users and it's straightforward to implement a proof of concept polyfill.

[tilgovi]

Is there any conceivable reason why selecting text wouldn't update the URLs hash fragment? It immediately exposes the functionality to users and it's straightforward to implement a proof of concept polyfill.

That's exactly what we've got in this demo: http://annotator.apache.org/demo/

[bokand]

Is there any conceivable reason why selecting text wouldn't update the URLs hash fragment?

That sounds pretty cool. I could also see counter-points though that users may not expect the URL to change when selecting text or would find it distracting.

IMHO, this sounds like a UI feature that could be left at the discretion of the UA. I don't think it creates any interop issues if one browser uses "select and right click-->Copy Link to Text" and another uses "update the targetText in the URL bar when selection changes" or doesn't provide a way to get links like this at all. This is something we should leave unspecified.

[bokand]

Given that we decided a directive delimiter (:~:) was necessary for compat, I don't think this applies in that case. Closing this out as part of some issue hygiene. Feel free to reply if there's still something related to do here.

[kevinmarks]

I think that was necessary for your use case, where you are programmatically creating a disjoint selection; for the case built from a user text selection, the copy text, paste after the url with a # works well.
If there is a ux affordance where selecting update the url, especially the share url as noted by remy this may be moot.
I can type your directive in the url bar (It's how I made the ones in https://highlightpoetry.com/ ) but it is not a great user affordance.

[bokand]

I don't think this has to do with the disjoint selection or programmatic selection at all. The problem is that users can create this on arbitrary pages (via the official extension and Chrome is currently experimenting with building this into the browser: available now via chrome://flags/#copy-link-to-text).

The fact that it can be created on any page means it has to work everywhere. There's no way to tell programmatically whether the page will break with the fragment on load. Even if we could, it would difficult to explain to users why it doesn't work on some pages.

[bokand]

If the page breaks when anything is specified in the fragment, even an id that is in the page, then that is an example of bad code, not a flaw with fragments, or extensions to fragment syntax.

While I agree with the spirit - compatibility with the long tail of the web is a reality we have to live with and (reasonably) accommodate. Unfortunately, I've found many examples of pages that break catastrophically when the see an unexpected fragment.