Standard WikiText & Custom Markup - DOC suggestions

[TiddlyTweeter]

I'm starting this Discussion to, hopefully, explore the ways we can integrate Standard WikiText with @pmario's Custom Markup (CM) system. I'll make posts about existing WikiText behaviours one-by-one and then make a few observations and raise some questions in relation to CM.

[TiddlyTweeter]

WikiText Tables (overview)

Standard WikiText for tables is pretty amazing! Ever since I started using TW I have used it extensively. It is very sophisticated with great "cell merge", "cell align", make cell a "th", auto creation of "thead" & "tfoot", application of "class", creation of "caption". It is well documented at: Tables In WikiText. In brief...

I'll comment on some interesting issues with the approach next.

[TiddlyTweeter]

@pmario I thought your table examples interesting. I stole a couple of ideas from them :-). In testing using CM for tables I was interested, like you, in being able to more easily edit larger data cells. In this (with the right pragma definitions) CM is definitely easier than Standard Wikitext.

In the example below I pass attributes into the <col> like <col span="2" style="width:8rem"> Thought it might interest you. Note that ﹙ little﹚ 's default behaviour is reassigned to <td>. Its a full table with all segments. You can edit and break lines wherever you want. It still renders correctly, I think. For some situations that behaviour could be helpful?

\customise angle=TABLE _endString=«TABLE _element=table _classes="class-table" _mode=block
\customise single=CA _element=caption
\customize single=CO _element="$macrocall" $name="addColSpan" _1="cols" _2="width"
\define addColSpan(cols,width)<col span="$cols$" style="width:$width$">
\customise single=HE _endString=‹HE _element=thead
\customise single=BO _endString=‹BO _element=tbody
\customise single=FO _endString=‹FO _element=tfoot 
\customise slash=R  _element=tr
\customise little=! _element=th
\customise little   _element=td

<style>
.text-align-right, .tr {text-align: right;}
.text-align-center, .tc {text-align: center;}
.vertical-align-top, .vt {vertical-align: top;}
.vertical-align-bottom, .vb {vertical-align: bottom;}
</style>

»TABLE.class-table-2 
›CA CAPTION
›CO:1:8rem
›CO:2:6rem 
›HE /°R ﹙ Header Row﹚﹙.tc Col 2﹚﹙.tc Col 3﹚°/‹HE
›BO 
    /°R ﹙!.tr head﹚﹙ data﹚﹙ data﹚°/
    /°R ﹙!.tr.vt head﹚﹙ data
and more
  
data﹚
﹙ data 
  
and more
  
data
  
broken over lines...﹚°/
    /°R ﹙!.tr.vt head﹚﹙ data﹚﹙ data﹚°/
‹BO
›FO /°R ﹙ Footer row﹚﹙ Col 2﹚﹙ Col 3﹚°/‹FO
«TABLE

[AnthonyMuscio]

I like the use of CM for tables and other complex structures build in html but if one understand the rules of html tables why not use the native element names such as tr th td etc.. as your symbols?

Even just the automatic closure of such elements is enough to make a table much easier to read.

Tony

[pmario]

Tony, You are right. TT and I are still experimenting with CM table syntax. ... It should be "easy to read", "easy to remember" and "easy to type" ... Especially the "cell merging" and "text alignment" will be tricky. see some examples ... That's still experiments, that only cover parts of the real possibility of html tables.

[pmario]

But now we do have better "snippet handling" so users can define some predefined table layouts that they know. So they only have to "copy paste" some new columns and rows and add some text.

The advantage of CM here (I think) is, that it should be easier to be dynamically created. ... BUT that has to be proved ;)

[TiddlyTweeter]

I like the use of CM for tables and other complex structures build in html but if one understand the rules of html tables why not use the native element names such as tr th td etc.. as your symbols?

@AnthonyMuscio you are likely right!

The issue for me is that as I work with CM, which actually really fits my needs for fine-control over "IN Tiddler" design, there is a necessary evolution process to derive a consistent system for ID's and parameter and class names.

[TiddlyTweeter]

WikiText Blockquotes (overview)

Blockquotes in WikiText are very rich & flexible. They are almost as rich in behavior as WikiText tables. TW supports both multi-line <<< ... <<< and single-line >(+) blockquotes. The docs for <blockquote> insertion via WikiText are goodly documented at: Block Quotes in WikiText. In brief...

I'll comment later on an issue or two...

[TiddlyTweeter]

Example: <q> element, lang= attribute...

Here is another example (proof of concept) that uses the lang="[country code]" for the inline <q> element. The attribute changes the style of quote marks to match the language ...

\customize slash=Q _element="$macrocall" $name="addAttribs" _1=p1 _2=p2
\define addAttribs(p1,p2)<q $p1$>$p2$</q>

<style>q {font-size: 1.1em; font-style: italic;}</style>

As they say in English /°Q:lang="en":foot-in-the-mouth °/ is when you make a gaffe, a mistake, especially when talking. In German /°Q:lang="de":ins-Fettnäpfchen-treten °/ is similar, as is the Italian /°Q:lang="it":fare-una-gaffe °/.

Output...

[TiddlyTweeter]

Note On Example For Paramater Passing To Blockquotes

@pmario This example does not work with 0.9.0. It will start to work with 0.10.0
I did adjust the parser, so it's possible to pass on parameters, that contain spaces.
... It's an example, how to use _1 and _2 params.

\customize degree=blockquote _element="$macrocall" $name="test" _1="citeTxt" _2="url" _mode=block _endString="---"

\define test(src, citeTxt, url)
<blockquote cite="http://$url$">
**$src$**
<cite><a class="tc-tiddlylink-external" href="https://$url$" rel="noopener noreferrer" target="_blank">$citeTxt$</a></cite>
</blockquote>
\end

Very good example! Thanks! I now understand it! But I did not understand at first that $src$ is special! :-)
Basically it is the CONTENT between the opening and closing Glyphs? Right? It is captured by your parser, right?
It is hard-coded somewhere?

Anyway, I now can use parameter passing pretty well!

Q: @pmario BUT, in final docs, it may be worth explaining what $src$ does? Something like that.

[pmario]

Very good example! Thanks! I now understand it! But I did not understand at first that $src$ is special! :-)

Yea, The src parameter was the first one, that I did introduce.

Basically it is the CONTENT between the opening and closing Glyphs? Right?

Exactly! ... It was the easiest one to implement. Almost no additional code was needed. No config, no pragma settings. ..

It is captured by your parser, right?

yes

It is hard-coded somewhere?

yes. It will be always there, even if you don't need it ;)

[TiddlyTweeter]

TX! Great to know! And WORKS well!

It is hard-coded somewhere?

yes. It will be always there, even if you don't need it ;)

:-) I just think that in docs that should be mentioned. That is all!

[AnthonyMuscio]

TT,

Just reviewed this discussion thread now. You talk about including a <cite> parameter URL= in the wikitext markup for block quotes. This may make sense in a "custom markup free environment", but with custom markup could you swap this around?. Add block quote css to custom markup for the html cite element?

It seems to me we should embrace HTML and all its features and unleash them with custom markup, rather than add individual features to wikitext markup. One starts with many features from html where you select elements for custom wikitext, the other is custom wikitext to which you add additional features. The former approach is the most expansive in my view, html is universal and maintained for a much larger community; the latter wiki markup is smaller and maintained by a smaller community.

Your thoughts?

[pmario]

The cool thing after a pause using and developing CM is, that you can see, what's missing and which elements still have rough edges

[TiddlyTweeter]

Issues Arising - Just My Thoughts

(This is horribly OPINIONATED! :-)

As I work more with Custom Markup I realise, more and more, that the basic ideas behind it share a lot with Standard WikiText.
And it is making me aware that the potential of Standard WikiText is likely quite under-used. Why? I don't think there is general wide understanding of how to pass styles into WikiText constructs. Partly this is because there are several methods...

• Passing in class= attribute via .class appended to the WikiText construct
• Wrapping in class @@.class ... @@ via <span> (inline)
• Passing in class= attribute via @@.class ... @@ (some blocks)
• Passing in to the style= attribute @@property:value; ... @@

BUT there is an issue in that the way they behave is not fully consistent. They are context dependent.
But we LACK, I think, full enough docs to fully understand WHICH method to use where?

IMO, Custom Markup opens the way to fully use HTML & CSS in TW in an efficient way IF a writer needs to quickly customise content.
But it also IMPROVES users understanding of Standard WikiText!

QUESTION ...

@pmario Should the docs for Custom Markup ALSO explain Standard WikiText better too?

(P.S. My thinking here is you can ALSO use Custom Markup to QUICKLY prototype new CSS use. It could be used well as part of the development of new CSS for "Standard" use in TW??)

[pmario]

QUESTION ...

@pmario Should the docs for Custom Markup ALSO explain Standard WikiText better too?

(P.S. My thinking here is you can ALSO use Custom Markup to QUICKLY prototype new CSS use. It could be used well as part of the development of new CSS for "Standard" use in TW??)

I think, if something for the "standard" doc is needed to understand custom-markup, it should go to tiddlywiki.com standard docs. CM docs should only link there.

IMO This will help both projects.

[TiddlyTweeter]

@pmario there may be consistency problems that have to stay!
Because: Backwards compatibility is more important!!

Right! One of the biggest appreciations of TW I have is, basically, its serious commitment to backwards compatibility.

BUT the issue for an end user is that the various changes over time have led to some inconsistency that can start becoming a "barrier-to-entry" too?

On WikiText ORTHOGRAPHY for styling, in particular, the inconsistencies (simply on what you "enter") can be pretty confusing, I think?

[pmario]

BUT the issue for an end user is that the various changes over time have led to some inconsistency that can start becoming a "barrier-to-entry" too?

On WikiText ORTHOGRAPHY for styling, in particular, the inconsistencies (simply on what you "enter") can be pretty confusing, I think?

You are right. That's why we do have a "deprecated" mechanism. .. The problem is, that this mechanism isn't really used. ... If we deprecate something we would be able to move it into a plugin, after 1 or 2 years. ... BUT we actually never did that.

[TiddlyTweeter]

@pmario ... You are right. That's why we do have a "deprecated" mechanism. .. The problem is, that this mechanism isn't really used. ... If we deprecate something we would be able to move it into a plugin, after 1 or 2 years. ... BUT we actually never did that.

Ah! Okay. I just want to comment that in order to fully appreciate Custom Markup plugin I did need to better understand the "(semi-)deprecated" existing features of TW! :-)

[AnthonyMuscio]

Mario;

You say;

Eg: The standard wikitext "_endString" is hardcoded and always produces a paragraph. Now we can change this behaviour.

but does not the line wikitext like * # produce line feeds? as normal <li> elements do? ie the html rules?

Tones

[TiddlyTweeter]

Adding Custom Pragma That Compliment Standard WikiText? - No. 1

In Standard WikiText we have the constructs for...

• [via ``` ... ```] <pre><code> ... </code></pre> Docs: Code Blocks in WikiText
  and ...
• [via """ ... """] <p> ... <br> etc ...</p> Docs: Hard Linebreaks in WikiText

I thought it interesting to add ... Simple PRE ...

\customise tick="'''" _endString="'''´" _element=pre _classes="test-style"

´''' test

  enter `´'''` to start `<pre>` block

  enter `'''´` to end `</pre>` block

test
'''´

... render ...

<pre class="test-style wltc-l1 wltc">test

  enter <code>´'''</code> to start <code>&lt;/pre&gt;</code> block

  enter <code>'''´</code> to end <code>&lt;/pre&gt;</code> block

test
</pre>

[pmario]

uuuh. That's an interesting one. You really have to test it, to see, what's actually going on. cool!

[TiddlyTweeter]

It needs CSS-style cascade change for "pre > code" elements to display. Normal TW CSS pre > code render the same.

[TiddlyTweeter]

Adding Custom Pragma That Compliment Standard WikiText? - No. 2

This one adds a <pre> container to emulate a computer CONSOLE :-). Useful in documentation of Windows command prompt ... :-)

I will improve it by PASSING in ATTRIBUTES on style, so the user can change the width and positioning in text flow. Later!

\rules except dash
\customise angle=CONSOLE _endString="«CONSOLE" _element=pre style="max-width:31rem;height:100%;font-family:monospace;font-size:.8rem;line-height:1;color:yellow;font-weight:600;background-color:black;border:3px solid grey;padding:1rem;border-radius:.8rem;"

<style>.blink-console {background-color: white; color:transparent; animation:blinking 1.4s infinite;}
@keyframes blinking{0%{background-color: white;}47%{background-color: transparent;}}
</style>

