rich-markdown-editor icon indicating copy to clipboard operation
rich-markdown-editor copied to clipboard

`headingsOffset` should affect written markdown

Open dave-db opened this issue 4 years ago • 4 comments

10.0.0-14 again

According to the docs:

headingsOffset A number that will offset the document headings by a number of levels. For example, if you already nest the editor under a main h1 title you might want the user to only be able to create h2 headings and below, in this case you would set the prop to 1.

I have that use case - all docs have an h1 set by their front matter, and the topmost heading for page content would be h2. When setting headingsOffset to 1 as suggested, I don't see the behaviour I was expecting.

Expected (with offset 1):

  • adding "big heading" sets an h2 in markdown
  • adding "medium heading" sets an h3 in markdown
  • adding "small heading" sets an h4 in markdown

Actual (with offset 1)

  • adding a "big heading" lists itself as an h2 in the editor (down the left), but sets an h1 in markdown
  • likewise, medium and small headings are listed as h3 and h4 respectively in the block menu, but in markdown are still h2 and h3

Have I misunderstood how the prop is supposed to work?

dave-db avatar May 11 '20 14:05 dave-db

The way it works right now it's only a display setting. But this was mostly because of technical restrictions in v9, in v10 it would be very easy to have the offset also affect the written markdown and with the major version jump that's a change that could be made.

Personally I don't have a usecase for the setting at this time so looking to the community for which is most likely preferred.

tommoor avatar May 11 '20 15:05 tommoor

My ideal usecase would be to limit users to using h2s and below in the editor, so sign me up for that behaviour!

dave-db avatar May 11 '20 15:05 dave-db

OFFTOPIC: is there a better place to ask questions about usage? I have a couple of queries relating to customising the markdown serialisation (using dashes over asterisks etc) and using image preview urls that aren't issues, and didn't want to clog things up here...

dave-db avatar May 11 '20 15:05 dave-db

You can open an issue for discussion – I'll probably close to keep things clean but it provides a place that others can find it in the future and a single thread for discussion. Github has a "discussions" feature in beta that should help with this kind of thing in the future – I'm attempting to get access.

tommoor avatar May 11 '20 15:05 tommoor