The use case that came to mind was Dave Gifford’s – he needed all the d/s tags opened for static export, but not necessarily the rest of the time.
Well, that 's an interesting question – can we use Genesis to add an “onClick” attribute that points to a function defined in a rawtext opening tiddler? Thus making a widget that acts like a JS-defined widget? Now that would be cool.
Just FYI: The open attribute on the <details> element is a boolean. In HTML parlance, boolean values do not support a value. The presence of the attribute indicates true; to represent false, it must be omitted.
Tricky.
https://html.spec.whatwg.org/multipage/interactive-elements.html#attr-details-open
Sure. Copy paste this code to the experimental wiki at: https://tiddlywiki5-jaen28zs7-jermolene.vercel.app/ and you get a $$details widget, that can have a persistent open state, without any JS code.
Creating a unique state tiddler name is a bit tricky and may be improved. At the moment if the SUMMARY text is the same, the state is the same and the tiddlers are visible for easier testing
Which is described at: https://github.com/Jermolene/TiddlyWiki5/pull/6666
\widget $$details(summary)
\whitespace trim
<$genesis $type="details" $names="open" $values={{{ [<transclusion>addprefix<summary>sha256[]get[text]] }}}>
<summary>
<$button actions=<<toggle>> class="tc-btn-invisible">
<$action-listops $tiddler={{{ [<transclusion>addprefix<summary>sha256[]] }}} $field="text" $subfilter="+[toggle[x]]"/>
<<summary>>
</$button>
</summary>
<$slot $name="ts-raw"/>
</$genesis>
\end
<$$details summary="click me">
block mode
This is the text to be detailed
</$$details>
<$$details summary="click me too">
Inline -- This is the text to be detailed
</$$details>
Unless I’m missing something, this example works when using the details element directly. I don’t think the genesis widget is required here. But it’s a great demo of the custom widget functionality in the parameterised transclusions PR!
<details open={{{ [<transclusion>addprefix<summary>sha256[]get[text]] }}}>
That’s exactly the problem … as soon as open is a parameter it is active. It doesn’t care about the value. To close the details tag open needs to go away completely.
There may be other ways to get it working with a macro. … But most of the time if there are more complex parameters we need to fall back to the <$macrocall widget.
Imo custom widgets are more verbose than a macrocall widget.
There’s a lot to unpack here. Where do I
<$slot> (not on search)<transclusion> ?@pmario’s example uses the new features from Parameterised transclusions by Jermolene · Pull Request #6666 · Jermolene/TiddlyWiki5 · GitHub
You can explore the docs for these new features in the prerelease build of the parameterised-transclusions branch:
https://tiddlywiki.com/prerelease/parameterised-transclusions/
To be clear as far as I can see this thread is not exclusive to TiddlyWiki 5.2.4 and 5.2.5 in which the GenesisWidget was released because some of the examples here demand the 5.3.0 pre-release.
I tried to stay within the bounds of the current release and provide a “details solution” and found the GenesisWidget (on its own) offered little (I stand to be corrected).
In fact I branched off and made a details solution with a macro that I personally consider better. To see examples of it used.
I am still looking for a compelling set of examples for the use of the GenesisWidget on tw 5.2.x
One example in core, where it should be updated using the $genesis is the list-links where (see $:/core/macros/list)
\define list-links(filter type:ul subtype:li class emptyMessage)
\whitespace trim
<$type$ class="$class$">
<$list filter="$filter$"emptyMessage=<<__emptyMessage__>>>
<$subtype$>
<$link><$let tv-wikilinks=no><$transclude field=caption><$view field=title/></$transclude></$let></$link>
</$subtype$>
</$list>
</$type$>
\end
I think the statement like <$type$ class="$class$"> is not semantic and not a good practice. Now this can be done using the $genesis in more semantic way.
I wanted to show a relatively simple example, how the genesis widget can be used, without any bells and whistles.
The very first example did work, but it probably was hard to use and not descriptive enough.
Initially the genesis widget was part of the “Parameterised transclusions” pull request, but was moved to the current wiki earlier. Probably to raise discussions like this one here.
With the second example I wanted to give a preview of an upcoming functionality, where the genesis-widget can shine.
The purpose of my second example was to create a DETAILS HTML tag, that is able to store the state and keep it. It should do so without the need for $text-substitution$, since this mechanism may be deprecated in the core once we have a working solution.
If a persistent open/close state is not needed, there is no need to use any widget or macro. The DETAILS HTML tag woks that way out of the box.
Your examples do something completely different. If I open a <<details>> macro and then click anywhere on the page it closes the content.
If that’s the intended behaviour … cool … but not really comparable.
My key concern relating to demonstrating the use of the Genesis Widget but perhaps we need to return to the OT (Original thread).
I understand the intention. I appreciate what you shared, I suppose two points are;
So, the upshot seems to be that the GenesisWidget has limited value in the current version of TW, but will be useful in TW 5.3.0.
But TW 5.3.0 will require us to know about \functions, \procedures, \widgets, \parameters, $Slots (sometimes idiosyncratic values inserted), $Fills, transcluded variables , the effect of using a variable with $, and when to use variables prefixed with $ or $$.
All because 6 particular characters can sometimes break macro substitution ?
Maybe it’s just my age, but I can’t help feeling the complexity is spiraling …
Both examples work. The first one works too. You only need to create a field named: open-val and give it a value. If there is a value the details will be shown. If there is no value details is closed.
Only the second example needs 5.3.0
I’ve been following this thread in the hope that someone at some point would give a “killer application” for the widget. One that would make me want to use it and/or replace “bad” code in my wikitext with an elegant genesis construction.
So far I’ve been disappointed. If the details widget is already the best use of it, or even the span vs. div thing from the documentation, it won’t do much for me.
@jeremyruston writes, correctly:
As others have noted, the trouble is that it’s hard to create examples that are simple enough to understand and yet realistic.
There must have been some application for it in the back of your mind these last 5 years that made you want to put it in the core. At the time of this writing, one of the list-links macros is the only use of it in the core. That cannot have been the reason for its creation, or shall I say genesis? 
I see a usefulness in getting rid of text substitution, but then again there are few cases where there is absolutely no other way around text substitution. I’m not sure these cases are made more robust or easier to understand with the genesis widget and its filter-defined parameters and values.
So I fear its usefulness may be limited to a few core developers and enthusiasts of the details widget. 
But that’s totally OK, of course. Not every widget is for everyone. I will keep it in my bag of tools and who knows, there may be a time where this will become very handy. Until then, I’ll keep looking out for better examples from others.
Have a nice day
Yaisog
PS: I hope to have made clear by the smilies sprinkled throughout that there are absolutely zero bad feelings regarding genesis on my side. It’s simply a case of having too high expectations, given past new major features which were always immediately useful or long-awaited.
I’ve tried to explain the motivation for the genesis widget as clearly as I can.
I don’t quite understand why the response is disbelief. I’m not sure that “killer application” sets the right expectation. Are there “killer applications” for the <$setmultiplevariables> widget or the <$qualify> widget?
The primary application of the genesis widget is to create widgets dynamically, where the widget name and/or attribute names are not known in advance.
There are numerous places in the core where we use textual substitution to partially achieve the same goal. There was further disbelief in this thread when I say that textual substitution is brittle and unwieldy for this purpose. That’s strange to me, because it’s something that I’ve been talking about for many, many years.
As others have noted, the genesis widget has some interesting applications in the context of custom widgets. For example, it is the basis of the “visible transclusion” feature:
https://tiddlywiki.com/prerelease/parameterised-transclusions/#Visible%20Transclusions
That’s the only core macro that has been refactored to use it so far. There’s further activity on GitHub on that front:
In many cases it will make more sense to wait until https://github.com/Jermolene/TiddlyWiki5/pull/6666 is merged before refactoring core macros.
Indeed, the problem is that historically we’ve used text substitution to solve a number of problems that have proven to have better solutions.
That’s not the intention. In this context, the <$genesis> widget is one of a number of enhancements that are needed in order to be able to avoid the dangerous usages of textual substitution.
A more helpful characterisation is that @pmario has discovered that the <$genesis> widget can be used to dynamically control HTML attributes that do not have a value, something that is otherwise not supported by the core. It’s a useful hack, but it’s not restricted to the <detail> element, there are many HTML attributes that are used without values.
To be honest, I’ve found this whole thread to have an unexpected tone and have been struggling to understand what is going on. There is a definite undercurrent of criticism, veiled as “I don’t understand this new thing, therefore it must be a useless mistake”. Smilies don’t really change that.
From my point of view, I’d prefer to focus on improving the docs but instead there is this discussion about how people felt when their expectations for the genesis widget were found to be misleading.
Not every addition to the core is ground breaking or revolutionary. Most of the primitives that we add, such as filter operators and widgets, address quite specific gaps in the affordances available via wikitext and are not immediately useful to everyone. $genesis is no different.
There also seems to be a lot of misinformation about what $genesis is intended to do. Genesis is a simple lightweight widget that does just one thing, it allows you to dynamically create an HTML tag or widget without knowing its name and attributes in advance. Yet that functionality is useful. This addresses some of the needs in the core where we otherwise have to revert to textual substitution or wikify, and improving the core alone is a compelling enough reason to introduce it.
Not only do antipatterns such as textual substitution lead to poorer performance, but a significant amount of effort has been required to patch issues arising from textual substitution over the last few years, and there are no further significant gains to be had in this area.
Furthermore, there is an ongoing effort with core development to open up a lot of the existing blackbox behaviour implemented as JavaScript to be expressed in wikitext instead, to make it more flexible and customizable. For example, this is what a performant and elegant wikitext based replacement of the $edit widget would look like, making the selection of editor for tiddlers more customizable. $edit is a meta widget that exists only to select and invoke the correct editor widget for a tiddler, such as $edit-text or $edit-codemirror, based on the value of a config tiddler. (untested code from a precursor of the genesis widget):
\define editor(field:"text",tiddler)
<$let
currentTiddler={{{ [<__tiddler__>!is[blank]else<currentTiddler>] }}}
type={{{ [<__field__>match[text]then{!!type}!is[blank]] :else[[text/vnd.tiddlywiki]] }}}
editor={{{ [<type>lookup[$:/config/EditorTypeMappings/]!is[blank]] :else[<currentTiddler>is[binary]then[binary]else[text]] :and[addprefix[$edit-]] }}}
>
<$genesis $type=<<editor>>/>
</$let>
\end
<$edit field="text" tiddler="MyTiddler">
equivalent to:
<<editor field:"text" tiddler:"MyTiddler">>
This could further be customized from wikitext to meet individual needs, for example so that codemirror is selected as the editor unless on a mobile device where the framed editor is used instead.
Implementing a similar editor selection mechanism for Streams is one of the few places where the plugin still uses custom JavaScript, but that is no longer necessary.
As we work on transitioning other parts of the core from hardcoded JavaScript based widgets to customizable wikitext implementations, the same facility to dynamically invoke the correct widget - without knowing its name in advance, will be needed. Yes, the slated features for TW v5.3.0 will provide more use cases for $genesis but it has value already.
I have been exploring progressive enhancement of a sort with wikitext, using alternative or more performant widgets when they are available without a hard dependency and falling back to core widgets when they are unavailable. Here too, the genesis widget will allow far more performant, robust and elegant code.
Hypothetical example:
<$genesis $type={{{ [widget[turbolist]else[list]] }}} filter="...my filter...">
<!-- do something -->
</$genesis>
Jeremy, thank you for taking the time to answer so comprehensively, but I think you got me all wrong: I for one welcome our new genesis overlords. My intention was not to criticize.
[…] instead there is this discussion about how people felt when their expectations for the genesis widget were found to be misleading
You’re exactly right. Maybe I mistook it too much for a herald of the great things to come with PR 6666. That PR has a lot of hype out in front of it.
Have a nice Christmas
Yaisog
PS: The usage of genesis in the list-links macro might not be a bad example of its usage for the online documentation, as template for users’ own macros.
This is a very interesting application for me! Tiddlywiki allows me to use $macrocall and call a macro where its name is determined through some logic. For example, in Shiraz and Commander and some other plugins this help me alot! But I never could do this with widgets! Now $genesis allows me to have the same flexibility with widgets and html tags. See for example Look for a Simple WikiText: Link Title Based on Several Conditions - #11 by Alvaro
Absolutely, this is a nice example to go!
My opinion is largely covered in the PR that Jeremy linked, but I will just say here that $genesis is absolutely useful to TiddlyWiki, arguably vital. When will end-users use it? Probably never. But for plugin developers like me, it’s a big tool. Text substitution is something that IMO has no place in a robustly built plugin. They’re powerful, sure, but they’re very brittle. It’s impossible to create macros using text substitution that can’t be broken in strange ways, and $genesis is a proper tool that takes TiddlyWiki a huge step toward doing away with text substitution in core and plugins.
I’ve got about 5 personal plugins. 4 of them will soon be using $genesis. Also, my two most popular plugins, Relink and Uglify, both work far more reliably on wikitext that uses $genesis instead of text substitutions.