Modifying wikitext for headers to be collapsible?

,
#21

Short answer: I don’t know.

Longer answer…

You’re heading off into the realms of I-don’t-know-where (that’s why I didn’t add your css to my 0.2). I prefer to stick with something really simple and wait for @jeremyruston’s intrinsic support to appear.

Having said that, I’m tinkering with a \widget + <$genesis> combo, just for kicks.

Currently looking like this…

<!--$ $.ce
  @param tag <string> The tag to hold the `text` parameter.
  @param id <string> Becomes the `data-id` attribute that uniquely identifies this widget.
  @param text <string> The text to be inserted in the element identified by `tag`.
  @comments Provides a collapsible-expandable element (akin to the HTML details element).
$-->
\widget $.ce(tag, id, text)
<$eventcatcher selector=<<tag>> $click=<<$.ce-actions>> tag=div class="ce-catcher">
  <$genesis $type=<<tag>> data-id=<<id>>> <<text>> </$genesis>
  <$slot $name="ts-raw"/>
</$eventcatcher>
\end $.ce

\procedure $.ce-actions()
<!-- <<alog $.ce-actions "dom-data-id dom-keep-open">> -->
<% if [<dom-keep-open>!match[true]] %>
  <$action-setfield $field=selected-header $value=<<dom-data-id>> />
<% endif %>
\end

Strangely, in use, it makes the wikitext look more cumbersome…

<$.ce tag="h1" id="mercury" text="About Mercury">
<div>
Mercury is extremely hot and extremely cold.
</div>
</$.ce>

That’s a lot of technical debt (and repeated use of $eventcatcher) for such ungainly looking wikitext at the point it is used. See my point? I’ll wait for Jeremy.

#22

yeah… Well this is useful in testing alternatives but I don’t think we are currently on the right track for the kind of behavior that should be the end result.

That being said, this would be useful for other things, and is giving us something to test ideas out on in the meantime.

TBH, I wish I knew more about eventcatchers and parsers, and in general the more advanced functions in tiddlywiki so I could build my own experiments.

Would it be useful to have a list or outline of what the ideal behavior would be? IDK if providing it will help others get a clearer idea or not.

#23

Something you asked earlier (can’t be bothered to go look for it) about what if the field comes from elsewhere…

The code as it stands targets fields on <currentTiddler> so…

<$let currentTiddler=somewhere-else>
<h1...

or

<$tiddler tiddler=somewhere-else>
<h1...
1 Like
#24

Ahh, yep. No worries though, if we do stick to this route then I’m pretty sure we can use targetTiddler variable or storyTiddler variable instead if I remember right (I cant remember the exact name of it atm… :sweat_smile:)

#25

Clearly. That’s why I mentioned the tabs macro earlier – clicking on something, then, elsewhere, something happens. At the moment, the “wiring” happens in the CSS tag + tag. Imagine if that was a different coupling…

#26

I believe if you study it there are CSS based ways too do this the main trick is the selection because h1 is <h1/> or self closing.

Not withstanding this the solution is most likely hiding in @Mohammad’s section editor which is driven by headings.

Further, I think as @jeremyruston said it is reasonable, and tiddlywiki classic had the slider macro, we could use + ++ +++ or other symbol for such sections and searching and replacing leading ! With + and +++ etc…

@pmario s custom markup may be able to do this but there is value making this more mainstream.

#27

Forgive me if I’m wrong but, I haven’t seen an h1 element used in a self closing format before. I’ve only ever seen <h1>Header One</h1> in my years of hobbiest webdev. If you don’t mind me asking, how would you format a header with <h1/>?

Interesting! I wasn’t aware of this but at first glance it’s including exactly what I was looking for, though I’m unsure if there is a way to do this without the need for the se-type field used for what the plugin refers to as patchwork tiddlers.

Addendum to this, even though the plugin discusses it being able to collapse all header levels, only levels 1 and 2 seem to collapse :thinking:

I’m afraid I cannot find any relevent examples of collapsing headers or the ability to do so in Pmario’s markup plugin. I’m sure there is something here but, it may be beyond me to see it :sweat_smile:

#28

Because it’s not allowed:

image
image729×376 30.9 KB

#29

Hmmm, That’s a bit opinionated, because the user looses control over the behaviour of every single heading. So from my point of view, it needs to be possible to define the functionality on a per heading level.

The description of starting a heading with a dot - .! is very close to the behaviour the custom markup (CM) works.

At the moment defining a block in CM we need 2 elements: a start glyph eg. degree ° and a userSymbol eg: !

So the custom markup start delimiter for a heading-1 would look like this: °!
The stop delimiter would be 2 new-lines.

But that’s not, what the OP wants. It wants to be able to define custom blocks. So at the moment the CM end-delimiter would need to be an end string eg: _endString="===" or something similar.

Since an HTML H-element does not have the ability to fold, it would need to be something different. eg: details and summary combination, which would work out of the box in CM

You probably did not search for the details element. I will upload a new example to the CM-page which you can test.

BUT that probably will still have more wikitext as you want. The definition can be in a separate tiddler.

Custom Definition

Line 1 defines °! as a start marker for the details element. End marker is: /! – (Almost everything is possible here.)

Line 2 defines °s as summary start marker. End marker is 1 new-line

Line 4 defines details level 2 with start: °!! and end: /!!

\custom degree="!" _element="details" _endString="/!" open  _mode=block
\custom degree="s" _element="summary"

\custom degree="!!" _element="details" _classes="" _endString="/!!"  _mode=block

Custom Wikitext

With a details level 1 and level 2. Where level 2 is nested inside level 1
The advantage is, that the output is semantic and accessible HTML

°! °s details level 1

