Despite the fact that v5.2.4 has not yet been released, there is now a pre-pre-release of v5.3.0 available:
The purpose of the pre-pre-release is to give everyone an opportunity to study the significant improvements that we collectively call “parameterised transclusion”, and to kick off a discussion about them. (v5.3.0 also includes all of the enhancements in v5.2.4 that you can read about at https://tiddlywiki.com/prerelease).
I won’t try to fully explain the new features here because it’s more useful to point people at the documentation and use it as an opportunity to identify areas that can be improved.
There is a brief introduction to the new features in the release note that comes up when you visit the v5.3.0 pre-pre-release, including links to the key entry points for the new documentation. There is also a high level summary of the changes aimed at end users at the top of the GitHub pull request.
I will pick out one small example of the usage of these new features. It’s to resolve the long standing problem that transcluding one of the core images does not allow direct control over the size of the image, instead requiring a CSS rule to resize these images.
I think @twMat once made a suggestion that it would be useful to be able to somehow pass the required size as part of the transclusion. With parameterised transclusion, that’s exactly what we can now do:
Note the use of a single vertical bar to delimit the parameters that are passed to the transclusion.
To make that work, we need a small modification to
<$parameters width="22pt" height="22pt">
<svg width=<<width>> height=<<height>> class="tc-image-close-button tc-image-button" viewBox="0 0 128 128"><path fill-rule="evenodd" d="M65.086 75.41l-50.113 50.113c-3.121 3.121-8.192 3.126-11.316.002-3.118-3.118-3.123-8.19.002-11.316l50.114-50.114L3.659 13.982C.538 10.86.533 5.79 3.657 2.666c3.118-3.118 8.19-3.123 11.316.002l50.113 50.114L115.2 2.668c3.121-3.121 8.192-3.126 11.316-.002 3.118 3.118 3.123 8.19-.002 11.316L76.4 64.095l50.114 50.114c3.121 3.121 3.126 8.192.002 11.316-3.118 3.118-8.19 3.123-11.316-.002L65.086 75.409z"/></svg>
Note the provision of default values for the width and height in the
<$parameters> widget; this ensures that transcluding the image without specifying any parameters continues to work as it does today.
Please note that these enhanced, parameterised images are not currently in v5.3.0, but I do hope to include them once the main PR is merged.
The plan is that v5.2.4 will be released soon (hopefully in November), and then if all goes well we will immediately merge the parameterised transclusion pull request into what will then become the pre-release of v5.3.0.
Why all of this added complexity to our release process? The reason is that the work on parameterised transclusion is fundamental to the future of TiddlyWiki, and so it is important that we get the best feedback we can before we make any final decisions.
At this point the changes are provisional, and explicitly subject to change. We’ve already had a lot of very helpful feedback on GitHub that has helped improve the quality and flexibility of these changes. But now that we have the basic reference documentation in place it is easier for non-developers to understand the changes and follow progress. (Documentation is like a bottomless put. I’ve spent a long time preparing a good deal of new material, but it is still thin in places, and I hope we’ll improve it together.)
I’ll emphasise again that feedback is welcomed on all aspects of these changes, but there are some specific open questions that I’d like to share here – most of them won’t make sense until after reading the documentation.
- The documentation introduces a number of new terms to TiddlyWiki. These terms are carefully defined, and are used consistently. However, I am not confident that we’ve arrived at the best choice of words for some of these new concepts. In particular:
- Is “procedure” confusing for the replacement for macros? It’s definitely quite long to type…
- Is “function” the best word for custom, parameterised filter operators stored in variables?
$$the best prefix for custom widgets?
.(period) the best prefix for custom filter operators?
- Are the new
<$fill>widgets the best names?
Questions or comments are welcome.