HTML Comments Break When Containing a Period (.)

[thorge]

HTML comments in LiaScript behave inconsistently. When a period (.) is included in the comment, the rendering breaks.

Steps to Reproduce:

See this snapshot for reproduction.

1. Create a LiaScript document with the following HTML comments:

   <!--
   Working
   -->
   
   <!--
   Not working.
   -->

2. Observe the rendering behavior:

   • The first comment displays correctly.
   • The second comment causes issues due to the period (.).

Expected Behavior:
Both comments should render correctly, regardless of the presence of a period.

Actual Behavior:
Comments containing a period (.) are not rendered properly.

Environment:

• LiaScript-Preview: v1.0.74

@RDM4CAU

[RDM4CAU]

I have tried various special characters - all special characters except for colon, minus and underscore lead to the problem described.

[andre-dietrich]

The problem here is, that HTML comments have a semantic meaning in LiaScript, they are used for adding meta information, define macros or for styling and configuration purposes, here is an example:

<!--
author: My name

import: https://raw.githubusercontent.com/liaTemplates/ABCjs/main/README.md
-->

# Comments

Due to the import of the ABCjs template, we can now render the ABC-notation (thanks to "@author").


``` abc  @ABCJS.render
X: 1
T: Shche ne Vmerla Ukrayiny ni Slava, ni volya
T: Ukrainian National Anthem
C: trad.
R: march
S: https://www.8notes.com/scores/34640.asp
Z: 2022 John Chambers <jc:trillian.mit.edu>
M: C
L: 1/8
K: F
[|\
"F"[A3F3][AF] ([AF][GE][AF])[BG] | [c3A3][BG] "A7"[A2F2][G2E2^C2] | "Dm"[F2D2][A2F2] "A"[E2^C2][A2C2] | "Dm"[D3D3][E^C] [F2D2]"C"[G2E2] |
"F"[A3F3][AF] ([AF][GE][AF])[BG] | [c3A3][BG] "A7"[A2F2][G2E2^C2] | "Dm"[F2D2][A2F2] "A"[E2^C2][A2C2] | "Dm"[D4D4] D2z2 |
"A"[E2^C2][E2C2] ([AC][GE][FD])[EC] | ("Dm"[DD3-]EF)[DD] "A"[E2^C2][E2C2] | "Dm"[F2D2][F2D2] "C"[G2E2][G2E2] | "F"[A4F4] [A2F2]z2 |
"A"[E2^C2][E2C2] ([AC][GE][FD])[EC] | ("Dm"[DD3-]EF)[DD] "A"[E2^C2][E2C2] | "Dm"[F2D2][A2F2] "A"[E2^C2][A2C2] | "Dm"[D3D3][E^C] ([FD][GE][AF])[BG] |
|:\
"F"[c3A3][=B^G] [c2A2][A2F2] | "C"[G2E2][G2E2] ([cE][BG]"^A7/C#"[AF])[GE] | "Dm"[F2D2][F2D2] "C"[G2E2][G2C2] | ("F"[A3F3][GE][A2F2])"C7"[B2G2] |
"F"[c3A3][=B^G] [c2A2][A2F2] | "C"[G2E2][G2E2] ([cE][BG]"^A7/C#"[AF])[GE] | "Dm"[F2D2][A2F2] "A"[E2^C2][A2C2] | "Dm"[D4D4] [D2D2]z2 :|
```

## Styling

<!-- style="border: 1rem solid blue" -->
A comment before an Markdown block is used to add additional attributes directly to that block or to add configuration settings, like for tables or quizzes.

But<!-- style="font-size: xxx-large" --> adding it to the end will only affect a single element.

## Commenting
<!--
@author: other person

@mycomment: This can be a string of arbitrary length.

@mycomments
Or if you do not add the colons, but instead add an end-macro

you can alsow write multiple lines of comments
@end
-->

The only way to attach a comment is per slide, by directly attaching it directly to the header. This way you can define new or overwrite existing macros, such as who ist the @author?

But you can also add more comments for yourself, simply by giving them arbitrary names that you do not call in your document...

You can also directly try this out here in the LiveEditor

... or, I forgot to mention, hiddent Text-to-Speech output can also be added within a comment.

---

One problem why stand alone comments are not perfectly rendered at the moment is, that adding a simple paragraph with text will be parsed by the HTML parser as a valid set of HTML-attributes. Maybe we can integrate a special notaion with 3 dashes

<!--- --->

or with another marker to add ignorable comments or we can somehow correctly parse <!-- toggle-id without style --> as no real parameter set. The problem is, that HTML-attributes can be defined also without equal sign or " ...

Any suggestions are welcome ;-)

[thorge]

Thank you for elaborating on this, this clarifies the current behavior. I forgot about the many features that share the same notation.

I think that the overlap of HTML comments for macros, styles, and configurations does have its advantages, since these remain invisible in standard Markdown viewers.

To address the issue without introducing breaking changes, adopting a triple-dash (<!--- ... --->) notation for "true" comments feels like a practical and elegant solution. This would clearly differentiate between functional and plain comments intended solely for documentation or annotations. Existing documents should remain unaffected.