- 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/6086c09e-ba93-41dd-ad6f-243b0b2953b6n%40googlegroups.com.

Reply via email to