Stylo: a stylable macOS CommonMark Editor

Application
1

I released lately a new Markdown editor called Stylo. It is CommonMark compliant (0.28 version is supported for now) and based on a custom Markdown parser and text rendering engine. It adds the GitHub flavored table and strikethrough for practical purpose and will add some more extensions in future releases.

The first version main focus was to implement a rendering engine capable of using CSS style definition to style Markdown source. To achieve this, a DOM for the Markdown source itself was needed in order to use it in the CSS cascading engine. Part of this work included adding Markdown specific DOM elements that didn’t have any corresponding HTML elements and defining new pseudo elements to allow styling parts of elements specifically relevant for Markdown source. For example, the new tag pseudo element has been made available to style the #'s in headers definitions:


h1::tag {
    color: red;
}

All documentation is publicly available at https://www.textually.net/stylo/documentation/markdown/, if you are interested.

I have put the Markdown specific DOM under the namespace https://commonmark.org. Maybe these things should be standardized in some way in CommonMark; this is an open discussion…

The App also includes HTML preview, multiple export formats, etc… If you’d like to try it, you can download it at https://www.textually.net.

My sincere gratitude to this community and all the people I have interacted with. I have big plans for Stylo and I hope you’ll enjoy it. Also, please, feel free to leave any positive/negative comment or feedback here or on the contact page.

2 Likes
2

You might want to offer users to style open tag and close tag differently. The latter is optional in # headings. GFM table rows arguably also have separator tags, and alignment colons or the entire header line might deserve separate selectors. I can also imagine a desire to style the digits of numbered lists differently from the period, likewise the exclamation mark in image links.

While Commonmark does not specify a detailed syntax for the info strings in fenced blocks, it would be useful to style keys (including shortened ones like the dot in .class) and values separately.

Whitespace used as markup and indentation could be useful to select as well, e. g. to distinguish tabs and spaces or to show width indicators.

3

Have you seen commonmark-spec/CommonMark.dtd at master · commonmark/commonmark-spec · GitHub

1 Like
4

I’d encourage you to add a link to this at

1 Like
5

Thanks for the suggestions! You definitely have interesting points.

You mention the different styling of open tag and close tag and it is in fact implemented but not available to CSS… I disabled the feature because I didn’t see the use case but since your pointing it out I will revisit this in a coming versions and may well unlock it.

For the table, I had also something but decided to back up and wait for a next release after the stabilisation of the essentials. But, for complete “stylability” I should support these kinds of pseudo elements… The same goes for all your other suggestions actually. Thanks for pointing them all out! I will soon include a release notes page on the website to actually let users track the new features.

6

Yes, I’ll do. Thanks!

7

I didn’t see this… thank you for the reference!

Now, this has some implications… and it raises some questions, specifically of usability in my case. In fact, in Stylo, I kept the same element names as HTML under a different namespace. The reason was to lower the cognitive load, basically make it simpler for someone who knows HTML to just style Markdown… This would complicate things if inline HTML and HTML blocks would become visible to CSS (which they are not right now, the same as for CommonMark DTD, it is an opaque html-block). At this point, namespaces would need to be used to distinguish (if distinction is needed) between let’s say HTML Hx and Markdown heading.

I can see that the DTD also removes the “instrumental” element(s) like references, which in my case I need. Would it be thinkable to bring the reference element in the DTD at this point? What is the status of this DTD?

This is something that will require a bit of work to conform to, but quite straightforward in fact. I need to take a bit of time to think about it before committing to anything but this is an important point to address.

8

@jgm Did you see this PR?

@Nebula You should also consider adding Stylo to Babelmark:

9

Christoph Päper via CommonMark Discussion
noreply@talk.commonmark.org writes:

@jgm Did you see this PR?

I have seen it, but haven’t had a chance to think it
through yet, thanks.

1 Like
10

About this PR, since we are opening the DTD specification… I thought about it and I think I will support both formats (CommonMark DTD and easier HTML based DTD). It means that the CommonMark DTD will be user facing… I was wondering if it would not be possible to use more “user friendly” element names? I mean removing all more “programmer specific” kind of characters like underscores, etc… Basically the elements names:

  1. code_block
  2. thematic_break
  3. html_block
  4. custom_block
  5. html_inline
  6. custom_inline

Would all change to their “single word” variation:

  1. codeblock
  2. thematicbreak
  3. htmlblock
  4. customblock
  5. htmlinline
  6. custominline

I would go even further as to follow even closer the HTML spec:

  1. codeblock
  2. thematicbr
  3. htmlblock
  4. block
  5. htmlinline
  6. inline

In the last version I removed the words “custom” as I think it is clear they are custom if they are not specified; and I replaced “break” with “br”.

Of course, this is all open to discussions but the spirit is to make the CommonMark DTD names more “user friendly”…

@Crissov Noted! Yes this is something I will do eventually soon.