Gutenberg: 자식 / 부모 블록 선택을위한 도구 향상

나는 빵 부스러기 아이디어를 좋아한다. (사실 4 월의 # 6459에서 꽤 비슷한 것을 제안했습니다.) 통합 툴바가 활성화되면 탐색 경로는 어떻게됩니까?

또한 클릭 연결 아이디어도 좋다고 생각하고 이미 모바일에서 사용되고 있으므로 일관성을 더합니다. 하지만 패스 스루 아이디어에 대해서는 잘 모르겠습니다. 블록에 걸쳐 다른 동작으로 인해 혼란을 일으킬 수 있다고 생각합니다.

나는 이동 경로를 좋아하지만 통합 툴바도 좋아합니다. 이동 경로에 대한 다른 위치를 찾을 수 있습니까? :)

또한 개인적으로 부모 블록 주변의 테두리가 마음에 들지 않습니다. 그러나 우리가 그것들을 유지한다면, 다중 선택을 어떻게 처리할까요? :). 다중 선택된 블록의 부모 주위에 테두리를 표시해야합니까?

클릭 연결 옵션이 마음에 듭니다. 이를 위해서는 '통과'블록에 대한 추가 작업이 필요합니다 (예를 들어 각 개별 "열"은 클릭 할 레이어로 간주되지 않음).

통합 툴바가 활성화되면 이동 경로는 어떻게됩니까?
나는 이동 경로를 좋아하지만 통합 툴바도 좋아합니다. 이동 경로에 대한 다른 위치를 찾을 수 있습니까? :)

좋은 질문. 빠르고 더러운 모형 :

예, 스위처의 중복 아이콘 문제가 보입니다. 계속 생각하는 것이 좋다고 생각합니다. 또한이 디자인이 # 4287에서 차단 된 문서 개요를 생략하는 방법에 유의하십시오.

또한 개인적으로 부모 블록 주변의 테두리가 마음에 들지 않습니다. 그러나 우리가 그것들을 유지한다면, 다중 선택을 어떻게 처리할까요? :). 다중 선택된 블록의 부모 주위에 테두리를 표시해야합니까?

내부 블록이 부모 그룹의 일부임을 나타내는 것으로 표시하는 것이 중요하다고 생각합니다. 그들은 내부 블록을 _ 고정 _합니다.

지금은 다중 선택이 작동하는 방식입니다.

그리고 이것은 두 개의 자식 블록을 선택하면 발생합니다.

즉, 마스터에서는 이미 부모 테두리가 있고 _ 그리고 _ 자식 블록을 여러 개 선택할 때 숨 깁니다. 실제로 다중 선택에서도 항상 부모 테두리를 표시하는 것이 _ 하위 블록 만 선택하는 경우 _ 의미가 있다고 생각합니다. 그러나 아마도 우리는 _parent_ 블록이 다중 선택 될 때 다중 선택을 다르게해야합니다. 따라서 추가 레이어 효과로 모든 하위 블록을 강조 표시하는 대신 상위 블록 만 강조 표시합니다. 작동할까요?

클릭 연결 옵션이 마음에 듭니다. 이를 위해서는 '통과'블록에 대한 추가 작업이 필요합니다 (예를 들어 각 개별 "열"은 클릭 할 레이어로 간주되지 않음).

예, 현재 _column_ 자식 블록에 몇 가지 UI 문제가 있습니다. 예를 들어 앞에 블록을 삽입 할 수 없는데 왜 선택할 수 있습니까? 하지만 이것은 엄청나게 어려운 기술적 도전이고, 나는 그것이 수반되는 도전을 이해합니다. 그래서 나는 이것이 쉽다고 말하는 것이 아닙니다.

https://github.com/WordPress/gutenberg/pull/9653 에서 작업하면서 계층을 탐색하기 위해 이미 존재하는 화살표 키 탐색 (부모를 선택하기 위해 열을 선택할 때 위쪽 화살표 키 사용)을 깨달았습니다. , 즉 열 블록)이 정말 잘 작동합니다. 실제로이 기능을 Windows 파일 탐색기의 "상위 폴더로 이동"과 유사한 "위로"버튼으로 표시하는 것만으로도 완전한 이동 경로 대신 충분할 수 있습니다.

이것이 어떻게 보일 수 있는지 보여줍니다. 상단 도구 모음 :

블록 도구 모음 :

CC : @youknowriad

몇 가지 생각

빵 부스러기

나는 이동 경로 솔루션을 좋아하지만 모호함이 있고 아이콘 전용 인터페이스가 문제가 될 수 있으며 아이콘 위로 마우스를 가져 가서 아이콘이 무엇인지 확인하거나 이동 경로가 아닌 옵션 도구 모음의 이동 경로를 혼란스럽게 할 수 있습니다.

따라서 상단 도구 모음이 표시하기에 가장 좋은 곳이 아닐 수 있으며 다른 곳의 탐색 경로에서 가져온 단서가 도움이 될 것입니다. 예를 들어, 현재 파일-> 클래스-> 메소드 / 기능을 보여주는 PHPStorm의 계층 도구 모음 또는 MacOS Finder 및 Windows 탐색기의 폴더 도구 모음?

클릭을 통해

클릭 스루는 숨겨진 UI가 될 것입니다. 사람들이 이미지 블록을 선택하기 위해 이미지 블록을 선택하기를 기대하기 때문에 많은 오해와 혼란을 볼 수 있습니다. 일반적으로 Adobe 소프트웨어에서 UI를 클릭하면 모드가 도입되기 때문에 혼란스럽고 특히 중첩이있는 경우 현재 위치와 종료 방법을 알기가 어렵습니다. 예를 들어 두 번 클릭하여 자식 블록에 들어가는 경우 부모 블록으로 돌아가는 방법과 UI가 블록 안에 있음을 어떻게 표시합니까?

모드에 대한 많은 연구와 지침이 있으며, Illustrator 또는 Photoshop에 있기 때문에 좋은 것으로 간주해서는 안됩니다. 적절한 솔루션이되기 전에 클릭하는 것보다 훨씬 더 많은 작업이 필요합니다.

https://medium.com/interaction-reimagined/dangers-of-modal-user-interfaces-316828de8161

http://www.azarask.in/blog/post/is_visual_feedback_enough_why_modes_kill/

이것은 또한 이것이 엉망이되는 모든 접근성 요소를 무시하고 있습니다.

위로 버튼

