Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Preserve bullet used for lists (-, * or +) #3478

Closed
max-nextcloud opened this issue Nov 23, 2022 · 5 comments · Fixed by #3523
Closed

Preserve bullet used for lists (-, * or +) #3478

max-nextcloud opened this issue Nov 23, 2022 · 5 comments · Fixed by #3523
Labels
bug Something isn't working feature: formatting Features related to text formatting and node types format: markdown good first issue Good for newcomers Nice to have

Comments

@max-nextcloud
Copy link
Collaborator

Describe the bug
There are different bullets chars that can be used to write lists in markdown. Preserve them when editing the file in text.

To Reproduce

  1. Create a file containing a list using - chars as bullets.
  2. Open the file in text.
  3. Change and save the file.
  4. Inspect the file. All bullets turned into *.

Expected behavior
Preserve the type of bullet used.

@max-nextcloud max-nextcloud added bug Something isn't working good first issue Good for newcomers feature: formatting Features related to text formatting and node types format: markdown Nice to have labels Nov 23, 2022
@max-nextcloud
Copy link
Collaborator Author

max-nextcloud commented Nov 23, 2022

Text reads the markdown source and turns it into data structures for the tiptap editor.
When saving the file it serializes these data structures into markdown again.

In order to preserve properties of the initial markdown they need to be handled in each of the steps involved:

  1. Parsing with markdown-it (md -> html)
  2. Loading with tiptap (html -> tiptap nodes and marks)
  3. Processing done by tiptap / prosemirror
  4. Serializing with prosemirror-markdown (tiptap nodes -> md)

We already loose the information what bullet was used in 1.
You can try this on the demo site of markdown-it:
No matter which bullet you pick the html code always looks the same.
But the internal representation keeps track of the bullet in markdown:

debug view on demo site
[
  {
    "type": "bullet_list_open",
    "tag": "ul",
    "attrs": null,
    "map": [
      0,
      2
    ],
    "nesting": 1,
    "level": 0,
    "children": null,
    "content": "",
    "markup": "-", // <--- here.
    "info": "",
    "meta": null,
    "block": true,
    "hidden": false
  },
]

So what it would take would be turning this markup property of the token into an html attribute such as in <ul data-bullet='+'>.
We are already doing something similar for the underlined text.

In 2. we'd than have to convert this into an attr on the tiptap list node. Tiptap and prosemirror should leave this alone in 3. and 4. would be handled by prosemirror-markdown if the bullet was stored in the bullet attribute of the ul node.

@susnux
Copy link
Contributor

susnux commented Nov 23, 2022

Keep in mind that all list items should use the same bullet, e.g. new created items should use the bullet of the previous item. The same is valid for TODO lists.

@max-nextcloud
Copy link
Collaborator Author

@jancborchardt pointed out in the design review:

We can use style="list-style-type:'-';" with a string value in the HTML: https://developer.mozilla.org/en-US/docs/Web/CSS/list-style-type

@juliusknorr
Copy link
Member

But in the rendering we actually want a unified look, right?

@max-nextcloud
Copy link
Collaborator Author

Frankly... i don't know. I'd be fine with both. Having different bullets might be confusing because there is no way of creating them (thus far) and to me it seems unnecessarily complex. Otoh if the rendered output closer matches the source might be nice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working feature: formatting Features related to text formatting and node types format: markdown good first issue Good for newcomers Nice to have
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants