Try to create the same working function without a macro with $text-substitution$ and HTML tags or JS.
This isn’t a behaviour I would have predicted. Possibly it needs to be added to the docs? Also, talking about brittleness … it’s easy to imagine that two filters for values and names could easily get out of synch, leading to misassigned name/value pairs.
The idea is to allow you to open or close all detail/summaries, something which otherwise requires javascript. Or, of course, wrap the detail/summary in a macro.
I suppose it’s brittle in some cases. But if I pass a tag to a macro like “div”, “p”, or “span”, how is that brittle?
I guess that Genesis is a widget that replaces a macro in the special case when we want to create an html tag and attributes from it. That seems very niche to me. I’m trying to understand the “killer” app/use.
Thanks!
2 Likes
- but why would we operate with these constraints?
I am not being flippant here, this is a genuine question.
- Some technical argument, or preference like “substitution is fragile” is insufficient if we can build a working solution.
- Substitution is a simple concept people can grasp so its unfortunate we are pushing people away from it rather than fixing it (If it were possible).
- or more specifically store the open/closed state.
We can already use the detail’s widget plugin and many cases do not need the state anyway. Just having normally open or closed is often enough.
A real solution would be making it possible to to provide a state to a html tag and capture the click.
<details {{{ [{!!state}] }}}><summary>more</summary>
Content
</details>
- If this worked.
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
- Find out about \widget ?
- Find out about $$ (can’t search for 2 chars!)
- Find out about
<$slot>(not on search) - Find out about variable
<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).
- Mario’s 5.3.0 pre-release example is effective though
In fact I branched off and made a details solution with a macro that I personally consider better. To see examples of it used.
- It uses a macro to toggle a state however the state is “also” a class name
- Although the state is bound to the current tiddler.
- Any element using the class name is what is toggled
- So the content can be placed after the toggle (as on details tag)
- Or anywhere else, and toggle one or more content areas at once.
- The toggle macro can also be displayed conditionally eg: after answering all questions show the “Show official answers” toggle.
- Incidentally this works to toggle a GenesisWidget with a matching class.
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 think the issue here is you must still go through the edit-text widget to get the input into a tiddlywiki readable form. As @Mark_S points out.
I understand the intention. I appreciate what you shared, I suppose two points are;
- To show the benefits of the GenesisWidget we need more compelling examples
- Especially if to be used in its own right.
- If it really is only going to “shine” later with the 5.3.0 release then lets make that clear.
- Your working example of the details widget is on 5.3.0 prerelease.
- Actually this is so for the details tag, not my demonstrated details macro.
- Perhaps not completely, here I diverged and found a solution to the “need for details” or slider content, using another approach.
- It also allows one to toggle visibility of the Genesis Widget and anything else via a named class. See the now numbered example 5. but yes this is a trivial example.
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.
1 Like
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>
3 Likes