Resize Handle
크기 조절 핸들
크기 조절 핸들은 모서리나 구석에 있는 작은 조절하는 부분이에요. 여기를 끌어서 패널, 입력칸, 줄, 물건 등의 크기를 바꿔요.
Drag the handle, or use Left and Right Arrow keys.
실제 예시
분할된 편집기는 잡기 좋은 넓은 구분선이 있어. 사용자가 끌면 양쪽 패널 크기가 같이 바뀌어.
주요 부분
- 01시각적 레이블
- 02Interaction target
- 03Current state
- 04Keyboard behavior
사용할 때
사람들이 공간을 직접 나눌 필요가 있고 합리적인 크기 제한을 설정할 수 있을 때 사용하십시오.
다음 경우에는 사용하지 마세요
작은 표시나 보이지 않는 타겟을 절대 사용하지 마세요. 크기 조정에도 제한과 키보드 옵션이 필요합니다.
코드에서 사용된 이름
resize / separator handle 출시하기 전에
Give assistive tools the control’s name (accessible name), purpose (role), value, and state. Check keyboard use, visible focus, target size, disabled and busy states, feedback, and recovery.
Outcome：Complete the task with 크기 조절 핸들 (Resize Handle)。 User context：분할된 편집기는 잡기 좋은 넓은 구분선이 있어. 사용자가 끌면 양쪽 패널 크기가 같이 바뀌어. Recommended pattern：크기 조절 핸들 (Resize Handle)。 Why it fits：사람들이 공간을 직접 나눌 필요가 있고 합리적인 크기 제한을 설정할 수 있을 때 사용하십시오. Do not use it when：작은 표시나 보이지 않는 타겟을 절대 사용하지 마세요. 크기 조정에도 제한과 키보드 옵션이 필요합니다. Product requirements: Define the default, loading, empty, error, success, and recovery states. Keep user input. Give clear feedback after every action. Accessibility and resilience: Use semantic HTML, full keyboard access, and visible focus. Make the layout work when zoomed and support reduced motion. Follow the project’s current rules. Do not add a new UI library unless the project already uses it. Acceptance criteria: The main task works with keyboard only and at 320px width. Focus and status changes are announced. Check loading, failure, retry, cancel, and reduced-motion paths. Evidence and limits (evidence boundary)：공식 문서라고 해도 초안, 출시 후보, 최종 버전일 수 있어요. 상태와 브라우저나 플랫폼 지원 여부를 꼭 확인하세요. Unknowns to confirm: Product wording, data source, analytics events, supported devices and languages, and platform limits.
이 요청을 확인하세요
Review how 크기 조절 핸들 (Resize Handle) is used now. Definition: 크기 조절 핸들은 모서리나 구석에 있는 작은 조절하는 부분이에요. 여기를 끌어서 패널, 입력칸, 줄, 물건 등의 크기를 바꿔요. Release checks: Give assistive tools the control’s name (accessible name), purpose (role), value, and state. Check keyboard use, visible focus, target size, disabled and busy states, feedback, and recovery. Before changing code, list the evidence, gaps, severity, and the smallest safe fix.