No doubt, we need infoboxes in our life.

An infobox is a special box located to the right of the content (usually) containing some important information. Wikipedia and other MediaWiki wikis use them heavily.

On Mycorrhiza, infoboxes (or infoboces? hehe) shall:

• Support titles
• Support subtitles
• Support images/videos/audios
• Support key-value entries
• Support prev-next-like entries (no idea how to explain that)

I propose this syntax:

infobox {
  <content>
}

The does not support all of Mycomarkup, only a part of it, i/e no transclusion, no other infoboces, no tables.

Supported subset of Mycomarkup in infoboces:

# Infobox title
## Section
### Subsection
img { ... }
Hypothetical: video { ... }, audio { ... }
Hypothetical: collapse { ... }, spoiler { ... }
Paragraph

Additional syntax:

! key | value (paragraph)
| column 1 (paragraph) | column 2 (para) | column 3 (para)

An example infobox:

infobox {
# Red gurnard
img { red gurnard }
## Scientific classification
! Kingdom: | Animalia
! Phylum: | Chordata
! Class: | Actinopterygii
! Order: | Scorpaeniformes
! Family: | Triglidae
! Genus: | Chelidonichthys
! Species: | C. cuculus
}

Another one:

infobox {
# Chapter 13
img { cool cat }
## Chapter information
! Release date | 2021-02-30
## Chapter navigation
| < [[chapter 12]] | [[chapter 14]] >
}

Something like that.

Mycomarkup comes with no CSS! Basically, if anyone wants to use Mycomarkup in their project, they will have to reimplement all of styles. Mycorrhiza does that, for example.