위로 버튼 아이디어가 좋습니다. 내 우려는 버튼을 누르면 아래로 버튼이 나타나고 블록이 위쪽으로 이동하고 모호하며 이동 경로 블록과 동일한 문제가 발생한다는 것을 의미합니다.

재사용 가능한 블록 패턴

현재 재사용 가능한 블록에는 이미 프런트 엔드에 표시되지 않는 블록 인터페이스에 크롬을 추가하는 UI 패턴이 있습니다. 열이 동일하지 않을 수 있습니까?

또는 내가 의미하는 바에 대한 슈퍼 쓰레기 모형

따라서 열 블록의 크롬은 선택하는 데 사용되며 마우스를 조준 할 수있는 시각적 인 것을 제공합니다.

툴바 모델에 맞도록 여기서 사용할 수있는 한 가지 잠재적 UX 패턴은 OS X 폴더 탐색 버튼입니다 : https://cld.wthms.co/avtQLO

사용자가 클릭과 선택을 통해 시각적으로 자식 / 부모 블록을 선택할 수있을 것으로 기대할 수 있다고 생각하지만, 올바르게 가져 오는 데는 많은 복잡성이 있습니다. 위의 순회 패턴은 좋은 첫 단계가 될 수 있으며 2 단계에서 더 우아한 솔루션을 개발하는 데 더 깊이 들어갈 수 있습니다.

나는 알렉시스라는 개념을 _adore_하는데, 특히 당신이 언급 한 더 복잡한 블록에 대한 것입니다. 나는 그것을 너무 좋아해서 즉시 실행하고 아이디어를 설명하기 위해 몇 가지 모형을 리믹스했습니다.

선택 없음 :

선택한 차단 :

선택한 내부에 중첩 된 블록 :

폴더 탐색 버튼 팝업이 열립니다.

☝️ 저는 그 개념이 마음에 듭니다.이 스레드에서 공유 된 모든 아이디어와 피드백이 함께 녹아서 _solid_ 기준선이 반복되는 것처럼 느껴집니다. 신선한 시각을 가져와 주셔서 감사합니다!

저는 시각적 트리가있는 드롭 다운을 좋아합니다. 일부는이 형식으로 전체 문서를 보는 것도 도움이 될 것이며 항목을 재정렬하는 유용한 방법을 제공 할 것이라고 생각합니다.

그러나 더 생각해 보면 이미 이와 같은 선택 메커니즘과 정보 패널에 문서 개요가 있다는 것을 상기했습니다.

이것은 모형의 스타일을 통해 향상 될 수 있으며 추가 선택 기호로 사용됩니다. 현재로서는 제목 만 표시되지만 전체 블록 트리와 선택 표시기가있는 버전은 매우 유용합니다.

내 유일한 단점은 도구 모음 아이콘 자체입니다. 화살표가있는 또 다른 미스터리 아이콘이며 도구 모음을 사용자 화하지 않는 한 기본적으로 MacOS의 Finder에없는 버튼입니다. 아이콘 시각 장애가 있고 아이콘을 쉽게 구분할 수없는 사람들에게는 문제가됩니다.

텍스트 레이블을 사용하면 더 명확 해지지 만 클릭하지 않고는 무엇을했는지 대부분 알 수 없습니다.

보기 좋게 보임 :) 가독성을 높이기 위해 아이콘을 약간 단순화 해 볼 수 있습니까? 간격이 4 개가 아닌 3 줄일까요?

텍스트 라벨을 사용하면 더 명확 해지지 만 클릭하지 않고는 무엇을했는지 알 수 없습니다.

툴팁도 있습니다.

re : @tomjn 의 의견에서, 이것이 별도의 장소를 만드는 것보다 전체 문서 트리에 통합 될 수 있다면 탐구 할 가치가 있다고 생각합니다. 문제는 트리의 단순성과 스캔 가능성을 유지하면서 훨씬 더 많은 수준의 물건을 수용하는 것입니다. 그러나 그것은 전체 페이지 구조에 대한 단일 소스 인 Sketch 또는 Photoshop의 레이어 패널 (디자인이 아닌 기능)과 비슷할 수 있습니다. 잘하기 위해 도전하지만 탐험할만한 가치가 있습니까?

다시 말하지만, 이것은 우리가 반복하는 것일 가능성이 높습니다. 그렇다면 더 정교한 것으로 성장할 수있는 가장 유용한 MVP는 무엇일까요?

툴팁도 있습니다.

충분하지 않다고 생각 합니다만, 별도의 논의와 기능 요청이라고 생각합니다. 새로운 티켓을 열겠습니다.

가독성을 높이기 위해 아이콘을 약간 단순화 할 수 있습니까? 간격이 4 개가 아닌 3 줄일까요?

나는 그것을 좋아한다 :

그러나 더 생각해 보면 이미 이와 같은 선택 메커니즘과 정보 패널에 문서 개요가 있다는 것을 상기했습니다.

나는 또한 이것이 별도의 장소를 만드는 것보다 전체 문서 트리에 통합 될 수 있다면 탐구 할 가치가 있다고 생각합니다.

