WIP(markdown/ext): use html style for columns

[gfanton]

From recent internal discussions, this PR replaces the current markdown columns extension syntax with HTML-style syntax.

This PR is almost done; it requires some cleanup and a few more tests.
I am waiting for a pre-review for syntax validation before continuing.

[Gno2D2]

🛠 PR Checks Summary

🔴 Changes related to gnoweb must be reviewed by its codeowners
🔴 Must not contain the "don't merge" label

Manual Checks (for Reviewers):

• IGNORE the bot requirements for this PR (force green CI check)

Read More

🤖 This bot helps streamline PR reviews by verifying automated checks and providing guidance for contributors and reviewers.

✅ Automated Checks (for Contributors):

🟢 Maintainers must be able to edit this pull request (more info)
🔴 Changes related to gnoweb must be reviewed by its codeowners
🔴 Must not contain the "don't merge" label

☑️ Contributor Actions:

1. Fix any issues flagged by automated checks.
2. Follow the Contributor Checklist to ensure your PR is ready for review.
   • Add new tests, or document why they are unnecessary.
   • Provide clear examples/screenshots, if necessary.
   • Update documentation, if required.
   • Ensure no breaking changes, or include BREAKING CHANGE notes.
   • Link related issues/PRs, where applicable.

☑️ Reviewer Actions:

1. Complete manual checks for the PR, including the guidelines and additional checks if applicable.

📚 Resources:

• Report a bug with the bot.
• View the bot’s configuration file.

Debug

Automated Checks

Maintainers must be able to edit this pull request (more info)

If

🟢 Condition met
└── 🟢 And
    ├── 🟢 The base branch matches this pattern: ^master$
    └── 🟢 The pull request was created from a fork (head branch repo: gfanton/gno)

Then

🟢 Requirement satisfied
└── 🟢 Maintainer can modify this pull request

Changes related to gnoweb must be reviewed by its codeowners

If

🟢 Condition met
└── 🟢 And
    ├── 🟢 The base branch matches this pattern: ^master$
    └── 🟢 A changed file matches this pattern: ^gno.land/pkg/gnoweb/ (filename: gno.land/pkg/gnoweb/markdown/ext_columns.go)

Then

🔴 Requirement not satisfied
└── 🔴 Or
    ├── 🔴 This user reviewed pull request: alexiscolin
    └── 🔴 This user reviewed pull request: gfanton

Must not contain the "don't merge" label

If

🟢 Condition met
└── 🟢 A label matches this pattern: don't merge (label: don't merge)

Then

🔴 Requirement not satisfied
└── 🔴 On no pull request

Manual Checks

**IGNORE** the bot requirements for this PR (force green CI check)

If

🟢 Condition met
└── 🟢 On every pull request

Can be checked by

• Any user with comment edit permission

[codecov]

Codecov Report

Attention: Patch coverage is 94.44444% with 6 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
gno.land/pkg/gnoweb/markdown/ext_columns.go	94.56%	4 Missing and 1 partial ⚠️
gno.land/pkg/gnoweb/markdown/utils.go	93.75%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!

[gfanton]

While this syntax is acceptable, it only makes sense if we support nested columns or per-column customization. However, I believe we should not support nested columns, at least not in gnoweb, as they can make Markdown syntax difficult to read in certain situations:

If we start implementing other components similar to this one and embedding them together, we risk creating something that is hard to read. By trying to balance HTML flexibility and Markdown readability, we may end up with a solution that is neither flexible nor readable.

To me, the best solution or compromise would be to have only one separator like this, with no nested columns.
Separator syntax is not really important as long as it doesn't use basic markdown syntax; it can even be an HTML tag.

<gno-columns>
## Title 1

content 1

|||

## Title 2

content 2

</gno-columns>

This syntax is readable and simple; there is no ambiguity about what constitutes a column. While it is less flexible, it should be sufficient in gnoweb context to support most use cases given the space available in the gnoweb interface.

[aeddi]

Personally, I completely agree with your second proposal. It seems to me that the philosophy behind the Render and Gnoweb duo is to have a compromise between a "raw-text first" format that can be displayed cleanly in the browser.

With this in mind, I think that using only a separator to define a new column would be cleaner than using a sub-pair of HTML tags. This would reduce the number of tags, reduce the number of corner cases on the parsing side and make the raw markdown more readable without being less explicit.

The only tradeoff of this solution is that we could only have one level of column, but I have the feeling that this will be sufficient for 99% of the users. So, maybe it is better to choose to have a more readable raw markdown every time we encounter a block using columns (which will happen very often I guess) than to make it difficult to read to add a feature that will probably almost never be used.

I'm just nitpicking on one point: I would prefer to use a tag like <gno-columns-sep/> rather than using ||| because it's more explicit and someone who never read the documentation would intuitively understand what it is when reading the markdown.

<gno-columns>
## Title 1
content 1
|||
## Title 2
content 2
</gno-columns>

<gno-columns>
## Title 1
content 1
<gno-columns-sep/>
## Title 2
content 2
</gno-columns>

[alexiscolin]

I agree that the code could end up being very hard to read. Additionally, from a UI perspective, we’re quite limited in terms of available space within the Markdown renderer (around 990px), which makes creating and using scoped columns rather constrained. This could become a really nice feature with a wider wrapper (something we might have later) but for now, it would likely result in very narrow nested columns (or none at all if we apply some CSS min-width safeguards), which limits the usefulness of scoped columns at this stage.