Tiddlywiki5: Details widget in core

[AnthonyMuscio]

I usually have the detailsWidget plugin from Thomas Elmiger on my wikis for a quick and smart looking more details view, see http://tid.li/tw5/plugins.html#DetailsWidget

However as much as I like it, a plugin for such a basic function is annoying. Would it be difficult to move it into the core?

[pmario]

I think, the reveal widget and the TOC do the exact same thing in a "tiddlywiki-way"

Reveal widget is part of the core, because it provides the basic building part for a lot of other functionality implemented as plugins. eg: TOC macros.

There are several possibilities to create a TOC ... tag-based and field-based.

IMO it makes sense, that functionality, that can be achieved in many different ways are implemented as plugins and not be part of a bloated core.

[Jermolene]

In terms of moving the functionality into the core, I concur with @pmario, and would add that native HTML <details><summary/></details> works out of the box in TW5; @telmiger's plugin is catering to some specific use cases which I think belong in a plugin.

[telmiger]

1. I am not entirely sure, a native HTML solution is good enough. I am afraid, if a user toggles open/close without a TW state, his/her choice could be lost during TW rerendering. But maybe you can convince me?
2. We have shortcuts for other HTML elements like quotes – why not for details?

[pmario]

We have shortcuts for other HTML elements like quotes – why not for details?

IMO this is something different! ... I didn't like the following construction

<$details summary="Compare the DeatilsWidget and the RevealWidget" state="!!accordion-second">

you text comes here!

</$details>

BUT if we can find a nice wikitext syntax, that does create the new details html element, I'd like to think about that.

The reveal-widget is relitvely hard to use for newbies. .. If we could combine "reveal" and "details" I think it would be nice.

[Jermolene]

Hi @telmiger @pmario

I am not entirely sure, a native HTML solution is good enough. I am afraid, if a user toggles open/close without a TW state, his/her choice could be lost during TW rerendering. But maybe you can convince me?

Indeed, using details/summary in TW5 can be brittle, but there are many situations where it's useful.

Stepping back, the OP here was asking whether this plugin can be "moved into the core". It's worth clarifying that I interpret that statement as meaning "can this functionality be refactored so that it is intrinsic to the core, instead of being packaged as a separate plugin". Decisions about what goes in the core are a very complex trade-off, and the bar is quite high: once we add something to the core it is irrevocable, our backwards compatibility goals mean that we can't subsequently take it out or change it.

In particular, any discussion about moving things into the core that already exist as a plugin are going to be harder. There has to be a very strong case for all the extra work and the long term burden of changing something that already works.

There is another interpretation of the OP, which is to ask whether a plugin can be made available in the core plugin library so that it's easier to find, install and upgrade. Easier third party submissions to the plugin library is on our roadmap, but we're not there yet.

[AnthonyMuscio]

Folks,

May I please restate this request?

Perhaps I should say "available in the empty.html" and documented in TiddlyWiki.com - not in the core, which throws developers into a debate :)

Having a basic clear text reveal slider is all I am asking for. See below the following alternatives I have now

1. Reveal (has any thing you need but is a mess in content)
2. <$details widget from $:/plugins/telmiger/details
3. HTML

All have there limitations, for something I imagine every user needs, and should be there, and should be non-intrusive in long content tiddlers, because that is where they are needed. Using these options is like a lucky dip because of subtle differences.

1. Not at all friendly to insert in Wiki text when you are writing content, How confusing it is when I return to edit a lot of text with a number of reveals therein, and by the way when do I need to reveal text - when I have lots of text. Fully featured has everything including state, open and closed, requires 2 buttons
2. Needs a plugin, I need this in any wiki I am going to share my long wiki text with that uses the details plugin, Great control just as for reveal, but much clearer, familiar to HTML coders, state... Need to install, need to tell people using my content to install etc...
3. Built in, undocumented on tiddlywiki.com, cant save state, "Sometimes" renders differently to $details and $reveal, familiar to HTML coders but no access to JavaScript for states and on click etc... Needs additional styling to be clear it is click-able.

None of the above are in my view adequate, using all of the above is a pain because I need to swap and change depending on the context and content, and each has sometimes subtle difference.

Finally, the plugin, as an example of placing code in the empty.html is 657 bytes in size, and if built in may be made even smaller, especially if it calls on reveal for most of the work.

<$reveal type="nomatch" state="$:/state/SampleReveal2" text="show">