그게 효과가 있다고 생각합니다. 이전에 항목을 플러그인으로 다시 작성하여 오른쪽에 표시되도록 제안했습니다 (# 4287 참조). 그러나 나는 이것을 문서 트리를 위해 용도 변경하는 팬입니다.

레이블에 관해서는 레이블을 좋아하지만 블록 도구 모음을 맨 위에 고정하는 옵션을 고려할 필요가 있습니다.

이 토론은 # 9053 (CC : @westonruter)을 떠올리게합니다. https://github.com/WordPress/gutenberg/issues/9628#issuecomment -429012989에 나와있는 Alexis의 제안을 좋아할 것 같습니다.

계속 진행되는 것을보고 @alexislloyd 개념에 감사드립니다. @jasmussen 저는이 모의를 정말 좋아하고 우리가 반복 할 수있는 좋은 점이 있다고 생각합니다.

그렇다면 좀 더 정교한 것으로 성장할 수있는 가장 유용한 MVP는 무엇일까요?

나는 이것을 더 간단한 순회 컨트롤로 만들고 나중에 선택을 기반으로 문서 콘텐츠 상자와 결합하는 것이 합리적인지 확인한다고 말하고 싶습니다.

# 10767의 논의에 따라 이것을 다시 열어 반복하십시오.

# 11159에 제안 된 추가 아이디어도 참조하십시오.

복잡한 블록으로 더 쉽게 작업 할 수있는 또 하나의 아이디어는 _ 선택되지 않은 블록은 미리보기 _이고 _ 선택된 블록은 추가 편집 컨트롤을 표시 할 수 있음 _입니다.

이 아이디어를 활용하여 열 블록의 요소를 더 쉽게 선택할 수 있습니다. 예를 들어 열 블록 또는 그 하위 항목이 선택되면 컨테이너의 패딩이 애니메이션되어 하위 요소를 선택할 수있는 공간을 만듭니다. 이렇게하면 측면 UI에 액세스 할 수 있습니다. 패딩이 확장 된 부모 블록 (예 : 파선) 주위에 테두리를 표시하려고합니다.

자식이 선택 되더라도 최상위 블록에서 .is-selected 클래스를 복원하면 구현하기가 비교적 간단 해 보입니다. 한동안 hasSelectedInnerBlocks 소품을 사용하여이 작업을 수행했습니다.

열 블록의 셀 위로 마우스를 가져 가면 다음과 같이 표시됩니다.

미디어 및 텍스트 블록의 셀 위로 마우스를 가져갑니다.

하나는 내부 블록과 외부 블록을 봅니다.
열-> 단락과 같은. 열-> YouTube. 미디어 및 텍스트-> YouTube

호버 정보의 탐색 경로 정보 (내부 및 외부 블록)를 클릭 가능하게 만드는 것이 좋습니다. 열을 클릭하여 상위를 선택하거나 단락을 클릭하여 하위를 선택하십시오.

방금 시도해 보면 부모 열 블록을 선택하는 가장 간단한 방법은 부모 블록의 오른쪽 / 왼쪽에 제공하는 추가 보이지 않는 히트 영역을 활용하는 것입니다.

이 추가 적중 영역은 블록의 상단과 하단에서 사용할 수 없으므로 그런 방식으로 선택하기가 훨씬 더 어렵습니다.

복잡한 블록으로 더 쉽게 작업 할 수있는 또 하나의 아이디어는 선택되지 않은 블록이 미리보기이고 선택한 블록이 추가 편집 컨트롤을 표시 할 수 있다는 점을 기억하는 것입니다.

이 아이디어를 활용하여 열 블록의 요소를 더 쉽게 선택할 수 있습니다. 예를 들어 열 블록 또는 그 하위 항목이 선택되면 컨테이너의 패딩이 애니메이션되어 하위 요소를 선택할 수있는 공간을 만듭니다. 이렇게하면 측면 UI에 액세스 할 수 있습니다. 패딩이 확장 된 부모 블록 (예 : 파선) 주위에 테두리를 표시하려고합니다.

이것이 @jasmussen 이 위에서 제안한 내용인지 100 % 확실하지 않지만 편집 모드에서 부모 블록의 일부 패딩 + 시각적 표시기를 추가하면 여기서 큰 도움이 될 수 있습니다. 이렇게하면 상위 항목을 선택하려는 경우 클릭해야하는 위치가 명확하게 표시됩니다.

누군가가 블록을 빠져 나가면 해당 추가 패딩이 사라져 블록을보다 정확하게 표현할 수 있습니다.

이 추가 적중 영역은 블록의 상단과 하단에서 사용할 수 없으므로 그런 방식으로 선택하기가 훨씬 더 어렵습니다.

이 문제에 대한 티켓이 있었는데 이는 형제 삽입 기가 작동하는 방식과 관련이 있습니다. 지금은 찾을 수 없지만이 문제를 해결할 수 있어야한다고 생각합니다. @aduth 벨을

이것이 @jasmussen 이 위에서 제안한 내용인지 100 % 확실하지 않지만 편집 모드에서 부모 블록의 일부 패딩 + 시각적 표시기를 추가하면 여기서 큰 도움이 될 수 있습니다. 이렇게하면 상위 항목을 선택하려는 경우 클릭해야하는 위치가 명확하게 표시됩니다.

그것은 내가 의미하는 바가 다소 정확하며 내가 할 수있는 것보다 더 아름답게 시각화되었습니다.

내가 의미하는 바를 설명하기 위해 추가 크레용 스케치가 있습니다. 열 블록 :

본질적으로 당신이 가지고있는 것, Kjell — 아마도 점선이 약간 더 어둡게 보일 것입니다. 또한 열 블록의 추가 개발 방법에 따라 _column_ 블록도 있음을 기억하십시오. 즉, 현재 계층 구조는 _Columns → Column → Image_입니다. 우리는 두 번째 수준을 다소 보이지 않게 만들기 위해 치열한 CSS 마법사를 사용하고 있지만 나중에 CSS 클래스를 적용하거나 개별 열에 필요한 다른 옵션을 선택하려는 경우에는 고려할 가치가 있습니다.

슬라이드 쇼 블록 :

명확하게 말하면 슬라이드 쇼 블록이 계획되어 있지 않습니다. 이것은 블록의 미리보기 및 편집 모드가 _ 넓게 _ 다를 수 있다는 점을 설명하기 위해 순수하게 낙서 된 것입니다. 단순히 블록을 선택하고 선택을 취소하여 두 모드 사이를 전환하는 것은 매우 쉽고 놀랍도록 중단되지 않으므로 우리는 그것에 의지하고 기회에 대해 창의적이 될 수 있어야합니다.

슬라이드 쇼 블록의 경우 거의 정의에 따라 콘텐츠가 화면 / 블록 외부에서 보이지 않습니다. 하지만 편집 할 때 꼭 그럴 필요는 없습니다. 편집 가능한 캡션이있는 썸네일을 보려면 블록을 선택하기 만하면됩니다. 그런 다음 블록을 선택 취소하여 결과를 미리 봅니다.

이 문제에 대한 티켓이 있었는데 이는 형제 삽입 기가 작동하는 방식과 관련이 있습니다. 지금은 찾을 수 없지만이 문제를 해결할 수 있어야한다고 생각합니다. @aduth 벨을

가장 가까운 것은 # 8883, # 8881, # 5180 중 하나 일 수 있습니다.

문서 트리가 도움이되지만 여전히 내가 조작하려는 것에서 초점을 변경해야합니다. 실제 블록과 중첩 된 블록을 직접 클릭하는 더 좋은 방법을 원합니다. @jasmussen 이 위에서 설명한 클릭 스루 방법이 더 많이 탐색 할 가치가 있다고 생각합니다.

내가 일반적으로 경험하는 문제는 다음과 같습니다.

사용자로서 나는 화면의 다른 곳에있는 다른 솔루션을 찾기 전에 적어도 1 분 동안 이것으로 싸울 것입니다. 😉

* _이 댓글을 추가했을 때 다른 댓글이 많이 나왔습니다. 지금은 그다지 적절하지 않을 수도 있지만, 투쟁을 문서화하기 위해 여기에 보관하고 있습니다 ._

그러나 편집 모드에서 패딩 + 부모 블록의 시각적 표시기를 추가하면 여기에서 큰 도움이 될 수 있습니다. 이렇게하면 상위 항목을 선택하려는 경우 클릭해야하는 위치가 명확하게 표시됩니다.

이 솔루션에 대한 내 관심사는 주변 블록과 관련하여 패딩이 작동하는 방식입니다.

1. 부모 블록의 패딩이 프런트 엔드에 반영됩니까? 아니면 편집기에서 더 많은 패딩?

2. 블록이 선택되면 패딩이 동적으로 추가됩니까?

1. 아니면 패딩 처리 된 부모가 다음과 같이 주변 블록 위에 나타날 수도 있습니다.

이 개념을 더 깊이 파헤 치려고합니다. 그것에 대한 몇 가지 생각을 좋아할 것입니다.

@aduth 감사합니다, 당신은 적어도 올바른 방향으로가는 티켓을 찾도록 만들었습니다. # 9229의 GIF는 문제를 설명합니다. GIF의 노란색 영역은 형제 삽입기를 위해 "예약"되어 있습니다. 이것이 블록 위 또는 아래의 패딩을 클릭하여 블록을 선택하지 못하게하는 것입니다. 이것이 @kjellr 의 의견에 대한 대답입니다.

이 추가 적중 영역은 블록의 상단과 하단에서 사용할 수 없으므로 그런 방식으로 선택하기가 훨씬 더 어렵습니다.

더 명확히하기 위해 노란색 영역은 형제 삽입 기 버튼을 보이게하기위한 것입니다. 그래서 우리가 가로 채기 위해 필요한 것은 _hover_ 액션입니다. 클릭이 여전히 노란색 막대를 통해 전파되고 아래 블록을 선택할 수 있다면 좋을 것입니다.

문서 트리가 도움이되지만 여전히 내가 조작하려는 것에서 초점을 변경해야합니다. 실제 블록과 중첩 된 블록을 직접 클릭하는 더 좋은 방법을 원합니다. @jasmussen 이 위에서 설명한 클릭 스루 방법이 더 많이 탐색 할 가치가 있다고 생각합니다.

현재 구현이 약간 덜어 졌더라도 실제로 지금 바로 테스트 할 수 있습니다.

• 모든 버전의 Gutenberg를 실행하십시오.
• 콘텐츠가있는 열 블록을 삽입합니다.
• 창 크기를 600px 중단 점 아래로 조정 한 다음 선택합니다.

즉, 상위 블록을보다 쉽게 ​​선택할 수 있도록 모바일 용으로 구현됩니다.

GIF :

현재 구현의 문제점은 가장 깊은 수준으로 드릴 다운하면 "상태"가 재설정된다는 것입니다. 따라서 동일한 단락을 두 번 선택하는 경우에도 열> 열> 단락, 열> 열> 단락입니다. 이 문제에 대한 확실한 해결책은 원하는 수준으로 "드릴 다운"한 후 블록을 다시 선택 취소 할 때까지 해당 수준에 _ 유지 _하도록 만드는 것입니다. 즉, 열> 열> 단락, 단락, 단락, 선택 취소, 되감기 등

또한 _some_ 블록의 경우이 클릭 스루 방법이 매우 중요 할 것이라고 생각합니다. 특히 모든 종류의 중첩 된 콘텐츠를 포함 할 수있는 페이지 템플릿을 살펴보기 시작합니다.

놀랍을 때 클릭 연결이 어떻게 작동 할 수 있는지에 대한 영감은 Keynote에서도 시도 할 수 있습니다. 몇 가지 도형을 삽입하고 직접 클릭 할 수 있습니다. 두 개의 도형을 _ 그룹화하면 이동하기 쉬운 새로운 도형이됩니다. 그러나 그룹의 내용을 편집하려면 두 번 클릭해야합니다.

https://github.com/WordPress/gutenberg/issues/9628#issuecomment -456637172에서 좋은 질문에 답하려면 :

부모 블록의 패딩이 프런트 엔드에 반영됩니까? 아니면 편집기에서 더 많은 패딩?

아니요,이 패딩은 편집기에만 있으며 _block이 선택된 경우에만 있습니다 _. 이것은 블록이 인터페이스 원칙을 기반으로하며 편집기에 다음과 같이 표시됩니다.

• 선택하지 않은 블록은 미리보기입니다. 가능한 한 프런트 엔드로 보여야합니다.
• 선택된 블록은 본질적으로 "블록 편집 모드"이며 블록은이 상태에서 추가 컨트롤을 출력 할 수 있으며 완전히 다르게 보일 수도 있습니다.

위의 예제 슬라이드 쇼 블록 낙서를 사용하여 강조 표시를 시도한 것입니다. 슬라이드 쇼 블록이 선택되지 않은 경우 슬라이드 쇼입니다. 선택하면 _ 슬라이드 쇼 편집 모드 _ 상태가되며 모든 슬라이드의 썸네일 그리드를 볼 수있어 캡션 편집, 재정렬 등을 쉽게 할 수 있습니다.

블록이 선택되면 패딩이 동적으로 추가됩니까?

예, 다소간입니다.

나는 이것이 더 잘 설명하고 그것에 대한 느낌을 얻기 위해 프로토 타이핑 할 가치가 있다고 생각합니다.

궁극적으로이 기능은 블록 자체의 소품이어야하며 블록이 사용하도록 선택할 수 있습니다. 예를 들어 중첩 된 단락이있는 인용구는이 인터페이스를 사용하지 않아야하지만 열을 편집 할 때는 완벽 할 수 있습니다.

다음은 빠른 코드 펜 프로토 타입입니다. https://codepen.io/joen/pen/exmMQv?editors=1100

다소 정적이지만 요점을 이해하기를 바랍니다.

다음은 빠른 코드 펜 프로토 타입입니다. https://codepen.io/joen/pen/exmMQv?editors=1100

다소 정적이지만 요점을 이해하기를 바랍니다.

그것은 정말로 요점을 이해하는 데 도움이됩니다. 클릭시 파선 테두리가 어떻게 나타나는지 확인할 수 있도록 약간 수정했습니다.

https://codepen.io/kjellr/pen/jdEJQb?editors=0110

이것은 완벽합니다, Kjell 감사합니다! 그것이 바로 제가 의미하는 바입니다. 구현의 일부 측면을 조정하고 직계 부모 (단일 열)가 패딩을받을 때 어떻게 보이는지 설명하고 싶을 것입니다. 그러나 이것은 멋지다! 작동 할 수 있다고 생각합니다.

나는 이것을 정말로 좋아한다.
더 많은 블록과 콘텐츠로 테스트하기 위해 PR을 만들어야합니까?
이것이 영향을 미칠 블록을 식별해야합니까?

나도 파고 있습니다.

지금은 Columns 블록에서 프로토 타입을 만들 수 있지만 착륙하려면이 _method_가 모두 일반이어야하므로 다른 블록 (당신이 말했듯이)도 이것을 사용할 수 있지만 블록이 이것을 선택하십시오. 일단 중첩 된 블록을 수신하면 Quote 블록이 이것을 갖는 것은 방해가 될 수 있습니다.

@gziolo 어떤 생각? 특히 https://github.com/WordPress/gutenberg/issues/9628#issuecomment -456811415에서 Kjell이 낙서 한 접근 방식에 대해 설명합니다.

@gziolo 어떤 생각? 특히 # 9628에서 Kjell이 낙서 한 접근 방식에 대해 설명합니다 (코멘트).

멋지네요. 마침내 필요할 때 부모 블록을 쉽게 선택할 수있게되었습니다. 내 유일한 질문은 다른 열을 더 좁게 만드는 대가로 열의 너비를 원래 크기에 더 가깝게 만드는 것에 대해 어떻게 생각하십니까? 현재 모든 열 중 하나를 선택하면 모든 열이 축소되어 3 개 이상의 열이있을 때 최적이 아닐 수 있습니다. @jasmussen 다른 질문이 있습니까? 대답해야합니까?

내 유일한 질문은 다른 열을 더 좁게 만드는 대가로 열의 너비를 원래 크기에 더 가깝게 만드는 것에 대해 어떻게 생각하십니까?

나는 이것이 우리가 아마도 구현 단계에서 미세 조정하고 균형을 잡아야한다는 것에 동의하는 경향이 있습니다. 기술적으로 더 어려울 수 있지만 자식의 크기를 줄이지 않기 위해 부모의 너비 / 높이를 확장 할 수도 있습니다.

다른 질문이 있습니까? 제가 대답해야합니까?

기본적으로 여기서 논의하는 인터페이스는 다음과 같습니다. 자식 블록이 선택 될 때 부모 블록에 패딩을 추가하여 . 이 _feels_는 Columns 블록에 대한 Kjell의 프로토 타입에서 좋습니다. 섹션 블록과 같은 다른 블록이나 하위 콘텐츠가 내부의 모든 사용 가능한 공간을 채울 가능성이 높은 다른 블록에서 매우 환영받을 것입니다. 그러나 아직 중첩을 사용하지 않지만 앞으로 그렇게 할 가능성이있는 Quote 블록과 같은 경우에는 좋지 않을 것입니다.

따라서 모든 블록에 대해 _generic_, 기본적으로 _off_ 인 방식으로 부모 선택 인터페이스를 구축하는 것이 좋을 것입니다.

최선의 접근 방법에 대한 제안이 있습니까?

중첩 된 블록 (현재 열, 미디어 및 텍스트)을 포함하는 모든 블록은 .editor-inner-blocks 클래스를 렌더링하는이 InnerBlocks 구성 요소를 렌더링합니다.
https://github.com/WordPress/gutenberg/blob/16a718a4bf359c53f0fb9c3626b08e2434a6fd7d/packages/editor/src/components/inner-blocks/index.js#L103
이것은 모든 중첩 블록에서 작동하는 일반적인 솔루션을 찾는 데 도움이 될 수 있습니다. 그러나 .is-selected 가 하위 요소 중 하나에 적용되므로 까다로울 수 있습니다.

Edit: CSS에서만 작동하지 않는 경우. 중첩 된 블록 중 하나가 선택되었다는 정보를 노출하기 위해 부모의 상태를 업데이트하는 방법을 항상 찾을 수 있습니다. @jorgefilipecosta 와 @aduth 는 중첩 블록으로 많은 시간을 보냈기 때문에 그것에 대해 더 많은 통찰력을 가질 수 있습니다. :)