line 1  
line 2  
adsf 

°!! °s details level 2

{{test}}
/!!

Some more text

Looks like this:

image
image1745×1273 155 KB

You can test it at: Custom Markup — create your own wikitext

test-details-open-talk.json (472 Bytes)

1 Like
#30

At the moment CM can not define a “start marker” as an “end marker” at the same time. At the moment they have to be different. Because the “end marker” is “eaten” by the parsers.

It may be possible to define an option, that allows start-markers of the same type to be
detected as end-markers for the previous element.

So there would be no _endString needed, but still be able to nest wikitext – But that’s just brainstorming

#31

@CodaCoder – That’s an interesting approach. I’ll have a look if I can define it using the custom markup plugin. If the concept was right, it should work out of the box.

The advantage of your approach is, that it would be able to store the state, which is not possible with the details widget experiment I did post. But I think I can combine your idea of a custom widget with my idea for custom markup.

That’s interesting :slight_smile:

#32

Agreed, while remaining “tiddler agnostic” in the sense that the location of the field (i.e. where we store the status) isn’t determined until render-time. At least, that’s how it was initially written…

The other thing… its ability to collapse/expand doesn’t happen in wikitext, per se, but in CSS.

(Of course, I shouldn’t ignore $eventcatcher… without which we wouldn’t be talking about this :wink: )

#33

The “issue” I have left is how best to abstract the CSS (the <style> element) from the demo tiddler into a stylesheet tiddler – getting currentTiddler to work in the CSS such that {{!!selected-header}} resolves correctly. That’s easy in the scope of a regular tiddler but it will lose that scope in a stylesheet tiddler.

Maybe I’ll end up with a macro that transcludes the required css… or leave it like it is :confused:

Thoughts?

#34

I didn’t follow this thread before. But once I’m reading it, it doesn’t seem to be about “overriding default wikitext’” per se. It’s about a particular desired GUI — being able to collapse stuff under headers. Is that right?

Have you checked out the Section Editor plugin by @Mohammad?

https://kookma.github.io/TW-Section/

I know you said you didn’t want plugins with lots of additional bells and whistles, but really, getting headers to behave like collapsible <details> sections is pretty much the central feature of that plugin… At any rate, you could look at that, and clone a version that boils it down to what you most care about.

(For my own part, I was disappointed that it can’t really handle nested hierarchical layers intuitively. And apparently there were good technical reasons for that single-level-deep limitation. So I actually generate old-fashioned <details> and <summary> tag-sets quite a bit, since they can be made to nest pretty well as needed, and will nicely export to html as needed.)

#35

Yes. And you’re right, it did wander off into one specific use-case.

Jeremy’s and Mario’s answer talking about his custom markup parse are certainly on topic. My stuff is about trying to solve OP’s use-case (which he was clearly happy to pursue).

I did wonder though, @Justin_H, did you want to change the topic title?

#36

Yea, I should probably reword the title to be a bit more precise. Let me take care of that right quick!

But yes I was directed to it, and I was impressed by it, but I believe the discussion moved to a different approach afterwords.

2 Likes
#37

Just a short update regarding the topic, since we’re talking about it, I’ve been recommended to a few plugins for reference, but there was talk of a custom parser idea that I think was the main aim.

The things I’m really looking for were:

  1. Doesnt change the syntax of the header wikitext (ie !!! HEADER 3 would be used and show as a dropdown, say as if you were to make an <h3> element)

  2. The default setting should be all headers being open, and close independently of one another. (Though there was a cool accordian effect achieved by storing the open state in the tiddlers field that looked cool)

  3. Didnt include extra functions or unrelated features if possible.

I’m still thinking about if theres a way to clone the javascript tiddler but instead have it place the header elements inside ul li elements, or even just in a div that can have an eventcatcher or onclick function, that way it doesnt break accessibility.

But thats all just braindumping :sweat_smile:

#38
  • It would operate until next Hn tag, and needs to know how to handle Hn+n
  • I think that is a setting
  • Its being a long time, it would be a block mode definition, but I would consider using a different wikitext character and not use headings even if they look like headings. eg the aforementioned +

You may feel this desirable, but you are proposing changing what is effectively and normally a simple implementation of html headers. I think this unwise and may have unwanted side effects. If you can limit this behaviour to the text field of a nominated tiddlers perhaps. But seriously why not replace ! !! and !! with + ++ +++ or similar wikitext character and allowing an optional close such as = == and ===?

  • Keep in mind such an alternate symbol can be applied with a search and replace.
  • Similarly you could apply a class to each header eg !.hopen !!.hclosed using existing methods if you can leverage the hn html elements.
    • I am confident there are ways to hack CSS now that may allow you to leverage something like nth to scope to the next Hn but it would need a real CSS wizard. Animatingor display:none may be the answer.

Once you have a mechanism to do what you want, with out changing existing wikitext, it is possible to introduce tools to easily convert from headings to this alternative in selected text/tiddlers or view template, ie restraining its scope.

#39

Well, I guess if that would be the only really feasible to achieve this, then I could adjust, but that does still leave the challenge of how to create collapsible sections with headers.

The reason I want to avoid it is so that you can still export the text and send it to someone who maybe doesnt have this configuration, but still wants to view it with the same header formatting applied.

Instead they would see

+++ Hello There

How are you

+++

And not

!!! Hello There
"""
How are you
"""

Which the 2nd translates correctly to

<h3>Hello There</h3>
<p>
How are you
</p>

Unless you exported it after it was parsed, atleast that is my understanding.

#40

There are a range of ways to effectively do this separate from the html h tags.

  • I will experiment.

Of course we could quite easily make an export, a template or batch do this conversion.