TiddlyWiki support

14 views
Skip to first unread message

Pesho Ivanov

unread,
Oct 16, 2021, 11:30:27 AM10/16/21
to d...@list.hypothes.is
Greetings.

TiddlyWiki[1] is a single html file with content of multiple wiki pages. It is meant to be continuously edited and I was wondering if Hypothes.is is suitable for annotating such a wiki.

I imagine that editing the wiki may totally break the anchoring of an existing annotation but I could not find any documentation of how h handles edits.

Will be glad to receive any information on the underlying anchoring method within an html.

[1] https://tiddlywiki.com/

Thanks,
Pesho

Michael DiRoberts

unread,
Oct 17, 2021, 11:15:56 AM10/17/21
to dev, Pesho Ivanov
Hi there,

You can read about fuzzy anchoring here. That said, there have been recent improvements to how we anchor annotations to text that I don't believe are captured in that article.

Best,
Michael

Pesho Ivanov

unread,
Oct 18, 2021, 4:26:28 AM10/18/21
to Michael DiRoberts, dev
Thank you, Michael. Indeed I see that the problem of annotation anchoring has been receiving attention for a while and it seems to me the research is ongoing.

Hello, From a quick look at TiddlyWiki, it looks like Hypothesis is not going to work well with it. The biggest problem is that the URL and metadata in the `<head>` of the page does not reflect the displayed content, so Hypothesis doesn't know how to associate annotations with the appropriate logical document in the wiki or navigate to a particular piece of content associated with an annotation. Hypothesis doesn't currently support applications that do client-side navigation well. We do want to improve this in future, but it will likely rely on applications updating the page URL and embedded metadata about the document as they navigate within the app. Regards, Robert Knight

Thank you, Robert. It looks to me that the general solution to the client-side navigation and dynamically-loaded content is capturing the rendered content and doing fuzzy search on it. Would that be a reasonable last resort?

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
--
You received this message because you are subscribed to the Google Groups "dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev+uns...@list.hypothes.is.
To view this discussion on the web visit https://groups.google.com/a/list.hypothes.is/d/msgid/dev/f1bfb691-948e-43dc-83c6-19e1d3963d24n%40list.hypothes.is.

Robert Knight

unread,
Oct 18, 2021, 7:03:23 AM10/18/21
to Pesho Ivanov, dev
Hello Pesho,

Fuzzy anchoring is really about addressing a different problem than the one faced here. Fuzzy anchoring handles the case where you know what the current document is, but the content of the document has changed since it was annotated. In this case the problem is that the client doesn't know what document(s) (tiddlers) are visible or how to change which ones are displayed.

For applications that do client-side navigation we can probably implement a general solution for "good citizens" that update the path of the URL to reflect the current document/page as the user navigates. TiddlyWiki doesn't do this by default, although I see there is a setting [1] which will make it update the fragment. The client currently ignores the fragment, as it identifies a subsection of a document rather than the document itself in "normal" websites.

If someone could make a variant of TiddlyWiki that used the path in the URL to represent the current document that would make it easier to support (although that would also complicate deployment). Otherwise I suspect we'd need a custom "integration" (like we have for PDFs) that understands TiddlyWiki specifically, or some heuristics to determine that the fragment identifies the document rather than document section being displayed.

Kind regards,
Robert.


Reply all
Reply to author
Forward
0 new messages