Of course, many people deserve cred for the docs but at this moment I was particularly impressed with the layout for the CheckboxWidget doc which apparently @Yaisog has structured (pr).
Notice the table listing the attributes and that many of them are links. Clicking an attribute hyperlinks down to a tabs list, where the appropriate tag is automatically opened.
This is an exemplary use of tiddler real estate and ease of use!
Thank you @Yaisog
I think It’s a nice improvement, if we use the interactive version of TW.
But as all tab-based interfaces, at the moment, it falls short if we use the static rendering.
eg: https://tiddlywiki.com/static/CheckboxWidget
That’s true for all of our examples, that use “interactive” elements like: “Try it” for operator-examples …
So it would be nice, if someone could solve that problem too.
Hi @twMat, thanks for the laurels. I had originally intended to improve the docs for more widgets, but then life got in the way… Hopefully, I’ll be able to pick this up in the not-too-far future.
@pmario - could you split this out into a separate thread. I think it is a worthy discussion.
So, static solutions means there’s no JS (right?) so we’re limited to html+css. But my impression is that CSS solutions are not favoured for tiddlywiki.com ? Or do we (really Jeremy) accept special solutions for static tiddlers? [edit: I note that we do use the <details> element]
I have a working pure CSS variant for tabs. It it not as good as a full tabs macro but it, well, works. The basic strategy is to have all tabs open but hide all except the one whose “tab” you click at.
I think it does suit some users to use the static renderings on tiddlywiki.com, perhaps just because Google is apt to include them in search results.
We have rather lost sight of the fact that many recent docs improvements to add interactivity have also broken the static renderings.
As you note, we could therefore decide to limit the interactivity offered by our documentation in order to ensure that the static renderings work properly. That does seem a shame though.
The other alternative would be to refine our interactive components so that they work better in the static view. At the moment there isn’t a reliable way for a template to know that it is being rendered in a static context. If there was we could adapt the “tabs” macro, the testcase widget, and the existing example macros so that they rendered their content unconditionally, without requiring interaction. I think it could be done in each case.
A dozen or so years ago, state-of-the-art web development meant progressive enhancement; one wrote HTML that was semantically correct, layered on CSS to make for a pleasant presentation, and then added JS to create a more dynamic experience.
Would there be a relatively straightforward way to do so here? Could the tabs widget generate HTML like
<div class="tab-container">
<div class="tab-header">...</div>
<div class="tab1">...</div>
<div class="tab2">...</div>
<div class="tab3">...</div>
</div>
and then use JS to hide the unopen tabs and to handle the navigation between them? Then in a static context, all the content would be visible and usable. Does this sound doable with TW?
Hi @Scott_Sauyet the tabs macro does generate very similar code. The problem is that it doesn’t know how to render itself without the interactive parts. For example, it only ever displays the contents of a single tab, rather than displaying them all one after another.
It would be well worth fixing this. It could be approached in several ways:
I think this would be much easier to implement at the moment.
As an experiment, I did try to implement the tabs macro as a “custom widget” that respects a tv-render-static variable to produce different HTML code.
I did fail miserably for several reasons.
Well, I meant something more than the current behavior. Could we render every tab and then use JS to hide the inactive ones? If that JS didn’t run (as in static mode), then we’d just have a few separate divs, with a nav bar at the top holding links to the separate sections.
I think of this as a different approach from your two suggestions. The same rendering code runs in either circumstance. But in static mode the JS enhancement wouldn’t run.
Tiddlywiki of course doesn’t function at all when JS isn’t available, but here it might still be able to take some hints from the style meant to degrade gracefully in the absence of JS.
That can be a performance problem. Rendering 100% and then hiding 80% will make the “interactive” wiki not so interactive anymore. It would also start to get “janky” behaviour, drawing long content and then making it short again. Tiddlers below will start to “jump” back and forth.
I’m just wondering if that has been tested. I understand the concern. And it’s probably a bigger concern in TW—which is very js-centric—than in the simpler web apps/sites where I usually see this technique. But it would be good to know if this would be a real-world problem.
I’ve seen very little such behavior in the past decade from other progressively enhanced sites. It used to be a real concern, but it seems to have been overcome with better patterns and faster JS engines.
I’m not trying to push hard here. I was simply wondering if that technique had been tried in TW, and—if it failed—what caused the failure.
This is a pure CSS+HTML tabs display, no js.
I’ve also seen, in pure html+css, what can be comparable to tiddlers displayed in some grid-like pattern with a little X button in each “tiddler” to close it and, if I recall, have the remaining ones reorganize themselves to fill up the empty space. Unfortunately, it was quite a few years ago and I don’t find this webpage…
Also interesting stuff here.
I’m always impressed with the ingenuity of these, but the ones I’ve seen all have restrictions I don’t think we can accept in TW: a dependence on ids, small fixed number of tabs allowed, etc. I would love to learn that something like these could work in TW. But I don’t find one after a limited search.
Well, isn’t some dynamic functionality in static TW better than none?
BTW, what, actually, is it that we’re looking for? It’s been implied we’re looking for “tabs”. What other things do we need?
Well, if you put it that way!
I personally have been focused on having the same code run for static and dynamic views. If we forgo that, then there are many options. This might be a good one.
I dunno. Who started this damned thread, anyway? 
Jeremy mentioned earlier the testcase widget and the example macro. I wouldn’t be surprised if there were others as well.
I made this static tabs list. It is based on radio buttons which uses an id attribute but I don’t think this is a problem in this context - or is it? Exporting it as a static tiddler works fine as far as I can tell.
Nice!
I think we would also need to add the qualify macro. So I suppose the usage of ids can be managed, and with it the fixed number of tabs allowed. I don’t know how well these comply with accessibility standards… but then again, I don’t really know how much TW tries to pay attention to those standards in the first place.
There is a problem that I assume is solvable, although I haven’t tried: Keyboard navigation is broken.
But assuming that can be solved, this sounds like a great way forward, at least for tabs. We’d also have to deal with the testcase widget and the “Try it” buttons, but this is real progress!