Let HTML be free (republished)

[AnthonyMuscio]

Folks,

Following on from my speculation in dealing with cases such as the html details or the closed Let HTML be free #3380 , I have started this discussion, I would like your views on the following.

If we could find a way to support the integration of HTML with TiddlyWiki for these "primitives" I believe this would be very popular, one way maybe to have some basic functions that "emulate" common html javascript functions OR extend the way WikiText containing HTML is parsed, so that the two work better together.

Eg a way to provision the html details with a toggle value.

The idea would be to leverage the rich html environment and reduce the need for solutions to be built into tiddlywiki when they already live in the HTML5 standards. If you spend time as I have looking at HTML at https://www.w3schools.com/ you will see that on many occasions that the html demands JavaScript which will not (directly) work in tiddlywiki but more often than not this java script seems really basic, allowing a value to be set or stored on click or some other primitive operation. Or the browser contains the value the html has produced from input to states but we have no way to reference it in the wikitext.

In fact TiddlyWiki has already done as I propose with CSS allowing it to be a fully supported standard in tiddlywiki as well as permitting it to be used in response to tiddlywiki tags and other attributes.

I am not saying this is simple, but it potentially is, and I do not have the experience to implement it.

In some ways Evans formula plugin is doing this by allowing html attributes to be set using tiddlywiki variables and tiddler/fields.

What remains is I believe a need to connect HTML more closely to the tiddlywiki internals.

One slightly more complex example may be html forms and php https://www.w3schools.com/html/html_forms.asp

 <form>
  First name:<br>
  <input type="text" name="firstname"><br>
  Last name:<br>
  <input type="text" name="lastname">
</form> 

If we could only access the values above we know are stored in the browser eg firstname lastname

But I think it worthy of investigation, because it would open the world of HTML5 and related frameworks to users while reducing the need for "equivalent" widgets like the Details widget. It will simplify what goes into tiddlywiki while at the same time enriching its capabilities. Further once a subset of tiddlywiki/html5 "methods" are available it would be easy to translate a wealth of code from html training and support sites, and users.

Please consider deeply, the return could be massive.

Regards
Tony

[CodaCodr]

Hi @AnthonyMuscio

Not sure I'm following all of what you said, Tony, but the <form> element caught my eye. I decided to look at it wrapped with an <$eventcatcher> widget. Try this (very) contrived example at tiddlywiki.com

\define submitactions()
<$action-log $$filter="dom-first dom-last" event=<<event-type>>/>

<$action-setfield $field=first-name $value=<<dom-first>>/>
<$action-setfield $field=last-name $value=<<dom-last>>/>
\end

<$eventcatcher events="submit" selector=".my-form" actions-submit=<<submitactions>> tag="div">

 <form class="my-form" first={{{ [[otherTiddler]get[first-name]] }}} last={{{ [[otherTiddler]get[last-name]] }}}>

  First name:<br>
  <$edit-text tiddler=otherTiddler field=first-name type=input/><br>

  Last name:<br>
  <$edit-text tiddler=otherTiddler field=last-name type=input/><br>

  <input type=submit value=Submit>
</form> 

</$eventcatcher>

<span>FN: {{!!first-name}}</span>

<span>LN: {{!!last-name}}</span>

The form as no action, method or target attributes.

The input elements are regular <$edit-text> widgets that target fields in otherTiddler. Modifying their values places their values in otherTiddler as you would expect.

The form has two "extra" attributes, first and last plus a class="my-form" which acts as the hook for <$eventcatcher>.

When the submit button is clicked, the event is trapped and the data passed to the <<submitactions>> macro.

The <<submitactions>> macro copies the values from the first and last attributes of the form (via dom-first and dom-last) into the first-name and last-name fields in the currentTiddler.

Like I said, contrived. But it does do one thing nicely -- via a lengthy route, allows modifying fields in the current tiddler :) Maybe there's a few other things eventcatcher can help with.

@saqimtiaz I was surprised to discover that dom-* attrs are not visible <$eventcatcher>HERE</$eventcatcher> - they only work in the actions handlers.

[AnthonyMuscio]

@CodaCodr

Thanks for that example case. It is to me a partial example of what we may do to give html a new life in tiddlywiki.

