Fragmentions

[bzbarsky]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Fragmentions
• Specification or proposal URL: https://indieweb.org/fragmention
• Caniuse.com URL (optional):
• Bugzilla URL (optional):
• Mozillians who can provide input (optional): @tantek @dbaron @martinthomson

Other information

See also #194 for another proposal in this space.

[bzbarsky]

@tantek and I looked through:

• https://docs.google.com/document/d/1eK5xcWo1T7M-SguRshahy53zHMvkvVzxIjVWZm34o-U/edit
• https://indieweb.org/fragmention
• https://wicg.github.io/ScrollToTextFragment/
• https://github.com/WICG/ScrollToTextFragment
• https://bugs.chromium.org/p/chromium/issues/detail?id=961440

and various issues on the ScrollToTextFragment repo. We have some concerns about the lack of a really clear processing model here; this concern is shared by #234 as well.

Also, both proposals fail to address some use cases (e.g. highlighting the entirety of a particular row on https://www.x-rates.com/table/?from=USD&amount=1) that came up during our discissions about this. Those use cases might be better-served by some other XPointer-like mechanism, possibly; more investigation is needed there.

ccing @annevk since I bet he cares about this too.

A draft position we are proposing:

---

Summary position: worth prototyping if a clear processing and security model is defined

There are several use cases addressed by this extension to URL, as incubated and deployed on sites:

• Users bookmarking, sharing, citing quotations/ranges of text that don’t have pre-provided anchors.
• Users bookmarking (and sharing) intra-document positions that don’t have pre-provided anchors.
• Marginalia being associated with the right part of the text.
• Peer-to-peer marginalia (comments written about a range of text posted on another site, automatically federated into the larger article, and presented/focused/listed accordingly when linked to).
• Citations.

Our general feeling is that Fragmention provides a clean re-use of existing syntax with no additional syntax cost (or resulting complexities in user model, implementations, etc.) for a very desirable feature for the web, and as such is an excellent trade-off of costs vs benefits.

Sites have deployed “scroll to and highlight context of a fragment” through the use of a polyfill, fragmention.js. Many are cited here: https://indieweb.org/fragmention#IndieWeb_Examples. This is a strong indication that this functionality addresses certain use cases effectively in practice.

Sites have also deployed a seamless UI for creating fragmentions, e.g. by a user selecting the text to link to, and using the History API to alter the current URL to a fragmention URL to that text that the user can select and copy. https://indieweb.org/fragmention#UI_for_Fragmention-generation. Presumably this UI could be hoisted into the browser instead; some care would need to be taken with that.

Lastly, there are also sites both posting marginalia comments (many, using fragmention links) and sites receiving and displaying marginalia (parsing fragmention links): https://indieweb.org/marginalia#IndieWeb_Examples. This use case would continue to be addressed effectively with a browser-native Fragmentions implementation.

We are concerned about the fragment routing issue described for WebMD in https://bugs.chromium.org/p/chromium/issues/detail?id=961440. While this is the first instance of this problem we’ve encountered, and in particular, widespread use of Fragmentions in the IndieWeb community has not encountered this problem, it’s clear that Fragmentions may not be compatible with sites that use fragment-based routing. This might well end up being a problem for actually shipping Fragmentions, or a problem for usability once it’s shipped.

Exposing the Fragmention string to the page allows in-page implementation of smart text highlighting (possibly augmenting whatever highlighting the browser does) and allows better UX (and in particular significantly improved UX experimentation) in the Marginalia use case. This needs to be weighed against perceived security and privacy implications of exposing the fragmention string. https://docs.google.com/document/d/1YHcl1-vE_ZnZ0kL2almeikAj2gkwCq8_5xwIae7PVik/edit hints at these, but does not really spell them out in a convincing way.

Security considerations for Fragmention are similar to those for ScrollToTextFragment described in https://docs.google.com/document/d/1YHcl1-vE_ZnZ0kL2almeikAj2gkwCq8_5xwIae7PVik/edit# and https://wicg.github.io/ScrollToTextFragment/#security-and-privacy and need to be sorted out before this can be prototyped in earnest. In addition, there is the consideration of Fragmention link use-cases where the author of the link may not want to communicate to the server hosting the link the range of text being linked. This is in tension with the marginalia use case. In practice the receiving page/site can largely detect the text of the Fragmention by watching scroll position and determining what DOM and/or text nodes have been scrolled to or set as :target, so the additional information exposed is limited.

The processing model for Fragmentions (i.e. the exact way the search for the string is performed) also needs to be defined before a serious prototype can be created.

While it seems to us that the comments about whitespace at https://indieweb.org/fragmention#Syntax are largely irrelevant, in that they are not allowed in IDs in "valid HTML" but are in fact supported in IDs in practice in browsers, that does not seem like a showstopper for prototyping this proposal in practice.

We feel that if it’s possible to adapt Fragmentions to address the compatibility and security concerns along the lines proposed in https://wicg.github.io/ScrollToTextFragment/, that would be preferable to inventing / switching to another syntax that does not have similar implementation and deployment experience. It will also encourage the continued growth of an existing healthy ecosystem that is already addressing the stated use-cases, albeit with opt-in required from the sites involved.

---