<$button set="$:/state/SampleReveal2" setTo="show">Show me</$button>

</$reveal>
<$reveal type="match" state="$:/state/SampleReveal2" text="show">

<$button set="$:/state/SampleReveal2" setTo="hide">Hide me</$button>

! This is the revealed content
And this is some text

</$reveal>

---

<$details summary="Show me">

! This is the revealed content
And this is some text

</$details>

---

Show me

! This is the revealed content
And this is some text

[AnthonyMuscio]

Now the speculation

I am using html much more now in TiddlyWiki than ever before, especially when HTML is clearer and achieves the same results, or when I like the look of something I find on the net. There is no reason to me why TiddlyWiki should not do its best to support HTML use.

There are a small set of cases where html must resort to javascript for everyday requirements, which of course do not work in TiddlyWiki such as on click or accessing a variable or text references, or changing or returning a state tiddler or field/variable.

If we could find a way to support the integration of HTML with TiddlyWiki for these "primitives" I believe this would be very popular, one way maybe to have some basic functions that "emulate" common html javascript functions OR extend the way WikiText containing HTML is parsed, so that the two work better together.

[pmario]

IMO this is not good enough. ... I would be in favour of a wikitext solution.

<$details summary="Show me">

! This is the revealed content
And this is some text

</$details>

[telmiger]

@pmario I guess we all would favour a wikitext solution. But when I made the plugin, I could not think of a wikitext solution that could handle these points:

• open state (Optional initial state, set to "open" to show details on load. Defaults to "".)
• state saving (An optional _TextReference_ containing the state. Wins over open.)
• the fact that a details section can contain anything (transclusions, buttons, titles, ...)

The only similar existing wikitext element I can think of now would be the blockquote. Would someting like the following be doable?