따라서 기본적으로 모든 블록에 대해 일반적인 방식으로 부모 선택 인터페이스를 구축하는 것이 좋지만 블록이 소품을 사용하도록 선택할 수 있습니다.

중첩을 사용하지 않는이 접근 방식에 대해 어떤 블록을 고려하십니까? 이것은 왜 그들이 처음에 중첩을 사용하지 않는지 생각하게 만들었습니다. 갤러리를 중첩 된 이미지 블록이있는 컨테이너로 변환한다고 상상해보십시오. 우리는이 동작을 무료로 얻을 수 있지만 보너스로 분류하기도합니다.

중첩을 사용하지 않는이 접근 방식에 대해 어떤 블록을 고려하십니까?

갤러리는 흥미로운 것입니다.

솔직히 저는 그리드 레이아웃 블록, 탭 그룹 블록 또는 기타 유사한 "페이지 빌드"블록과 같은 고급 레이아웃 블록을 주로 생각하고 있습니다. 특정 콘텐츠는이 인터페이스를 사용하지 않아야합니다.

솔직히 저는 그리드 레이아웃 블록, 탭 그룹 블록 또는 기타 유사한 "페이지 빌드"블록과 같은 고급 레이아웃 블록을 주로 생각하고 있습니다. 특정 콘텐츠는이 인터페이스를 사용하지 않아야합니다.

