Skip to content

Support multi-line component props? #299

Description

@xMrAfonso

PS: I did message Sebastien on X, but I thought this would be a better place to ask this. It's not necessarily a feature request, it's rather a question on why it's not a thing.

Currently, component attributes seem limited to a single line:

::component{foo="bar" hello="world"}
::

Could comark support multi-line attributes like this?

::component{
  foo="bar"
  hello="world"
}
::

I know YAML props exist, but several users find that syntax verbose and overall unpleasant to work with. Additionally, would love to know more on the reasons why this isn't already a thing, or what the limitations are.

It would be nice to also maybe have an props attribute which I can insert yaml directly. For instance:

::component{ props="|
  foo: "bar"
  hello: "world"
"}
::

Activity

  1. farnabaz commented on Jul 29, 2026

    @farnabaz
    Collaborator

    For multi-line props you can use Block Attributes style.

    ::component  
    ```yaml [props]  
    foo: "bar"  
    hello: "world"  
    ```  
    ::  
    
  2. xMrAfonso commented on Jul 29, 2026

    @xMrAfonso
    Author

    Yes, I amaware of that but I specifically asked why this specific multi-line is not supported and that users dislike the way you just described. @farnabaz

  3. farnabaz commented on Aug 10, 2026

    @farnabaz
    Collaborator

    @xMrAfonso I see. There isn't one specific reason—there are multiple considerations behind how we chose and shaped the syntax this way. I'll name two important ones and explain how they influenced this specific feature.

    Readability

    We didn't want to negatively affect Markdown readability. One of the core principles of Markdown is that the source itself should remain readable.

    When designing the component syntax, we were careful not to create visual mess inside Markdown files. That's why we initially only supported block-level plugins. The logic is roughly this: if you see :: at the beginning of a line, you know it's a component and may not need to read its contents unless you care about the rendered version.

    ::component{...anything}
    
    Some paragraphs and content
    
    ::

    This simple rule prevents readers from having to scan those lines for meaningful content. Attributes, most of the time, aren't useful information for someone reading the raw Markdown—the paragraphs and text are the actual content.

    The multiline syntax was introduced later. To minimize its impact on readability, we chose the already familiar YAML/code-block syntax. Markdown readers are used to recognizing and navigating this kind of syntax, so it causes less disruption.

    Markdown renderers

    Another important consideration is how the syntax will appear in existing Markdown renderers such as GitHub.

    1

    ::component{ props="|
    foo: "bar"
    hello: "world"
    "}
    ::

    2

    ::component{
    foo="bar"
    hello="world"
    }
    ::

    3

    ::component

    foo: "bar"
    hello: "world"

    ::

    Personally, I think the third option is easier to understand when rendered by a Markdown renderer that doesn't support the component syntax.


    All that aside, the component syntax is optional in Comark. We enable it by default, but you can disable it, clone it, create a new plugin, test it with different readers and writers, and, if you like it publish it for the community. 🙂

  4. atinux commented on Aug 13, 2026

    @atinux
    Contributor

    I created a browser web extension (pending approval on official Chrome & Firefox stores), hope this would help 😊

    https://github.com/comarkdown/comark-webext

  5. xMrAfonso commented on Aug 13, 2026

    @xMrAfonso
    Author

    I created a browser web extension (pending approval on official Chrome & Firefox stores), hope this would help 😊

    https://github.com/comarkdown/comark-webext

    Hey, looks very interesting indeed. Will check it out!

    Only reason for this issue was mainly checking if there was no other way of doing multi line/structured props without using the code blocks. I guess it isn't.

  6. farnabaz commented on Sep 24, 2026

    @farnabaz
    Collaborator

    Thanks for suggestion, however there is no plan to support other syntax for attributes yet.
    I'm closing this, feel free to drop another one if anything else need to be considered. 🙏

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions