Additional And Configurable Markup?

[jonnie45]

Just a thought.

I wondered if the idea of having a few configurable markup options had been considered in the past?

To start with the default markup options

//italics//
strikethrough

So hypothetically if the symbol || was…

||available||

…( I haven’t checked it probably isn’t )

…for configurable markup ‘option1’ then this might be used together with a user defined CSS declaration class ‘mkupoption1’ with the context of a div or perhaps a span resulting in

<span class="mkupoption1">available</span>

I guess there are probably precious few, perhaps even no suitable characters left for additional markup but I do like the idea of a few user configurables.

This occurred to me whilst annotating text OCR scanned from a book into a tiddler, the author had already used italics and bold to emphasize certain words or phrases but I wanted to add additional emphasis on some phrases in a way that I can distinguish them from the authors.

I found myself wishing I could highlight on a word by word or sentence by sentence basis, maybe characters with different background colour as if I was using a highlighter pen - not sure I would play around until I found something I liked.

Of course I know how to do this with HTML and CSS “in tiddler” but I try to keep my tiddlers confined to regular text and regular Tiddlywiki markup as much as possible so the tidiest option in keeping with the way things are now that I could see would be a few option configurable markup options. If such a system existed it would be really cool if the options page that allowed you to change the CSS for a configurable markup also gave the option to define the icon to appear with it, perhaps also the crtl key shortcut.

I know there are some additional editor options for Tiddlywiki but I was thinking it would be nice to have a few configurable markup options ‘out of the box’ in the standard Tiddlywiki product?

*span is probably the most appropriate text container for text markup? It can always be promoted to an inline block in the CSS?

Alternative Option.

Presently the markup for bold results in

<strong>example word</strong>

If instead this resulted in

<span class="mkupoption1">example word</span>

And css, icons and shortcuts were all user configurable in a nice interface then the existing markup scheme would simply be the “factory defaults” that the user could alter to their own satisfaction.

I don’t think I have ever used strikethrough so I would probably change that to highlight and change the CSS and probably the icon to suit my new purpose.

[TiddlyTweeter]

@jonnie45

I wondered if the idea of having a few configurable markup options had been considered in the past?

Do you know about @pmario’s Custom Markup plugin?

[INTRO] the Custom Markup Plugin - beta

Hi folks, I did just update the Custom Markup Plugin Have a closer look at the table of contents and there is a Playlist at youtube. For those of you, that know the plugin already, be aware there are some breaking changes in V0.20.0 and V0.21.0! Have fun! Mario

Best, TT

[jonnie45]

Thanks I will take a look.

I think it might be a great idea if user configurable text styling markup were part of the standard product, absolutely no offence to Mario but he does warn of breaking changes - perhaps configurable text markup within the main Tiddlywiki product would be a better option for those seeking only a few minor tweaks to the factory settings.

I added a section at the end of my original post which occurred to me as writing - the question being why not have all text markup of the common text types…

bold strikethrough and italics etc

… have all of them coded as configurable markup so that the current text styling markup system is merely the factory default? If we could change the CSS for those markup classes, also change the icon and the shortcut we would have true freedom to stray from the factory settings as we see fit without additional plugins.

There would be a downside that when one user passed on an exported tiddler to another they would have to warn the other user “all my strikethroughs are configured as yellow background highlights” but if a plugin is required for markup then I guess users will also encounter issues if they exchange tiddlers with another user. At least they get the text they may simply need to edit it to remove or alter the non-factory-defaults markup.

[TiddlyTweeter]

@jonnie45

bold strikethrough and italics etc

… have all of them coded as configurable markup so that the current text styling markup system is merely the factory default? If we could change the CSS for those markup classes, also change the icon and the shortcut we would have true freedom to stray from the factory settings as we see fit without additional plugins.

My understanding is you can do that already?

Yeah, you have to find the CSS class for, say, bold on some item you want to change the look of. BUT once you have class you can easily override it with a supplementary style sheet (Tagged: $:/tags/Stylesheet ).

Your idea that there might be a system to modify CSS styling in a more end-user friendly way might work well in a plugin?? I’m not convinced it would be worth the overhead in the “core”???

(IF I understood you! )

Just comments, TT

[jonnie45]

Hi - No I don’t think so - that’s really the central point of my post.

I used Mozilla Developer tools to inspect the result of bold markup around a single word in Tiddlywiki.

See above

Presently the markup for bold results in

<strong>example word</strong>

So markup is being translated to HTML choices not CSS classes.

I’m not convinced it would be worth the overhead in the “core”???

Maybe you are right, I suppose when I wrote the post I was highlighting a kind of “in hindsight” maybe it would have been better if the core code had been designed initially to use configurable markup using CSS, not a criticism but often ideas spring from thoughts about design decisions that at least from one angle might have gone the other way. There may be very good reasons for not doing that way of course.

[TW_Tones]

@jonnie45

This occurred to me whilst annotating text OCR scanned from a book into a tiddler, the author had already used italics and bold to emphasize certain words or phrases but I wanted to add additional emphasis on some phrases in a way that I can distinguish them from the authors.

