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 tiddlywiki+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/0c6f9683-e1de-49ff-a61c-04986da6eaa1n%40googlegroups.com.
