*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 tiddlywiki+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/3410cd1c-894b-4bfd-9595-9b91e0b1acc5n%40googlegroups.com.
