In order to do this, one needs to replace the <$view> widget by a <$transclude> in the viewtemplate like this:
\whitespace trim
<h2 class="tc-title">
<$transclude field="caption"><$view field="title"/></$transclude>
</h2>
The <$transclude> widget has the same behavior as the <$view> widget regarding its contents.
Fred
I think however we could perhaps use the new cascade mechanism;
alternate-title.json (2.2 KB)
Why isn’t this in the core? I just google across this, and I decided to make a PR, so I don’t need to do this in every plugins.
It’s much closer to being in the core than before (given the cascade affordance), but this option is probably something that new users of several solutions such as streams (as well as my biblio solution under development) would want to access easily.
In case a novice browsing this thread would like some help finding the relevant cascade mechanism, here’s a screenshot:
And then the tiddler at $:/ui/ViewTemplate/title/useCaption has contents like this:
\whitespace trim
<h2 class="tc-title">
{{!!caption}}
</h2>
If you create a new tiddler and the caption is set to something different, all lists now use the caption and for new users it is easy to loose the tiddler. If we did this to the tiddlers in the story this may get even more confusing. For this reason I added an indicator to titles using the caption. You can turn it off, but having it by default may be wise if added to the core.
My use case is mostly with random generated title, like described in What’s the standard way to not writing Title.
Maybe it is better for me to include a custom cascade in those plugins that generate the tiddler with random title?
I would be more tempted to use something that generates titles from the context. For example for a projectname generate titles synch as projectname item N so you know what it relates to.
In some ways a feature of captions is in a way multiple tiddlers with what looks like they can have the same name.
I’ve been showing caption instead of title, AND 
I have some regrets…
(Granting perhaps for some projects — where public / reader and author are totally separate — one could let the cascade show ONLY a caption, because, say, “They don’t need to see what’s under the hood”… But it’s usually helpful for me, as author, to be able to distinguish title field from caption field at a glance!)
I now think the best practice, for most projects, is NOT to suppress real title entirely, but to make the caption prominent in the titlebar area (playing semantic role of “heading” for the content), while keeping the actual title visible somehow (or at the very least some clear visual indicator of the fact that one is seeing a caption there, rather than contents of the title field).
I appreciate the spirit of this comment above by @TW_Tones:
Still, I think I want something more constantly visible than a tooltip, such as faint text that darkens on hover…
OK, below is my current demo of a solution (four tiddlers under the caption-title-bundle tag), which together
(1) uses cascade to check for [has[caption]]
(2) per cascade, shows caption in place of title field in titlebar of tiddlers in story river. (Also applies a css class, caption-variant, so that when we’re looking at the caption (in titlebar), we can style it to mark the difference.
(3) bumps the real title, as a link, into beginning of subtitle area (but only if the caption exists)
(4) styles that subtitle-area real title link with <<colour muted-foreground>> — except hovering yields <<colour tiddler-link-foreground>>. Also styles the caption-variant class with a background color, so you can see immediately whether you’re looking at a caption.
This solution currently doesn’t work with uni-link plugin — which insists on replacing even the real title string in the subtitle area with the caption. If folks are interested (including @pmario) I could at some point look into the tweaks needed to protect a link from getting replaced by caption, exactly when the link is in this particular kind of location or role.
The uni-link plugin has a global option to show the caption or subtitle field in alias links. Creating this option was a mistake, because it’s not flexible enough. It’s only there for backwards compatibility.
That’s why the “alias-link” that should be used is [[alias-link|?s]] which is a shortcut for [[alias-link|?subtitle]]. This possibility is more flexible than a global setting.
For me the “subtitle” field is more important than “caption”. That’s why it takes precedence in my plugins but uni-link does not modify the tiddler title in the ViewTemplate. uni-link only modifies [[tiddler links]]
For me the tiddler ViewTemplate looks like this:
Where I add the “real title” as an H1 into the tiddler text. This allows me to keep the tiddler title unique and just change the H1 as needed. No side effects
I am yet to see your solution in action, but my own was a proof of concept I designed to fill a gap. It was closely related to my masquerade solution.
This was a responce to this topic alone.
Previously
I have the same view as you that it was importiant to know when a caption, alt-title, or masquerade tiddler title was in use especialy as a designer or author. I used the unicode letters inside a circle and superscript to indicate this after the title, but have an option to toggle thier display.
Hm, it seems to me that if the setting “treat titles as links” is on, then uni-link does affect even the tiddler title as it displays in titlebar. (And I always do have that setting on, because of my heavy use of linkstyle features.) At any rate, my concern just now was not about uni-link’s effects on the titlebar, but rather its effects on trying to display the real title as a link within the subtitle.
Of course, I understand that you have solutions that work for you and have clear logic. At this point, I’m already highly invested in leveraging the caption field (on a number of projects), so I’m trying to develop a caption-as-title (in titlebar) solution that does add better visual clarity (to recognize title vs caption), and doesn’t depend on other plugins. Still, it will be ideal to avoid actually clashing with uni-link. I’ll explore some more!
Have you looked at my alt-title or masquerade solutions? they may do what you want, or give you a platform to innovate?
I am reviewing my “alt-title and masquerade solutions” and I intentionally left caption out of it, because captions have their use as “short titles” in lists. That is why I would instead use the alt-title field. I need to add the aforementioned indicator use to show an alt-title is in use.
eg my Masquerading tiddlers optionally look like this;
[object-type[page]]
caption: only for tabs, shame but the semantics of a caption have been lost as a result
subtitle: my preferred titling method
title: TW’s unique “id”
uuid: my unique id used for most linking I need
I will have to check that, because I do not use “title-links” for my wikis. I did not ever test that case with uni-link. If uni-link interferes with the main title-links I do consider this a bug.
If wikitext [[wiki-links]] are used within the tiddler “subtitle” area the setting should be active. – But as I wrote, I discourage to use the global setting at all. I probably should make that clearer in the docs.
I think using “caption” for long titles is the “second” best way to do it. That’s why I did propose “subtitle” as an alternative for “titles”.
For plugins and eg: System Tags we do have “description” fields, which again are different to “subtitle”. For me a “description” is or can be a whole paragraph, which can be shown together with a modified version of the list-links macro.
This is a fascinating question, because to some degree, converging on a “best practice” is good for the community.
I take your comments to be very helpful in thinking through our “best practice” for how different fields perform title-adjacent functions.
Different projects have different data structures, and different users will have different associations with field-names…
I admit that relying on a subtitle field has not been attractive to me for two reasons:
Neither of these reasons are likely to matter as much to others as to me, but they do help explain why I haven’t used subtitle in the way you suggest.
Still, I must admit that caption already has a technical role in TiddlyWiki! And indeed, occasionally I’ve realized that I want a tab (say, in the sidebar) to show something super-short, but then that short caption may not belong in the tiddler’s titlebar — it’s not the most helpful string in a place where quite a few words can fit.
So I agree that using caption is probably not the best field for holding what I really want to see in the titlebar (though it may still belong in the cascade of things to look for). Darn, I’ll have some reworking to do, since I’ve been deploying caption-based tweaks across many wikis.
I wonder whether I might consider a field called heading2 or even h2 — since (after treating heading1 as aligning with the title of the whole site) and heading2 is the html heading applied by default to the tiddler title — or whatever is getting displayed in that role at the top of the tiddler… 
Agreed. But that’s because…
And that titling in TW is “overloaded”. The “problem” compounds.
I’m intrigued by Mario’s approach…
I might play around with that at some point. For me, <H1> isn’t a tag I ever use, so that frees it up for title-use.
Certainly there can be some side-effects (to solving the “title field doesn’t contain what I need to see at the top” problem by just starting the tiddler’s text field with a title-ish heading using <h1> tagging):
(1) This takes up space within the tiddler
(2) That internal heading will now show up when that tiddler is transcluded (remember some transclusions are quite short and functional), and
(3) Viewtemplates for the tiddler body that aren’t really based on the text field won’t show this at all.
[EDIT: (4) There are also these questions about heading-levels, which prompt me to start in-tiddler headings with h3…]
Of course, these side-effects may not matter within some projects. For my projects, I want a field to hold the meaningful words that — at least sometimes — belong in the titlebar instead of (or more prominently than) the title field.
Of course. That’s why I said “for me”. I’m in control of how my text field is displayed for viewing. Today, I’d have used cascades, probably, but I use my own code to slide/dice the content to present the view I want/need.
I am, of course, talking about content tiddlers, not every tiddler.
As do I!.. Yet we all are doing so much sharing of solutions, and we’re also thinking about community editions. So I appreciation taking time to reflect together on what might make sense as a path to recommend broadly.