Select only the content of a list item or blockquote

Hi, I noticed that when a user selects
Screenshot%20of%20Google%20Chrome%20(8-1-18%2C%202-12-07%20PM) ,
only the content of the emphasized text is selected so that the user can immediately start typing.
Screenshot%20of%20Google%20Chrome%20(8-1-18%2C%202-16-41%20PM)

This is true for strong text as well.
Screenshot%20of%20Google%20Chrome%20(8-1-18%2C%202-20-24%20PM)

However, when a user decides to create a ordered list, unordered list, or blockquote, the Markdown keyboard symbol is selected as well, which means that a user can’t immediately stop typing.

Screenshot%20of%20Google%20Chrome%20(8-1-18%2C%202-13-38%20PM) Screenshot%20of%20Google%20Chrome%20(8-1-18%2C%202-13-42%20PM) Screenshot%20of%20Google%20Chrome%20(8-1-18%2C%202-13-35%20PM)

This is an annoyance to users who know Markdown, because I need to re-select only the content, and absolutely infuriating for a user who doesn’t because they might not even know what’s wrong.

Can this be updated so that only the content of whatever is being listed or quoted is selected, and not the keyboard symbol itself?

Finally, in the spirit again of helping people who don’t know Markdown. Could “strong text” be replaced with “bold text” and “emphasized text” be replaced with “italicized text”?

9 Likes

I like this suggestion, @codinghorror’s call on the wording here. I agree calling italics emphasised in the tooltip is somewhat confusing. Looking at Stack Exchange sites it uses “Emphasis” and “Strong” so there is precedent even in non tech sites. GitHub uses “Bold” and “Italic”.

Regarding making Italics/Bold smarter. There are quite a few edge cases… for example, when you highlight this block and hit “B” what do you expect?

- test
    -  text
-test
(3) test

4. test

[spoiler]
test
[/spoiler]

test [i]test
test[/i]

The ideal outcome has a LOT of magic rules, and we don’t want to have to write a full parser here.

- **test**
    -  **text**
**-test**
**(3) test**

4. **test**

[spoiler]
**test**
[/spoiler]

**test [i]test
test
[/i]**

I am sort of pr-welcome here, but we got to determine what a very simple set of rules that capture the 99% case first.

3 Likes

I see (1) highlighting text, then hitting “B” as different from (2) not having text and hitting “B”. The first case does have a lot of magic rules. Perhaps until there’s rich text editing (if that’s at all a priority), include a button that links to Markdown syntax? An you know, I think the second case already works very well for “B” and should be replicated for lists and blockquotes.

It’s a minor issue, but this is still happening with the ordered and unordered list items:

image

I’m guessing there’s a call to setSelectionRange that needs to have its start value offset by the length of the markdown syntax (“*” or “1.”) + 1 for the space character.

I don’t think I’d ever used those tool buttons before today. I only noticed the issue because I needed an example of a markdown editor to copy. I wonder how much actual use those buttons get?

1 Like

The buttons are useful for individuals unfamiliar with markdown. In a community that transitioned from Discourse to Discord, one of the initial feedback from the members was the absence of the formatting toolbar. However, once I had learned the formatting techniques, I found myself preferring to type the formatting commands, but not when using a smartphone or tablet. This is because the buttons are placed near your fingers, making them more accessible than special characters on the keyboard of my phone. This is the reason I use them.
I have also recently reported the issue that was mentioned in the op.

1 Like

That’s good to know! It means I didn’t just waste my day adding formatting buttons to a markdown editor.

Also, I can confirm that this is the issue with the composer toolbar:

I’m sure someone can fix that quickly, but I’d be happy to make a PR if it can wait a bit longer.

1 Like