»CONSOLE C:\Users\TT>

               Powershell 5.1.19041.610

             +===========================+
              FETCH TW - OWLET v01a
            +=============================+
            |    TW5 RELEASES             |
            |  D - Release: With Docs     |
            |  E - Release: Empty         |
            |  F - Release: Full Plugins  |
            |      ---------------------  |
            | PD - Prerelease: With Docs  |
            | PE - Prerelease: Empty      |
            |      ---------------------  |
            |  U - Upgrade Tool           |
            | --------------------------- |
            |    TW5 EDITIONS             |
            | E1 - CodeMirror             |
            | E2 - D3 Graphics            |
            | E3 - Highlights             |
            | E4 - KaTex                  |
            | E5 - Markdown               |
            | E6 - Resume Builder         |
            | E7 - Text Slicer            |
            | E8 - XLSX Utilities         |
            | --------------------------- |
            |    TWC RELEASES             |
            |  C - Release                |
            | --------------------------- |
            | H - Help                    |
            | --------------------------- |
            | X - Exit                    |
            +=============================+
              Internal Settings active
             +===========================+
?             key:/°.blink-console _°/

«CONSOLE

... outputs ...

[AnthonyMuscio]

Really cool

One of possibly hundreds of canned "custom wikitext" authors would like to have up their sleeves for producing rich content.

[TiddlyTweeter]

@AnthonyMuscio One of possibly hundreds of canned "custom wikitext" authors would like to have up their sleeves for producing rich content.

Right! I think it is quite a striking example, though it was actually easy to create and is easy to use. You can see the latest full version online at: Console Emulation Example: Parameter Passing

[TiddlyTweeter]

One thing that Custom Markup can ADD to Standard WikiText is DYNAMIC <a> attributes ...

What do I mean? Merely that the brilliant [[title of link|link]] method in Standard TW is not always flexible enough ... This illustrates a solution via being about to invoke a site in many ways (e.g. YOUR site :-) through CM ...

[TiddlyTweeter]

Easier Way to do a Modal???

I think Modals are underused? They are great for reference materials.

In experiments with Custom Markup I found it was easier (once you done the macro) to invoke a modal
... Here is an example, which could be improved, in time, by passing in attributes for styling.

The button for it ...

The code a user would enter is only ⠒HLP:"Custom Markup Defaults" $:/tt/cm/hlp_Custom Markup Defaults⠶

[pmario]

I was thinking about the wltc-lx classes. I think I can remove them from glyphs, that can't do indents. ... We'll see

[TiddlyTweeter]

I was thinking about the wltc-lx classes. I think I can remove them from glyphs, that can't do indents. ... We'll see

Thanks. TBH, classes that don't do anything are more of a maintenance headache than they are worth? I do think the indents wltc-l2 and up may well be used by some users wanting an easy solution to indenting so maybe worth keeping?

My 2 cents.

[TiddlyTweeter]

I personally hate dropdowns and modals. I think they waste screen space, and animated modals waste time too.

... If there is a different way to show additional content without them I prefer the alternative way.

But I'm open to learn new ways to use them. ...

Interesting! I broadly agree with you. Overuse of them is just a mess. BUT Pop-up or Modal simple help info I, myself, find useful for quick reference.

[AnthonyMuscio]

Question?

Is there scope and end options for "Special Block Defaults"?

Tony

[TiddlyTweeter]

In my tests I don't think you can redefine the behavior of "Special Block Defaults" (e.g. »»» ) except through style sheets.

As far as I can see @pmario intended them as hard-coded support for common needs for indenting, and provides classes to define what they do.

TT

[TiddlyTweeter]

Comment On Custom Markup & Standard Markup CSS Application

I have been looking at the numerous ways TW permits CSS styling. I was pleasantly surprised to see Custom Markup also supports the @@style:value; @@ wrap method both for inline and blocks. For instance ...

@@background-color: red;
°.a-style.another BLOCK TEST
@@

Inline @@background-color:red;『.a-style.another TEST』@@ of styling.

... producing ...

... with HTML ...

<div class="a-style another wltc-l1 wltc" style="background-color: red;">BLOCK TEST</div>
<p>Inline <span class="tc-inline-style" style="background-color:red;"><span class="a-style another wltc-inline wltc">TEST</span></span> of styling.</p>

Its handy for rare situations? Q: Is it mentioned in Docs?

[AnthonyMuscio]

TT,

Inline @@background-color:red; TEST@@ of styling.

works, what is 『.a-style.another TEXT』 doing?

Tony

[pmario]

『.a-style.another TEXT』 It assigns 2 classes: class="a-style another" to the SPAN element. ... The html element that is used depends on the custom pragma.

It's the same mechanism as:

*.test asdf

that is part of TW already. This mechanism works for custom block and custom inline definitions