<<[.tc-hint-details Show me
! This is the revealed content
And this is some text
<<[ open _"$:/state/myDetailsStateTiddler"_

If yes, I think this would be nearly equivalent to what my plugin is able to do.

[pmario]

<<[.tc-hint-details Show me
! This is the revealed content
And this is some text
<<[ open "$:/state/myDetailsStateTiddler"

@telmiger ... You are right. Such a wikitext is much more complicated, than a named parameter approach using the widget.

[pmario]

At the moment I'm having a closer look at the DOM structure that is created by the plugin.

[pmario]

I did have a closer look at MDN and the SPEC

It should be like this:

<details>
    <summary>Details</summary>
     ... all the content, including additional detail elements ... 
</details>

The DOM structure in the implementation is:

<details>
    <summary>Details</summayr>
    <span>
       ... all the content, including additional detail elements ... 
    </span>
</details>

IMO the additional hardcoded <span> as a wrapper needs to be removed. Text styling can be directly applied to the details element, which can handle all flow content elements.

The <span> should only include phrasing content, which doesn't include nested details elements. ...

[telmiger]

You are right, @pmario – I guess I added the span as a shortcut because I could not see another way to style the content only (in other words: without having to remove it again from the summary):

details > span {
padding: 0 0.75em 0.1em 0.8em;
display: block;
}

I don't remember, why I used a span instead of a div ... but to remove it would be better anyway.

[pmario]

The class parameter can be assigned to the details element. eg: myClass If a class is assigned to the details, it should also be added to the summary with a postfix eg: myClass-summary

With this mechanism it shouldn't be needed to create details > ... which will cause problems if transcluded "details" are used. ...

[pmario]

You already use tc-details for global styling, so imo there should be a tc-summary too. So the easiest way to style them consistently would be with those default classes.

[telmiger]

@pmario I am working on a new version with better CSS and without the span. But I doubt any tc-class is necessary. The tags <details> and <summary> are so specific, you would not want to use them in a different context. And if you need variants, you can add your own class via _class_ parameter.

[pmario]

But that would be different to the rest of the core.

[telmiger]

@pmario Other standard HTML tags without tc-class in TW: ul > li, dl > dt, table > ...

[Jermolene]

Hi @telmiger @pmario watching the discussion, and looking at the code, I'm wondering again whether this is appropriate for the core. One of the goals of the core is that the features be as near universal as possible; the restrictions on the <details> element are actually quite limiting:

• Microsoft has not yet implemented details/summary in their Edge browser. It is listed with “Roadmap Priority: Medium — Development is likely for a future release” – see their Platform status.
• Internet Explorer in general and Firefox before Version 49 do not support details/summary either.
• Other browsers might not support animation effects on opening or closing – at least not in early 2017.
• Apple iOS mobile browsers lack support of toggle events on details. Therefore we emulate the toggle event using click. In mobile Safari this can have the side effect, that users must tap twice to open/close details or to activate links in details. Firefox mobile seems to work.

On the whole, it feels more attractive to use a "native" equivalent without any of those disadvantages.

[telmiger]

Hi @Jermolene, Microsoft Edge has a new status (I will have to update the docs too):

NOTE: A first implementation landed in some Preview builds of Edge, but we had to pull it off due to quality issues.

Roadmap Priority: High — We intend to begin development soon.

I think the OT was restated in https://github.com/Jermolene/TiddlyWiki5/issues/3353#issuecomment-404383188 and could be interpreted as a plugin in the official library now. Would that make sense?

[Jermolene]

Hi @telmiger ah, OK. I'm generally not persuaded by the argument "plugin X is so useful that it should be included in empty.html" because it undermines it's purpose: from a user perspective, the empty edition is empty so that the user can choose what to add to it, but it also serves as a "minimum viable platform" for the community. When we talk about "add these two tiddlers to an empty wiki" there's a clear meaning.

I've no objection to creating separate editions of TiddlyWiki that have different bundles of pre-installed plugins, though.

[telmiger]

Hi folks, my new version is online: https://tid.li/tw5/plugins.html#DetailsWidget including a somewhat updated documentation. Usage on iOS is better now on my personal devices, so maybe I could remove another limitation soon. CSS is much simpler and better now – but devided into two files, the intention is to make it easier to just define other colours for users.

@Jermolene we are on the same page concerning empty.html

[pmario]

@telmiger ... From my point of view the widget DOM looks good now. ... But as Jeremy said, it should be kept as a plugin at the moment. ...

Browsers will evolve faster as we can think about it. ... I think it's ready as PR for a future TW version. ... soon ;)

[pmario]

Had a short review of the code. ... Nothing that jumped into the eye. so LGTM

[telmiger]

After another round of optimisation and bugfixing I became aware of a problem: I can’t find a way to put tags or wikitext into the summary. According to the spec it should be possible to have someting like <summary><em>Text</em> in italics</summary> ... and I really tried almost everything:

• summary = "<em>Text</em> as parameter
• summary = "''Text'' more text" as paramenter
• new lines in the parameter
• adding new lines via JS after processing \n as well as \r\n
• wikifying the result after processing (with and without new lines)

So if anyone knows a solution that works with my tests at https://tid.li/tw5/plugins.html#Details%20Advanced%20Examples I would be very grateful!

[sukima]

The discussion shows this as a little bit of a sore topic but I wanted to offer an alternative for those who might not need all the features of the plugin and am OK with the trade offs with the vanilla <details>.

I add the following to my Wikis:

Custom Macros (tag: $:/tags/Macro)

\define fold(tiddler, summary)
<$set name="title" value="$summary$" emptyValue="$tiddler$">
<details class="fold" open><summary><<title>></summary>
<$transclude tiddler="$tiddler$" mode="block" />
</details>
</$set>
\end

\define folded(tiddler, summary)
<$set name="title" value="$summary$" emptyValue="$tiddler$">
<details class="fold"><summary><<title>></summary>
<$transclude tiddler="$tiddler$" mode="block" />
</details>
</$set>
\end

Custom CSS (tag: $:/tags/StyleSheet)

.fold[open] {
  border-bottom: 2px solid #eee;
  background-image: linear-gradient(#eee, transparent 100px);
}

.fold > summary {
  display: list-item;
  background-color: #eee;
  padding: 4px 6px;
}

.fold > summary:hover {
  cursor: pointer;
}

.fold[open] > summary {
  background-color: transparent;
}

Which allows me to do the following:

<<fold "MyTiddler">>
<<fold "MyTiddler" "Custom summary text">>
<<folded "MyTiddler" "Initial render closed">>

It should be noted that the vanilla (empty) theme buggers up details/summary because it resets the display of <summary> to block instead of the browser default of list-item.

Also WikiText has difficulty if the content is inline and needs a way to be forced to be block. In the above macro transclusion is set mode="bock" but if you venture to do your own <details> as HTML manually you will have to make sure you don't accidentally trigger an inline WikiText. Either wrap your content in a <div> and/or always use <$transclude … mode="block"/> instead of {{…}} when inside a <details>.