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 호출의 시작 값이 마크다운 문법(“*” 또는 “1.”)의 길이 + 공백 문자를 위한 1만큼 오프셋되어야 할 것 같습니다.

저는 오늘까지 그 도구 버튼을 사용한 적이 없었던 것 같습니다. 마크다운 편집기의 예시를 복사해야 해서 문제를 알게 되었습니다. 그 버튼들이 실제로 얼마나 많이 사용될지 궁금합니다.

1개의 좋아요

마크다운에 익숙하지 않은 개인들에게 이 버튼들은 유용합니다. 디스코스에서 디스코드로 전환한 커뮤니티에서 멤버들이 처음에 피드백한 내용 중 하나는 포맷팅 툴바의 부재였습니다. 하지만 포맷팅 기법을 익힌 후에는 포맷팅 명령어를 직접 입력하는 것을 더 선호하게 되었습니다. 다만 스마트폰이나 태블릿을 사용할 때는 예외입니다. 이는 버튼들이 손가락 근처에 배치되어 있어, 내 폰 키보드의 특수 문자보다 접근성이 더 좋기 때문입니다. 이것이 제가 이 버튼들을 사용하는 이유입니다.

또한, 원문에서 언급된 문제를 최근 보고했습니다.

1개의 좋아요

그건 좋은 정보네요! 마크다운 편집기에 포맷 버튼을 추가하느라 하루를 낭비한 게 아니라는 뜻이니까요.

또한, 컴포저 툴바의 문제가 이것임을 확인할 수 있습니다:

누군가 빨리 수정할 수 있을 거라고 생각하지만, 조금 더 기다릴 수 있다면 PR을 만들어도 기꺼이 하겠습니다.

1개의 좋아요