The Genesis Widget and Refresh Issue

#1

In kookma Utility Plugin, the $genesis is used to create the html5 widget details as below:


<$genesis $type="details" $names="open" $values={{{ [tag[show-content]] [tag[show-source]] :and[match<currentTiddler>] :then[[open]] }}} title="Show/hide tiddler source code" >
<summary>Code</summary>
<$macrocall $name="code" language={{{ [{!!type}else[xml]] }}} src={{!!text}} />
</$genesis>

NOTE: The filter transclusion result determines the state of details (expanded or collapsed).

This code is implemented within a viewtemplate to unveil the source code of a tiddler using the HTML5 details widget.
The problem arises when I activate the details to show a tiddler’s code in the story river; any subsequent interaction causes the details to close.
This indicates that the $genesis is refreshed, which resets the details. Such interactions include clicking the search input box or opening a tiddler in the story river.

How resolve the issue?

2 Likes
#2

Overall this is a weakness with using the details element, that the state does not survive a refresh cycle where it is re-created. The robust solution is to use the $reveal widget.

However, I do not see anything in your code that would be triggering the refresh that would result in such behaviour. More likely, the container of the $genesis widget is getting re-rendered.

#3

Thank you for clarifying this.
The code resides in a view template and the details is displayed correctly, however as I click in the search button
or open a new tiddler in the story rever, the state changes to its predetermined state.

#4

The fact that the details/summary elements do not work properly within TiddlyWiki’s dynamic refresh environment is quite a barrier for new users who are already familiar with HTML.

I have been wondering idly what would be involved in having TiddlyWiki give special treatment to the standard HTML <details> and <summary> elements, rendering them as custom widgets instead of standard HTML elements. The implementation of the custom details element would create a state tiddler with a random name, placing the name of the state tiddler in a variable. The custom implementation of the summary widget would create a clickable element containing the summary text, and an event handler that would use the variable to obtain the title of the state tiddler whose value should be toggled. I think the end result would be that details/summary elements would just work naturally within TiddlyWiki.

If we were to take this approach of giving special treatment to specific HTML elements then there might be a few other candidates that would benefit from the same treatment. For example, we could extend the <video> element so that it automatically uses a state tiddler for the video position, avoiding the video playback position resetting to zero when there is a refresh.

1 Like
#5

For as often as I create & destroy details elements, it would make sense to have a way to find and delete orphaned state tiddlers for removed details widgets.

I have a ToDo List that uses details elements to show/hide the text field of task tiddlers. These tiddler are meant to be fairly temporary with new ones being created regularly, so I feel like I would need to either make an easy way to prune the old state tiddlers or be able to specify the state tiddlers and make the ToDo list delete each state tiddler along with the corresponding task tiddler.

Even if the details element is not perfect, I currently don’t have to worry about cleaning up a lot of state tiddlers for them.

2 Likes
#6

Hi Jeremy,
Thank you for your clarification and detailed explanation.
The TiddlyWiki approach of creating details/summary has been already implemented by different community members.
One flexible and customizable implementation can be found in Shiraz.
For example see the Faqs created by slider/details here: https://kookma.github.io/TW-Shiraz/#Tutorial%20Advanced%20FAQs%20Page:%5B%5BTutorial%20Advanced%20FAQs%20Page%5D%5D%20demo%2Fadvanced%2Fslider-faqs%20demo%2Fadvanced%2Fdetails-faqs
These are not only resembles the standard HTML5 details widget, but are searchable and can create elegant FAQs pages.

The Reason Using HTML5 details
BUT, the reason some users stick to standard HTML5 details widget is to export to static pages, where TiddlyWiki approach does not work but standard HTML5 details works.

1 Like
#7

I was suggesting something that I think is slightly different: that TW have special handling for the <details> and <summary> elements so that they handle refresh transparently, without any special intervention by the author. If that was made as a core change it would magically “fix” all the usage of <details> and <summary> in existing wikis, making it work reliably.

1 Like
#8

Ah thank you Jeremy! That would be great! Much appreciated.

#9

I think this may make life simpler, if introduced it would be important to provide a way to toggle this behaviour on or off as we can, for example, “globally disable/enable wiki parser rules.”.

There are plenty of use case where the details widget can be used without a state. A simple normally open or normally closed details widget with content fits a lot of use cases.

  • Perhaps we could revsit the original $details widget and bring that into the core?