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 лайков

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.

4 лайка

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.

Это небольшая проблема, но она всё ещё проявляется для элементов нумерованных и маркированных списков:

Я предполагаю, что вызов setSelectionRange должен иметь начальное значение, смещённое на длину синтаксиса Markdown (“*” или “1.”) + 1 для пробела.

Кажется, я никогда раньше не пользовался этими кнопками инструментов. Я заметил эту проблему только потому, что мне понадобился пример редактора Markdown для копирования. Интересно, насколько часто эти кнопки используются на самом деле?

1 лайк

Эти кнопки полезны для тех, кто не знаком с разметкой Markdown. В сообществе, перешедшем с Discourse на Discord, одним из первых отзывов от участников было отсутствие панели форматирования. Однако, как только я освоил техники форматирования, я стал предпочитать вводить команды форматирования вручную, но не при использовании смартфона или планшета. Это связано с тем, что кнопки расположены ближе к пальцам, что делает их более доступными, чем специальные символы на клавиатуре моего телефона. Именно поэтому я их использую.

Я также недавно сообщил о проблеме, упомянутой в исходном сообщении.

1 лайк

Это хорошая новость! Значит, я не зря потратил весь день, добавляя кнопки форматирования в редактор Markdown.

Кроме того, могу подтвердить, что проблема с панелью инструментов редактора заключается в следующем:

Уверен, кто-то сможет быстро это исправить, но я с радостью сделаю pull request, если можно будет немного подождать.

1 лайк