• Perhaps, like or rather than, the event capture widget a custom widget that could wrap pure HTML and "interpret" html into tiddlywiki wiki-text and widgets so it works out of the box while forcing it into compliance with TiddlyWikis standards would work? In some ways this is the reverse of the render process.
• Another idea (possibly ill informed) is to some how allow the DOM generated by HTML code etc... to be interrogated by TiddlyWiki widgets given to designers and users.

I am in the process of boosting my HTML CSS and Javascript skills to this end, however even some time ago I managed to include HTML in a tiddler that was able to submit a form to my PHP host (by adding the supporting files in the same folder as the tiddlywiki). In this case the html was merely presented via tiddlywiki and the rest of the code on the server. keep in mind the host must permit this and supply the relevant code so we are not granting powers to tiddlywiki that html etc... would not have on a host configured as such.

One reason I was exploring this was this would allow a module (TW5 plugin) to be written that could be used to service login and permissions or even form submissions through tiddlywiki as the user interface to the host, thus enabling check in and out, and other host dependant solutions that tiddlywiki cant easily address.

[CodaCodr]

One reason I was exploring this was this would allow a module (TW5 plugin) to be written that could be used to service login and permissions or even form submissions through tiddlywiki as the user interface to the host, thus enabling check in and out, and other host dependant solutions that tiddlywiki cant easily address.

As well as html forms, one could envisage a plugin providing XHR (i.e "ajax").

But I'm still not clear why you choose to say "Let HTML be free..." - how is it not free now? I'm not quite getting it...

[AnthonyMuscio]

CodaCoda. Let HTML be free is to investigate how we can remove some of the limitations placed on HTML within tiddlywiki, many of which relate to the fact many basic html functions require javascript that is not available to that html, and we need to maintain tiddlywikis control of many of the changes that can occur.

I agree we can do a lot with html within tiddlywiki, one of my favorite discoveries was using arbitrary html tags which you can style or hide with css. eg <mysection style=...></mysection> and in another project we have a way to transform this into custom wiki markup, all good.

My idea here is to provide additional widgets or "supporting primitive functions" so we can leverage HTML even further. HTML5 is mature and sophisticated but opening more of its functionality to tiddlywiki designers we make use of an inherit that functionality.

You may be aware that many of the widgets and plugins effectively provision functionality found in HTM/Javascript into the tiddlywiki platform. Such as reveal, button etc... but this mean we need to "keep up" with trends and methods used widely and provision widgets for the functionality. My idea was to consider tacking this from the ground up and provide html/basic Javascript supporting widgets then designers can more readily make use of HTML solutions directly.

We have already got features which support this approach, such as the raw tags etc.. where someone in the know can include imbedded code so it works in tiddlywiki. The key difference in my idea is not to do this piecemeal but try to strategically build the tools to extend the degree by which we can leverage HTML much more with basic javascript functions delivered securely.

Tony

[AnthonyMuscio]

Perhaps even a way to have a HTML/Javascript sandbox that can be made to look as if it were part of tiddlywiki with communication in either direction possible.

[CodaCodr]

The only HTML element I know of that is "not allowed" in regular tiddlywiki is <script>, so in that sense, HTML is already free. That's to prevent the unaware, casual user from including potentially harmful JavaScript code that might damage their wiki - i.e., protecting the innocent from themselves, more than anything.

And running JavaScript isn't so difficult, either, once you learn how...

Sorry, I still don't "get it". :/

[AnthonyMuscio]

CodaCodr

Constraints on injecting Javascript are important, but I am suggest just enough to permit html form submissions and other basic html interactive on click etc... With <script> not available many of the action and submit, HTML vars to Tiddlywiki vars, and more are not available and a large code base of HTML is of no use in tiddlywiki. I am suggesting complementing what supporting functions/widgets are available to set HTML free.

TiddlyWiki does attempt to deliver functionality, without reverting to Javascript coding, perhaps you do not get it because you move quickly to javascript, and coding extensions to tiddlywiki, rather than remaining inside the WikiText, HTML and CSS spaces such as possibly the vast majority of users do. I have remained active in this space to represent the tiddlywiki superuser as distinct from a code developer.

regards
Tony