The GenesisWidget and HTML5 Input Tag

[Mark_S]

ELI5 – how is this better than just rolling your own HTML ?

[TW_Tones]

@Mark_S I suppose it allows you to integrate HTML with TiddlyWiki but it also allows to to avoid the verbosity and the need to “close tags”.

• By defining your own “widgets” you choose the appropriate name, parameter names and default values.
• (I think) It also allows multiple HTML tags to be combined into one intuitive package.

I must admit though I am still to grasp how to make use of the “Genesis Widget” and from there “healthy coding standards”, so its use does not make it harder to self document and share code snippets.

• My “feeling” (read opinion) is it may be a step too far for many users, and will be used to build things that can already be done without it, because the author does not know the simpler method.
• This view may change when I come to understand it better and explain it to other users. Also time will show us when it is a compelling solution and when it should be avoided.

[Mohammad]

@Mark_S

ELI5 – how is this better than just rolling your own HTML?

The new widget will allow me to bound the HTML5 tag attributes to tiddler fields, and access them through WIkiText.

[Mark_S]

Well, the samples don’t do anything like that. They seem to present a very round-about way to do something that could be done much simpler with html and transclusions (e.g. my-class={{!!class-field}} ). There’s nothing in the examples that demonstrates making another widget – just using the Genesis widget. So … I hope someone can fill in the gaps.

[TW_Tones]

@Mark_S

There’s nothing in the examples that demonstrates making another widget

• I think it fair to say this is a common kind of limitation of the documentation, especially for new features. The only way to deal with it is to submit improved documentation and examples especially “real world examples” but its a catch 22, because not as many people learn how to use it, such as they can write good documentation.

[Mohammad]

An example of using GensisWidget is given here by @Alvaro

Look for a Simple WikiText: Link Title Based on Several Conditions

If I understand you correctly, the following would work. But if i’m wrong, you only need to change the filters to match the expected results. \define currentTag() HelloThere \define gSetting() $:/config/LinkTitle <$list filter="[tag<currentTag>]"> <$let theField={{{ [<currentTag>get[format]] [<gSetting>get[text]] +[trim[]!match[title]] [<currentTiddler>has[caption]then[caption]else[title]] +[first[]] }}} theType={{{ [<theField>!match[title]then[$transclude]else[$view]] }}}> <$link tooltip=<<…

[Mark_S]

But … everything there could have been done with HTML/macros.

I was thinking maybe you could use it to create the “open” attribute in details/summary tags. But, my experiment so far suggests that it ignores the calculated attribute “open”:

<$genesis $type="details" $names="field default" $values="myfield A" {{{[[myattributes]get[open]match[yes]then[open]else[]!is[blank]]}}} >
<summary>TiddlyWiki</summary>
  <p>Welcome to TiddlyWiki, a unique non-linear notebook for capturing, organising and sharing complex information
</p>
</$genesis>

Maybe you could use it to add attributes to existing widgets (e.g. SelectWidget), but I’m not sure how that would be helpful

[jeremyruston]

We develop TiddlyWiki fairly actively, and so of course there will be a steady stream of new features. Users shouldn’t be alarmed if they don’t understand all of those new features all at once. In many cases, these new features are the culmination of years of thinking and discussion (that’s the case with the genesis widget; the first mention in my notes is 5 years ago).

As others have noted, the trouble is that it’s hard to create examples that are simple enough to understand and yet realistic.

Anyhow, the second example from the genesis widget documentation dynamically creates a div or span element according to the value of a parameter. The only existing way to achieve the same thing is to use a macro with textual substitution. As you know, we’re trying to reduce the need to use textual substitution because of its brittleness.

There is something further that the genesis widget handles which is almost impossible to achieve in any other way: to be able to specify attributes for the widget without knowing their names, values or the overall number of such attributes in advance. This is accomplished by optionally passing a pair of filters, one of which yields the names of the attributes and the other yields the corresponding attributes.

I’d welcome any improvements to the documentation.

[pmario]

The following example creates a DETAILS HTML tag with a dynamic open parameter. … If the field open-val is empty the open parameter is removed, otherwise open is set to the value. (which imo is a bit ugly)

\whitespace trim
<$genesis $type="details" $names="open" $values={{!!open-val}}>
<summary>summary text</summary>
some text. 
</$genesis>

@jeremyruston … Would it be possible to create the “open” parameter without a value, or should we treat it as a feature?

I think most of the HTML attributes, that ignore their value don’t care if they have a value. …

[TW_Tones]

@jeremyruston

This is accomplished by optionally passing a pair of filters, one of which yields the names of the attributes and the other yields the corresponding attributes.

Thanks for the clarification @jeremyruston.

• You may recall I have being a champion for such possibilities for some time and appreciate the innovations.

to be able to specify attributes for the widget … without knowing
… the overall number

• I understand the same “pattern” is used in existing widgets like the SetMultipleVariablesWidget.
• I am yet to proceed and use this as I wanted but will soon.

The name/values idea is not so strait forward and demands integrity between two filters which is more complicated when using variable parameters in those filters.

• As a result we need more realistic and every day examples to show how to make use of these features.
• Further it may be desirable to deprecate “textual substitution” but if this method is easier to use and understand, then people will continue to use it.
  • at least where relevant.

Like others I am happy to study, promote and support these new features but we need to build just a little more examples that demonstrate;

• The features it states it allows
• Real world examples
• Examples containing variables and fields rather than static or literal values.

This is an example of an issue we face in a number of areas, there is a hump to climb between the release of a new feature and community adoption that can then inform “improved documentation”.

How do we find a way to kick this along a bit further?

[TW_Tones]

@pmario

following example creates a DETAILS HTML tag

@pmario is there any way to demonstrate why anyone would do this?

• It seems to diverge from the alternative approaches with no apparent added value.

[pmario]

@TW_Tones

It seems to diverge from the alternative approaches with no apparent added value.

Try to create the same working function without a macro with $text-substitution$ and HTML tags or JS.

[Mark_S]

@pmario

If the field open-val is empty the open parameter is removed, otherwise open is set to the value.

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.

@TW_Tones

@pmario is there any way to demonstrate why anyone would do this?

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.

@jeremyruston

As you know, we’re trying to reduce the need to use textual substitution because of its brittleness.

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!

[TW_Tones]

@pmario

Try to create the same working function without a macro with $text-substitution$ and HTML tags or JS.

• 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).

@Mark_S

The idea is to allow you to open or close all detail/summaries

• 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.

[Mark_S]

@TW_Tones

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.

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.

@TW_Tones

A real solution would be making it possible to to provide a state to a html tag and capture the click.

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.

[CodaCoder]

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

[pmario]

@Mark_S

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.

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>

[jeremyruston]

@pmario

Copy paste this code to the experimental wik

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]] }}}>

[pmario]

@jeremyruston

<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.

[Mark_S]

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> ?