Styles block not updating as we move our cursor

[d-e-v-esh]

Bug Report 🐛

(Package: Markdown Editor) The styles block that shows the current styling (H1, H2, Normal Text, etc.) does not get updated with the move of our cursor. It only updates when we start writing inside that block. This is not the case in editors like google docs. They update the styling bar as the cursor moves. This might get very annoying when we try to find the styling of a block and just clicking on the block does not do anything. Then we need to write to find out what the styling is.

Expected Behavior

The styling box should change according to the block of text that our cursor is on top of.

Current Behavior

The styling box does not change according to the block of text that our cursor is on. It waits for us to write inside of the block to update.

Possible Solution

Steps to Reproduce

1. Go to the markdown editor.
2. Monitor the style box as you move the cursor around the text of different kinds of styles.
3. The style box would not update as you move around different kinds of blocks

Context (Environment)

Desktop

• OS: Windows 10
• Browser: Chrome
• Version 88.0.4324.182 (Official Build) (64-bit)

Detailed Description

Possible Implementation

[d-e-v-esh]

@Michael-Grover I would like to work on this issue.

[d-e-v-esh]

@Michael-Grover I have almost fixed the problem by calculating the result(current block) in the onChange function. The style block does not respond to Heading 4, Heading 5, and Heading 6 as they are already not listed in the dropdown menu. Are those text styles going to get dropped in the future?

[Michael-Grover]

I think there's a reason for having h4-h6 but I'm not sure. @DianaLease or @irmerk do you remember? I think we have h4-h6 because markdown usually has those header styles, and if people import markdown text that includes h4-h6, we don't want the document to break.

[irmerk]

I don't recall the reason for omitting H4-H6. My best guess is it was purely design based. But we're based off the CommonMark spec, which does support H1-H6. Is there any limitation in @accordproject/markdown-transform @dselman or @jeromesimeon? It doesn't look like it from our own documentation

[Michael-Grover]

My reasoning for omitting H4-H6 in the dropddown is because the size difference between the six different headers and one paragraph style would be practically indistinguishable from each other unless the H1 was comically large (which it used to be). By having fewer header styles, we can be sure that they are each visually distinct from each other

I would be interested in a lawyer's opinion about how many levels of headings they would need in a contract. I can't think of any contracts I've seen with six different heading styles. It's my understanding that usually the formatting of contracts is very minimal, and hierarchy of information is shown with nested lists of sections and subsections rather than different sizes of headings.

[irmerk]

My thought would be that would be up to the individual lawyer using the editor, and that person can choose to use H5 or not based on the styling. If we are based on the CommonMark spec, we should support the CommonMark spec.

[Michael-Grover]

Jira uses six heading styles, and they choose to make H4-H6 smaller than the paragraph text, which seems kind of weird to me. I'm not sure how many contract authors will want headings that are smaller than the paragraph text. However I think I prefer their approach versus making all of the headings styles a size between H1 and paragraph, meaning that they will be very similar in size and visually indistinguishable. Maybe we should discuss in the next AP Tech WG call to get opinions from engineers and lawyers?

[irmerk]

@Michael-Grover could you create a separate issue for the H1-H6 topic?

@d-e-v-esh I think you can continue on with what currently exists (H1-H3) and get a solution that will work with whatever comes from the H1-H6 Issue.