나는 그것들이 모두 컨테이너 블록 범주에 적합 할 것으로 예상합니다. 즉, 구현 세부 사항으로 InnerBlocks 를 사용해야하므로이 범주에 맞아야합니다. 블록 정의에서 supports 그룹을 사용하여 다른 기능에 대해 수행하는 것과 유사한 옵트 아웃을 제공 할 수 있습니다.

나는 그것들이 모두 컨테이너 블록 범주에 적합 할 것으로 예상합니다. 즉, 구현 세부 사항으로 InnerBlocks를 사용해야하므로이 범주에 맞아야합니다.

그러나 Quote 블록은 중첩 기능을 받았을 때 내부 블록도 사용하지 않습니까?

그러나 Quote 블록은 중첩 기능을 받았을 때 내부 블록도 사용하지 않습니까?

예, 인용문, 목록, 표지-이 3 개는 과거에 중첩 된 블록으로 변환 된 것으로 간주되었습니다.

한 가지 우려 사항 (실험을 차단해서는 안되지만 주목할 가치가 있습니다!)은 열 블록이 얼마나 좁을 수 있고 편집 모드 도구에 어떤 영향을 미치는지 측면에서 이미 몇 가지 문제가 있다는 것입니다. 이 제안은 상호 작용을 편집하는 동안 열을 더욱 _ 좁게 만들 수 있으며, 이로 인해 이러한 좁은 문제가 다시 나타날 수 있습니다.

또한 문제가 될 수도 있고 아닐 수도있는 일대일 편집 /보기 패리티에서 더 멀리 밀어냅니다. 이미 InnerBlocks가있는 사용자 지정 블록에서 이와 비슷한 작업 (선택시 추가 패딩)을 수행하고 있으며 잘 작동하지만 편집보기가 정확하지 않다는 것을 의미합니다.

따라서 기본적으로 모든 블록에 대해 일반적인 방식으로 부모 선택 인터페이스를 구축하는 것이 좋지만 블록이 소품을 사용하도록 선택할 수 있습니다.

Jetpack Form 블록을 구축 할 때 이와 같은 것을 선택할 수 있다면 좋았을 것입니다.

또한 문제가 될 수도 있고 아닐 수도있는 일대일 편집 /보기 패리티에서 더 멀리 밀어냅니다.

나는 이것이 선택된 상태와 선택되지 않은 상태 사이에 약간의 변화를 가져도 좋다고 생각합니다.

또한 3 개 깊이로 중첩 된 블록이 있으면 어떻게됩니까? 두 번째 수준이 부모 블록 인 경우 패딩 옵션이 두 번째 수준으로 확장됩니까?

@mapk

또한 3 개 깊이로 중첩 된 블록이 있으면 어떻게됩니까? 두 번째 수준이 부모 블록 인 경우 패딩 옵션이 두 번째 수준으로 확장됩니까?

영향을받는 모든 수준의 중첩의 패딩은 깊이 중첩 된 블록을 선택할 때 일부 큰 크기 증가 및 감소를 초래할 수있는 것처럼 들립니다 (예 : 섹션의 행에있는 열의 인용문에있는 단락). 이상적으로는 블록을 선택하는 것이 다른 모든 블록의 모양을 크게 변경해서는 안되므로 직계 부모의 간격을 변경하는 것만으로도 충분 해 보입니다.

직계 상위를 선택할 수있는 한 상위를 선택하면 상위를 쉽게 선택할 수있게되는 등의 방식으로 상위 계층에서 작업 할 수 있습니다. 블록 탐색 메뉴는 더 빠른 액세스를 위해 사용될 수 있으며, 일부 사람들이 이전에 제안했듯이 고정 가능한 사이드 바로 만들어서 빠르게 액세스 할 수 있습니다. (# 11408 및 # 11688 참조.)

패딩 변경은 선택한 블록과 직계 하위 항목에만 영향을 주어야합니다.

이것이이 작업에 영향을 미칠 경우를 대비하여 Columns Block에 Vertical Alignment를 추가하려는 작업이 _individual_ Columns를 선택 가능하게 만든다 (이전에는 선택할 수 없었 음).

https://github.com/WordPress/gutenberg/pull/13899

Columns Block에 수직 정렬을 추가하기 위해 착륙하려는 작업은 _individual_ Columns를 선택 가능하게 만듭니다 (이전에는 선택할 수 없었습니다)

여기에 주목 해 주셔서 감사합니다. 이것이이 상호 작용을 조만간 정리해야하는 이유입니다.

블록 테두리와 관련하여 오늘 일찍 @jasmussen 과 논의한 내용을 공유하고 싶었습니다.

이것은 위의 일부 모형 에서

이 예에서는 초점이 맞춰진 상태에 어두운 테두리를 사용하고 있습니다. 블록이 부모 또는 자식 블록 인 경우 다른 관련 항목 주위에 점선으로 된 밝은 테두리 (추가 패딩 포함)를 포함했습니다. 이를 통해 사용자는 블록 계층 구조에서 자신이 어디에 있는지 명확하게 시각화하고 다른 중첩 블록을 선택하기 위해 클릭 할 수있는 위치를 명확하게 파악할 수 있습니다.

@kjellr 정말 좋아요. 그것은 구조가 무엇인지 매우 명확하게 만듭니다.

그러나… 나는 우리가 다시 점선의 대비 문제에 부딪 힐 것이라고 생각한다. 확실하게 말할 수는 없지만 점선 도입은 접근성 기준을 따라야한다는 것을 의미합니다. 그리고 훨씬 더 높은 대비를 만드는 것은 아마도 이점을 무효화 할 수있는 시각적 인 무거움을 유발할 것이라고 생각합니다.

그냥 큰 소리로 생각하고 있습니다. 시력이 좋은 사용자로서의 외모가 정말 마음에 들지만, 내 마음에 드는 피드백만으로는 충분하지 않습니다. :)

내 화면에는 처음에는 점선도 보이지 않았습니다. 내 화면이 약간 기울어지면 거의 보이지 않습니다.

접근성이 떨어질 경우 대비를 낮출 필요가 없습니다. _little_ 라이터이고 다른 border-style 사용하는 한 잘 작동 할 것이라고 생각합니다.

죄송합니다. 원래 댓글에서 더 명확해야했습니다. Joen과 이야기하는 동안 몇 분 만에 모형을 만들었습니다. 당시 화면에 있던 회색에서 무작위로 색상을 선택했다고 생각합니다. 😄 정확한 음영은 최종 솔루션을 전달하는 것이 아니라 일반적인 접근 방식입니다.

부모 블록에 패딩을 추가하여 내부 블록이 프런트 엔드 (# 14148 # 14169)와 일치하지 않게하는 것에 대한 우려에 대한 응답으로 다른 아이디어를 작업했습니다.

이를 위해서는 더 많은 개발이 필요하지만 좋은 옵션이 될 수 있습니다.

기본적으로 부모 블록을 클릭하면 확장 (일반 블록보다 커짐)하여 자식 / 부모 선택을 쉽게하는 데 필요한 패딩을 제공합니다. 이렇게하면 내부 블록이 프런트 엔드와 일관되게 시각적으로 유지됩니다.

스크린 캐스트

InVision 프로토 타입

https://wp.invisionapp.com/share/EGQRWRC8MFT

장점

1. 내부 블록은 적절한 너비로 유지됩니다.
2. 내부 블록은 시각적으로 프런트 엔드와 일관성을 유지합니다.
3. 선택한 블록 크기 변경은 이미 사용 된 패턴입니다.

단점

1. 블록 선택 (너비)을 일반 블록 선택 이상으로 확장하는 것은 새로운 패턴입니다.
2. 블록이 전체 너비로 설정되었을 때 이것이 어떻게 작동하는지 잘 모르겠습니다.

기본적으로 부모 블록을 클릭하면 확장 (일반 블록보다 커짐)하여 자식 / 부모 선택을 쉽게하는 데 필요한 패딩을 제공합니다. 이렇게하면 내부 블록이 프런트 엔드와 일관되게 시각적으로 유지됩니다.

그것을 파십시오. 블록 도구 모음이 왼쪽 테두리와 같은 높이를 유지하고 싶지만 이것이 구현 세부 사항입니다.

실제로 더 커질 수없는 작은 화면에서는 도전이 될 것이지만, 해결 가능한 것처럼 느껴집니다.

특히 이러한 접근 방식은 내부 블록이있는 _any_ 블록으로 확장 될 수있는 것처럼 느껴집니다. 심지어는 선택이 가능한 한 방해받지 않아야하는 기본 텍스트 블록 인 Quote 블록도 마찬가지입니다.

정말로, 정말로 당신의 작업을 파헤쳐 라, Kjell – 그것은 Mark의 아이디어로 보이지 않게 작동 할 수있을뿐만 아니라, _ 필요할 때 _ 문서의 구조를 강조하는 데 도움이되지만, 작성하고 싶을 때 흐름을 깨뜨리지 않습니다. 확실한 방향으로 느껴지고, 우리에게 필요한 것은 다음에 대한 강력한 개발자입니다.

구현 참고 사항에서-점선 부모는 이론적으로 선택한 블록과 동일한 색상을 가질 수 있지만 점선으로 인해 여전히 보조로 표시됩니다. 부모를 가리킬 때 윤곽선이 단색이 될 수 있으며, 클릭 할 때 일어날 일을 나타 내기 위해 _child_ (마우스를 가리킬 때 선택한 것)를 파선으로 만들 수도 있습니다.

구현 참고 사항에서-점선 부모는 이론적으로 선택한 블록과 동일한 색상을 가질 수 있지만 점선으로 인해 여전히 보조로 표시됩니다. 부모를 가리킬 때 윤곽선이 단색이 될 수 있으며, 클릭 할 때 일어날 일을 나타 내기 위해 _child_ (마우스를 가리킬 때 선택한 것)를 파선으로 만들 수도 있습니다.

예! 나는 그것도 완전히 작동 할 수 있다고 생각한다. # 14145가 어디로 가는지보고 거기에서 치료법을 알아 봅시다. 👍

또한 단일 열을 선택 가능하게 만들었을 때 테두리를 수정했지만 PR 범위를 벗어난 것으로 제거되었습니다. 분명히 UX 개선처럼 느껴졌습니다. 이것이 향하는 방식을 사랑합니다!

참고 : 위의 아이디어 를 탐색을위한 별도의 간결한 문제로 전환하고 있습니다. 여기를 따르십시오.

https://github.com/WordPress/gutenberg/issues/14935

누구든지 자녀가 선택되었을 때 부모 블록에 has-child-selected 클래스를 추가하기 위해 참여할 수 있다면 이것이 시작하는 데있어 유일한 차단기입니다.

새로 도입 된 그룹 블록을 테스트 한 후 발견 한 관련 문제 :

현재 혼란스러운 점은 그룹 블록을 삽입 할 때 실제로 보이는 것이 단락 블록이라는 것입니다.

적어도 다음과 같이 할 수 있습니까?

또는 @mtias 가 블록 탐색 기능을 재사용하여 비공개 채팅에서 제안한 내용 :

_ 그것들은 결코 최종 디자인 제안이 아닙니다 😃_

@gziolo 그 문제는 # 14241로 해결 될 예정입니다. 나는 당신과 동의합니다, btw, 그래서 곧 그것을 발송하게되어 좋을 것입니다 :)

@gziolo 그 문제는 # 14241로 해결 될 예정입니다. 나는 당신과 동의합니다, btw, 그래서 곧 그것을 발송하게되어 좋을 것입니다 :)

음, 부분적으로 말할 것입니다. 이 새로운 사용자 정의 삽입기를 사용하여 단락을 삽입하면 다시 원점으로 돌아갑니다 🤷‍♂️

# 14935가 여기서도 도움이 될 것 같습니다. 또한 현재 선택된 블록이 중첩되도록하는 더 많은 방법을 가지려면 사이드 바에서 몇 가지 옵션을 탐색해야합니다.

아 예. 나는 우리가 여기에서했던 것처럼 사이드 바의 이동 경로를 부활시키는 것에 대해 생각하고 있습니다.

https://github.com/WordPress/gutenberg/issues/13309#issuecomment -458452168

단순하고 비교적 우아하며이 문제 (9628)에도 도움이됩니다.

위의 아이디어 중 일부에 대한 반복을 던집니다.

블록 변형 / 스타일을 전용 항목으로 이동하고 블록 아이콘을 자체 "블록 트리"패널로 만들면 어떨까요?

블록 변환 / 스타일의 가시성을 높이고 사람들이 다른 중첩 된 블록으로 좀 더 명확하게 이동할 수 있도록 도와 줄 수 있다고 생각합니다. 다음은 더 복잡한 예제의 모형입니다.

(두 컴포지션 모두 # 14961의 윤곽선 / 패딩을 사용합니다.)

매우 흥미로워 보이는 Kjell! 그런 다음 블록 탐색 영역과 연결되어 둘 사이의 일관성을 만듭니다. 블록 탐색을 사용하는 방법을 배우면 동일한 학습이 중첩 된 블록을 계속 선택할 수 있습니다.

나는 개념적 수준에서 목업을 정말 좋아하지만 실행에 대한 무언가가 약간 조밀하다고 느낍니다. 필연적으로 더 나은 아이디어가 있는지는 모르겠지만, 좀 더 가볍게 느낄 수있는 방법이 있는지 궁금합니다.

블록 구조의 빠른 개요를 찾는 데 어려움을 겪었다는 것을 알고 있으므로이 개념은이 문제를 해결하는 데 좋은 아이디어입니다.

여기서 내 관심사는 @chrisvanpatten과 유사합니다. 잘 생각했지만 많은 것 같습니다.

1. 특정 컨텍스트의 일부 블록에는 드롭 다운을 표시하는 다양한 방법이 있습니다.

믹스에 다른 쉐브론을 추가하면 (회색이고 오른쪽을 향하지만) 구문 분석이 더 어려워 질 수 있습니다.

1. 다른 문제는 도구 모음이 길어지고 있다는 것입니다. 큰 문제는 아니지만 https://github.com/WordPress/gutenberg/issues/10524 및 https://github.com/WordPress/gutenberg/issues/ 아이콘에 대한 레이블을 포함 할 수 있습니다.

이것을 탐구하는 동안 숙고해야 할 몇 가지 생각. 이것은 진행 상황을 전달하는 가장 간단한 접근 방식 일 수 있습니다.

좀 더 가볍게 느낄 수있는 방법이 있는지 궁금합니다.

네, 계층 구조가 부족한 것과 관련이 있다고 생각합니다. 첫 번째 도구 모음 항목은 접지 요소와 좀 더 비슷하고 다른 항목은 블록의 보조 옵션처럼 느껴야합니다. 어떤 종류의 분리가 필요합니다. 이것은 올바른 해결책은 아니지만 대화를 위해서 조금만 도움이된다고 생각합니다.

특정 컨텍스트의 일부 블록에는 드롭 다운을 표시하는 다양한 방법이 있습니다. 믹스에 다른 쉐브론을 추가하면 (회색이고 오른쪽을 향하지만) 구문 분석이 더 어려워 질 수 있습니다.

그럴 수도 있습니다. 내가 생각하지도 않는 이것을 표현하는 또 다른 방법이있을 것입니다. 솔직히 말하면 툴바에있는 더 간단한 추가 "블록 트리"아이콘이 될 수 있으며, 부모 또는 자식 요소에 대해 자동으로 추가됩니다.

다른 문제는 도구 모음이 길어지고 있다는 것입니다. 큰 문제는 아니지만 아이콘 # 10524 및 # 15311에 대한 레이블을 포함 할 수 있습니다.

동의합니다. 이것이 방향이든 아니든, 어쨌든 매우 긴 도구 모음에 대한 솔루션을 정렬해야합니다. 내가 좋아하는 노력을 생각 https://github.com/WordPress/gutenberg/pull/16557 등의 도구 모음 계층 구조의보다 포괄적 인 rethinks 같이 수행이 도움이 조금 https://github.com/WordPress/gutenberg/issues/ 15096.

도구 모음 버튼으로서의 블록 트리 아이디어에 대해 저를 놀라게하는 한 가지는 블록 자체에 대한 본질적인 어떤 것도 참조하지 않고 블록이 어떻게 관련되는지에 대해 참조하는 블록 도구 모음 항목이라는 점에서 독특하다는 것입니다. 문서의 나머지.

그것은 다른 무엇보다 더 많은 생각을하고 있지만, 그래픽 앱의 비유를 사용하기 위해 이러한 유형의 "레이어링"및 "그룹화"UI는 일반적으로 _document_ 수준에서만 존재합니다. 블록 수준에서 액세스 할 수있는 것보다.

블록과 문서 수준 도구 사이의 "간격"과 관련하여 다양한 접근성 문제가 있다는 것을 알고 있으며이를 블록 수준에두면 탐색이 더 쉬워 질 수 있습니다.

이것은 무엇보다 더 많은 생각을하게됩니다.이 도구는 도구 모음에서 사용 가능한 다른 도구와 블록을 다른 컨텍스트와 연결하는 방식이 상당히 다릅니다.

이것은 무엇보다 더 많은 생각을하게됩니다.이 도구는 도구 모음에서 사용 가능한 다른 도구와 블록을 다른 컨텍스트와 연결하는 방식이 상당히 다릅니다.

그래, 나도 같은 느낌이야.

우리는 지금 상단 툴바에 그 컨트롤을 가지고 있는데, 이것은 블록 자체에서 너무 멀리 떨어져있는 것처럼 보입니다. 사이드 바가 실제로 가장 좋은 장소일까요? 컨트롤은 거의 블록과 연결되어야하는 것처럼 보이지만, 별도의 도구 모음으로 표시되지만, 다른 도구 모음을 추가하고 싶지는 않습니다. 😄

우리는 지금 상단 툴바에 그 컨트롤을 가지고 있는데, 이것은 블록 자체에서 너무 멀리 떨어져있는 것처럼 보입니다.

나는 또한 이것이 구텐베르크의 기본 설정에서만 사실이라고 덧붙일 것입니다. 누군가가 상단 도구 모음 옵션을 선택하여 모든 블록 도구 모음을 상단 도구 모음으로 이동했다면, 이는 확실히 그렇지 않습니다. 하지만 대부분의 사용자가 해당 설정을 변경하는 것은 의심 스럽습니다.

또 다른 메모에서 사람들이 Gutenberg의 기본 설정 인 Top Toolbar 설정에 어떻게 반응하는지보고 싶습니다. 새로운 Gutenberg 사용자에게 더 친숙한 기능을 제공하는 Classic 편집기와 더 잘 어울립니다.

이 도구 모음 설정은 많이 탐색되었으며, 약간의 테스트 후에 최상의 기본값이 정해졌습니다. 탐색에 대한 자세한 내용은 https://github.com/WordPress/gutenberg/issues/2983 에서 확인할 수 있습니다

대부분의 사용자가 해당 설정을 변경하지 않을 수 있습니다.

툴바의 위치는 엄청나게 개인적인 설정입니다. 테스트에서 1 단계에서 WordPress를 사용하기 시작한 사람들이 블록에서 선호하는 것으로 나타났습니다. 도구 모음은 두 곳 모두에서 기본 설정되어 있으며 현재 우리가 가진 것이 최상의 옵션입니다. 또한 이것이 아마도 클래식 편집기에 더 잘 어울리는 이유 일 것입니다. 개인적으로 기본값을 변경하지 않는 것이 좋습니다.

@jasmussen 우리는 # 17088에 찬성하여 이것을 닫을

네, 할 수 있다고 생각합니다. 이 티켓은 다양하게 탐색했지만 다른 티켓은 이제 일부 아이디어를 구체화합니다. 이 티켓은 새 티켓 Thanks Riad의 참조를 따르면 여전히 찾을 수 있습니다.