I found myself wishing I could highlight on a word by word or sentence by sentence basis, maybe characters with different background colour as if I was using a highlighter pen - not sure I would play around until I found something I liked.

This can be addressed by various means from CSS to adding classes to the existing markup.

Most existing markup allow “.classname”

eg

*.classname list item will add css to the line

Some text @@.classname more text@@ and continuing

There is a highlighter editor Tool bar button somewhere and you can wrap things with “@@”.

• I also have tools to wrap content in any tag which is easy to use for highlighting while in edit mode.

[pmario]

Hi Jonnie,

@jonnie45

I think it might be a great idea if user configurable text styling markup were part of the standard product, absolutely no offence to Mario but he does warn of breaking changes

No offence taken The closest thing you can use out of the box is described at: https://tiddlywiki.com/#Styles%20and%20Classes%20in%20WikiText

As Tony pointed out already it looks like this.

@@.myStyle any text @@

or

@@.myStyle
* List One
* List Two
@@

… and so on. …

---

General Comments

You did raise the right questions and had the right ideas. … The main problem is you will run out of available symbols very fast …

@jonnie45

So hypothetically if the symbol || was…

||available||

…( I haven’t checked it probably isn’t )

||available|| will cause problems with the existing parser in some edge cases. … We use it for transclusions (where it may work) but tables will definitely be a problem.

eg: The following is a valid table

|aa|bb|cc|
||xx||
| using ||available|| in a table will break it |

Nesting is a similar problem: eg: ||outer text starts here ||nested text wants to be here|| outer text ends here|| … That won’t work with the existing parser primitives.

---

About the custom markup plugin

The idea in the custom-markup plugin is, that you can write text like

°aside some text

and it will create an ASIDE HTML element and automatically add 2 standard classes, which can be used to style it.

<aside class="wltc-l1 wltc"><p>some text</p></aside>

°aside.myClass some text

would create the following HTML text

<aside class="myClass wltc-l1 wltc"><p>some text</p></aside>

As you can see of the “custom” markup starts at the beginning of the line it uses “block level” elements. If it detects a valid HTML element it will be used.

°div will create a DIV

°h2 will create a heading

Inline syntax is a bit more restricted. … As you wrote there is a lack of free symbols. We name them custom glyphs

Some /° this is a span and some /°.myClass nested text with a class°/ -- some more text °/

(html text manually formatted for better readability)

<p>
Some <span class="wltc-inline wltc">this is a span and some 
   <span class="myClass wltc-inline wltc">nested text with a class</span>
 – some more text </span>
</p>

As you can see, I did use different symbols for start and end. … The good thing about these “new” symbols is, that you can copy paste the text into an existing wiki and you get no wikification at all.

From my point of view that’s preferable over some completely wrong formatting.

---

Since I’m lazy I don’t want to write °div.myClass at every line I want to customize. That’s why there is a pragma definition the does the configuration once eg:

\custom degree='§' _element='div' _classes='.myClass' 

°§ my text starts here and is covered in a DIV with a class="myClass"

°§ Only 2 chars at the start of the line are needed

creates … (the text is manually formatted here for easier reading)

<div class="myClass wltc-l1 wltc">
  my text starts here and is covered in a DIV with a class="myClass"
</div>
<div class="myClass wltc-l1 wltc">
  Only 2 chars at the start of the line are needed
</div>

And to drive everything to the top, it’s possible to “call” widgets and macros like this:

°CLIP Paragraph 1

Paragraph 2
---

which calls a macro named clip (copy to clipboard), which is defined like this:

\custom degree="CLIP" _element="$macrocall" $name=".clip" _srcName="code" _mode=block _endString="---"

\define .clip(code)
\whitespace trim
<div class="doc-example">
	<$macrocall $name="copy-to-clipboard-above-right" src=<<__code__>>/>
	<pre><code><$text text=<<__code__>>/></code></pre>
\end

See example at wikilabs

---

For more info see the TOC: Custom Markup — create your own wikitext
Important: Start reading from the beginning.

[pmario]

@jonnie45

Maybe you are right, I suppose when I wrote the post I was highlighting a kind of “in hindsight” maybe it would have been better if the core code had been designed initially to use configurable markup using CSS, not a criticism but often ideas spring from thoughts about design decisions that at least from one angle might have gone the other way.

The main reason, why there has to be a standard is “compatibility”. So for copy pasting or export import between wikis, it helps a lot, if they use the same syntax.

@jonnie45

There may be very good reasons for not doing that way of course.

One more reason is speed. Parsing a tiddler is one of the most demanding tasks the core has to do. So it helps a lot if everything is preconfigured on the source level and the code doesn’t have to make too many extra decisions.

TW parsers are all regexp based and if a user creates a wrong configuration, it can “brick” the wiki.

IMO custom configuration of new and performant wikitext glyphs can be done — at startup only. I do have an idea for the custom markup plugin. … But it may lead to wikitext-syntax-anarchy …