I'm not following all the tech discussion here, but I like the idea of accessible, standard documentation that's trivially easy to author.
One good example that comes to mind is the documentation for ansible modules. There are lots of them, and they all have consistent, (mostly) understandable docs. Perhaps there are some ideas there you could borrow or steal. A particularly useful section is the examples. For widgets a set of good examples would be handy, and perhaps easier to use casually than the formal syntax definition. Example: https://docs.ansible.com/ansible/2.9/modules/copy_module.html#copy-module (Find many others here:) https://docs.ansible.com/ansible/2.9/modules/modules_by_category.html On Mon, Jun 7, 2021 at 7:22 PM TW Tones <[email protected]> wrote: > Sorry, > > I meant to add I think version three could be at the bottom of every > definition with all parameters, copy or drag. > > Tones > > On Tuesday, 8 June 2021 at 09:21:02 UTC+10 TW Tones wrote: > >> *Stobot et al* >> *I'm not that familiar with screen readers etc. but if you want to take a >> crack at an example to help me understand, I'd be happy to look at it* >> Nor am I but alt apparently making use of alt text is important for >> images at least. No what I am saying is making use of the other features >> like mouse over, tooltips etc... Of late I have being getting into >> draggable payloads, especially of content as I describe in *On syntax >> formats* below. Just drag a syntax form into your tiddler and edit. >> >> *On Syntax formats* >> To me version one is almost useless, it resembles the list of parameters >> already documented. But you still need to refer to the rest of the >> document. Using version one as a code snipit still requires a lot of work. >> I would favor version 2 but one for each of the different configurations, >> ie a subset of parameters for each common form of the widget. >> >> *The details widget.* >> >> I use the html one a lot more know since something changed to make it >> more reliable. It does store the initial state (open or closed) just not >> the ongoing state, and in a larger number of circumstances this is all you >> need. Also keep in mind that even the existence of the details widget can >> be inside a list/reveal itself which is conditional. It is ideal for more >> or less content. Using the summary tag you can actually place macros in the >> details "heading" to show the number of something there inside the details >> tag (I do not think $details does this). >> >> Not with standing this, there is the details widget in a plugin >> https://tid.li/tw5/plugins.html#DetailsWidget and 14kb in size, but I >> have not used it much lately. >> >> I wish we could get the equivalent of the old TWC nested sliders plugin >> but perhaps this can be emulated in Mario's "Custom Markup" as he has also >> demonstrated the the details widget can. >> >> *That reminds me;* >> We could document a lot more features and methods in tiddlywiki or a >> separate wiki that are not just about widgets, macros tweaks and filters, >> but also making use of html and css. For example using css to toggle >> content display: none; and possibly classes such as nest nest1 nest2 would >> stand in for the nested sliders plugin. >> >> >> >> Although the reality is the Custom Markup plugin may be the most valuable >> plugin since "relink" and possibly of even more consequence. >> >> Regards >> Tones >> >> >> On Monday, 7 June 2021 at 22:44:42 UTC+10 TiddlyTweeter wrote: >> >>> >>> - To TiddlyTweeter's point, if <$details> stored state, wouldn't it >>> just be a less-flexible <$reveal>? >>> >>> RIGHT. Point is it is just a dumb state that requires NO state tiddlers >>> at all. You can simply, directly, change the toggle state. >>> >>> It is mostly ONLY useful for ON/OFF situations. >>> For that it is elegantly simple in code! >>> >>> TT >>> >>> >>> On Monday, 7 June 2021 at 13:15:15 UTC+2 Stobot wrote: >>> >>>> Great continued feedback. I'll keep going, but just to mass-reply: >>>> >>>> PMario >>>> >>>> - I agree that the "closed version" should be in a small general >>>> syntax notes area - maybe right below the syntax block. Things like: >>>> - Each attribute can be given as "Text Value", {{Trancluded >>>> Value}}, or <<Macro Value>> >>>> - Still thinking through how to handle the "or" situations (need >>>> tiddler value or tiddler and field, or just field, or tiddler and >>>> index...) >>>> - Soren had the one example which might be great. I currently >>>> don't understand it clearly though, so will think on how to simplify >>>> it >>>> >>>> Tones >>>> >>>> - I'm not that familiar with screen readers etc. but if you want to >>>> take a crack at an example to help me understand, I'd be happy to look >>>> at it >>>> >>>> Ste >>>> >>>> - I'll check out the stretch text thing. Others have suggested >>>> details which seems to have similar aims (though is non-core) >>>> >>>> Mohammad / Odin / TiddlyTweeter >>>> >>>> - I think version 1 is good myself, and version 3 for completeness. >>>> Might think about the best method to include both - via some mechanism >>>> like >>>> stretch-text / details / reveal / tabs (most core-ish I think) >>>> >>>> <details> (PMario / TiddlyTweeter) >>>> >>>> - Funnily enough the *only* thing that I can see useful about the >>>> <$details> widget is that it *doesn't* store the state (which keeps >>>> size & >>>> # of changes down). >>>> - To TiddlyTweeter's point, if <$details> stored state, wouldn't it >>>> just be a less-flexible <$reveal>? >>>> >>>> Thanks all, I'll keep plugging along and circle back to get more >>>> feedback in a while. >>>> >>>> On Monday, June 7, 2021 at 5:47:53 AM UTC-4 TiddlyTweeter wrote: >>>> >>>>> >>>>> TiddlyTweeter wrote: >>>>>> >>>>>>> ... using either *<$reveal>... *or <details>... to hide sections so >>>>>>> its not too overwhelming and the end-user can expand only the sections >>>>>>> they >>>>>>> need to see. >>>>>> >>>>>> >>>>> PMario replied: >>>>> >>>>>> At the moment Jeremy doesn't accept PRs that contain the <details> >>>>>> element, because it doesn't store open/close state. >>>>>> I think, we need a <$details> widget, that can handle persistent >>>>>> state, in the core first. >>>>>> >>>>> >>>>> HA!* <details> *is super simple. ADD "open" or remove it. >>>>> * Should be a doddle. * >>>>> It is NOT intelligent like *<$reveal> *which handles well complex >>>>> situations, but in MANY use cases <details> binary sate is all you need. >>>>> >>>>> Side comment >>>>> TT >>>>> >>>> -- > You received this message because you are subscribed to the Google Groups > "TiddlyWiki" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/tiddlywiki/0c6f9683-e1de-49ff-a61c-04986da6eaa1n%40googlegroups.com > <https://groups.google.com/d/msgid/tiddlywiki/0c6f9683-e1de-49ff-a61c-04986da6eaa1n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- [email protected] -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/CA%2B9aNS-7bw6Cnjcx6UNgMUZLms%3D%3DH5qyVZCqUvA4tGbQGegQ8g%40mail.gmail.com.