There should be a standard stylesheet packed with Mycomarkup. It will do basic layout things such as putting img end { to the end of line, etc. No font size, no extra colors, etc.

It may not be obvious at first, but headings in Mycomarkup are broken. Until Mycorrhiza conquers the world, we have possibility to change this fundamental block without too much trouble.

What is wrong?

1. Heading level 1. They are not recommended for use in Mycorrhiza. You should only use it when using stand-alone Mycomarkup, and even then you don't really need too. So, why do we have it?
2. Actual top-level heading in text is level 2. It makes sense, because there is a h1 already: the hypha's title. But many users don't know that (take a look at Klavawiki, for example) and use heading level 1. Well, can't blame them for that.
   • To somehow aid users in the right direction, the toolbar doesn't have level 1 headings. And this is ridiculous, to be honest.
3. Some heading levels were never used. I have never seen anyone use level 5 and level 6. Well, except for Pescenomicon that used them for CSS hacks, not as headings.
4. Bold plays the role of a heading sometimes. Like in this list. It's not bad in any way, but it just makes it impossible to include such headings in TOCs. Well, we may not have TOCs now, but we certainly will in the future.
5. That stupid octothorp #. We use it because Gemtext uses it. Gemtext uses it because Markdown uses it. Mycomarkup doesn't really care about compatibility with them, to be honest.
   • Writing this character is a fun little activity on the standard Russian keyboard layout йцукен. Sometimes I remember most Mycorrhiza users I know speak and write Russian.

A solution

Here it is:

= heading level 1 (h2)
== heading level 2 (h3)
=== heading level 3 (h4)
==== heading level 4 (h5)

Use the equality sign for headings. Why?

• It is the classic choice, used by most lightweight markups (not Markdown though): MediaWiki, MoinMoin, Creole, etc.
• It's available on йцукен and is easier to reach than # on qwerty.
• Such syntax leaves the hash sign vacant. What can we do with it? Hashtags.

Also, lack of h1 solves the problem of the block being discouraged. Did you know that MediaWiki discourages it too?:

Skip Level 1, it is page name level.

Here's another thing. Heading levels 3 and 4 flow into the next paragraph, if there is no empty line between them. Thus, level 3 and 4 are inline elements.

Approximately, this:

=== over

the rainbow

=== over
the rainbow

Becomes this:

<h4>over</h4>
<p>the rainbow</p>

<p><h4>over</h4> the rainbow</p>

The HTML validator does not say this is bad.

Nevertheless, all headings are block elements by default in the web browsers. So, in a CSS-less environment they would display on a separate line. All right, not a big problem. Alternatively, we can inject a little style="display:inline" here and there.

So, that's it.

This is highly controversial, so please discuss.

How am I supposed to style my wiki now?!

Now, that's your image gallery:

img {
image 1
image 2
}

They are shown one below another. This is not enough.

From the very start I planned to have a way to specify the gallery's layout here:

img <layout> {
image 1
image 2
}

Some possible layouts:

• Content arrangement:
  • default
  • grid
  • horizontal
  • carousel (why?)
  • text-to-the-right
  • tile
• Gallery placement:
  • stretch
  • right
  • left

You can combine them like grid right (similar to transclusion selectors).

Did you know that table cells support all of Mycomarkup? You can even include a table in a table cells, which is not good.

When we transclude the description from a hypha that does not have the description, nothing is shown.

We should show something I guess?

I had this idea for a long time.

A note block is a little box with some text. It may be a reminder, a disclaimer, a warning, or whatever.

Many MediaWiki wikis have them implemented with templates and hacks. Well, it's considered idiomatic there.

Yandex Flavored Markdown, yet another dialect of Markdown (which has 4 levels of headings too, by the way), introduces such note blocks. Yandex's idea is similar to mine. That's great.

So, the syntax I purpose is as follows:

note <type> {
   <body>
}

Where:

• <type> is an optional value. Possible values:

  • important for text that is so important everyone must read it.
  • tip for slightly related notes that may help readers.
  • warning for warnings. A good choice for marking sections deprecated.

  Default: tip.

• <body> is a Mycomarkup-formatted text.

Each type has its own colors and icons. Every aspect of it is granularly configurable with CSS.

See also this heavily-related Mycorrhiza issue.

Current rocket links syntax is bad because of how different it is from all other Mycomarkup blocks. You can't have a hypha link with spaces, you have to replace the spaces with underscores. Also, the link text comes after a first space, not after |, like in inline links.

I propose this new syntax:

=> addr
=> addr with spaces
=> addr | text
=> addr with spaces | text

It is not compatible with the current syntax. Moreover, we can't have them both at the same time (like with headings) because the => is not going anywhere.

To somehow address it I propose this temporary syntax:

=> addr
=> addr_with_spaces
=> addr text
=> addr | text
=> addr with spaces | text

Basically, if there is | in the rocket, the new logic is used. Otherwise, the old one is used. This is generally backward-compatible (haven't seen | being used in display text!) and lets people use the new syntax already.

Then a forced migration will happen. I think it should happen at the same time as the forced migration to the new heading syntax.

We need a column block

See #3 for one syntax proposal:

columns {
  column {
    ## Volume 1
    🐟
  }
  column {
    ## Volume 2
    🐠
  }
  column {
    ## Volume 3
    🐡
  }
}

Another way:

columns {
  {
    ## Volume 1
    🐟
  }
  {
    ## Volume 2
    🐠
  }
  {
    ## Volume 3
    🐡
  }
}

Question:

• What about column sizes? Should we be able to set their proportions? Like, the first column is 2fr, the second one is 1fr, like in CSS

Wikis encourage communication, right? They do not. Not Mycorrhiza, at least.

A way to solve it is the Message block. I actually had ideas about it for like a year.

Message block should have this:

• Content (Mycomarkup, might be empty)
• Link to author (might be empty)
• Timestamp (might be empty)

Well, we can actually live without timestamps. If you really need them, write them in the content part.

So, content and author. This syntax is reasonable:

msg {
  No author
}

msg bouncepaw {
  An author is specified. When rendered, [[u/bouncepaw]] is linked there.
}

They can be nested, encouraging branching discussion:

msg A { I hate the AC.
  msg B { Why? This is stupid!!
}}

msg B {
   Hello world! Did you know there are many benefits to loving the AC?

   msg C {
      No, I wouldn't have thought! Tell us more please
   }
}

Message blocks should look like chat bubbles 💬 I am still unsure how to determine what messages go to the left and what messages go to the right.

Now, you can specify an image's size in pixels:

img { pear | 300 }
img { pear | 200*500 }

From the very start I did not like it, because, well, for some reason.

One day I would love to see size specifiers like that:

• Horizontal
  • narrow
  • normal-width
  • wide
• Vertical
  • short
  • normal-height
  • tall
• Shape
  • square
  • normal-shape

The normal--prefixed specifiers are meant to be default.

Each image would get CSS classes that correspond to the size specifiers. Admins would redefine these specifiers easily.

There's an idea to add a tag for video embedding. It would look similar to img, like this:

• From hypha: video { ../kittens | 100 { Are smol } }
• From external link: video { https://www.learningcontainer.com/wp-content/uploads/2020/05/sample-mp4-file.mp4 {Big Buck Bunny} }
• From a streaming site (seems not possible easily, would require additional support) video { https://www.youtube.com/watch?v=Nq-q2USYetQ }

Look, GFM has got footnotes!

We actually have an idea of that, too. Let's implement it in similar fashion.

I like apples[[^about-apple]]. Let's bake charlotte pie[[^1]]!

notes {
  about-apple | { They are tasty.
But you need to be aware of worms. }
  1 | https://tasty-pies.org/charlotte.html
}

Notes:

• I've replaced & to ^, like in most of Markdown dialects.
• Also I've replaced links to notes to not mistake the idea with 'link aliases'. Possible alternatives are 'foot', 'footnotes', 'footer' etc.

Design

Technically, it should be a two-pass process (scan for links, enumerate, and only then render both links and anchors). But we can force top-to-bottom declaration syntax and link-based enumeration. And also allow duplicate links (however, we would also need to implement anchor joining then).

Also, it is possible to implement this with a visitor, which would collect notes blocks, enumerate and replace footnote links with anchors (like, name="footnote-1" href="#footer-about-apple") on-the-fly, and then we would use it to render a separate footnotes section. But seemingly inline mycolinks can't have names (thus, anchors to them), so we'd have to add them for return links.

Full Mycomarkup support in footnotes is seemingly possible, but I'd be careful with transclusions. Links and the section design is also a discussion point.

All further issues are to be discussed on SourceHut

=> https://todo.sr.ht/~bouncepaw/mycomarkup

We sure need a spec for Mycomarkup.

The spec will be important for:

• Standardisation. Projects like Vera's Python parser will benefit from this.
• Formalisation. Everyone will benefit from this.
• Gaslighting people into the fungal ways.
• Explaining the design decisions.

And it will probably be fun to make.

The spec shall define a language usable not only in Mycorrhiza, as Mycomarkup is now. Sure, the library lets you transform Mycomarkup to HTML from the shell, but look at how links and images work and you'll come across radical mycocentrism there.

Some things to address when appropriating Mycomarkup for general usage:

• Link rules
• Error messages

Also, the spec should define the language HTML-agnostic. Sure, there will be sections explaining how Mycomarkup can/should be transformed into HTML, but they are not crucial for defining the language.

While writing the spec, we will definitely find some things that we have never really thought of. We might leave them undefined and come back to them in later versions.

The writing will take place on mycorrhiza.wiki, somewhere. There will be many hyphae, and one big epic hypha collecting them all together using transclusion.

As of versioning, we won't have versions per se until the pre-1.0 era comes. When it comes, we'll see what's next.

Interwiki implementation is going quite well, except it's making the already complex code more complex. Well, whatever.

Migrate to links.Link interface from links.LegacyLink. Progress:

• Rocket links
• Image galleries
• Transclusion (show error)
• Inline links

Images form 3-party server can track hypha guests. We should allow to disable images from 3-party server.