툴팁은 발생할 수 있는 가장 작은 UI 문제처럼 느껴집니다. 그것들은 작고 대개 숨겨져 있습니다. 누군가가 빌드 방법을 묻는다면 전통적인 대답은 거의 항상 일부 JavaScript 라이브러리를 사용하여 돌아옵니다. 그리고 오랫동안 그것은 합리적인 조언이었습니다. 나도 그것을 따랐다. 표면적으로 툴팁은 간단합니다. 요소에 마우스를 올리거나 초점을 맞추고 텍스트가 포함된 작은 상자를 표시한 다음 사용자가 다른 곳으로 이동하면 숨깁니다. 그러나 실제 사용자에게 제품을 제공하면 가장자리가 보이기 시작합니다. 키보드 사용자 탭으로 트리거를 실행하면 도구 설명이 표시되지 않습니다. 스크린 리더는 이를 두 번 알리거나 전혀 알리지 않습니다. 마우스를 너무 빨리 움직이면 툴팁이 깜박입니다. 작은 화면에서는 콘텐츠가 겹칩니다. Esc를 눌러도 닫히지 않습니다. 초점이 흐려집니다. 시간이 지남에 따라 내 툴팁 코드는 더 이상 소유하고 싶지 않은 코드로 성장했습니다. 이벤트 리스너가 쌓여 있습니다. 호버와 포커스는 별도로 처리해야 했습니다. 외부 클릭에는 특별한 경우가 필요했습니다. ARIA 속성은 수동으로 동기화를 유지해야 했습니다. 작은 수정이 있을 때마다 또 다른 논리 레이어가 추가되었습니다. 라이브러리가 도움이 되었지만, 뒤에서 무슨 일이 일어나고 있는지 완전히 이해하기보다는 제가 작업한 블랙박스에 더 가까웠습니다. 이것이 제가 최신 Popover API를 보게 된 계기였습니다. 라이브러리의 도움 없이 브라우저의 기본 모델을 사용하여 단일 도구 설명을 다시 작성하면 어떤 일이 발생하는지 확인하고 싶었습니다. 시작하면서 다른 새로운 기능과 마찬가지로 아직 해결되지 않은 사항이 있다는 점에 주목할 필요가 있습니다. 즉, 전체 API에는 유동적인 여러 부분이 있지만 현재는 훌륭한 브라우저 지원을 누리고 있습니다. 그동안 Caniuse를 지켜볼 가치가 있습니다. "기존" 툴팁 Popover API 이전에는 툴팁 라이브러리를 사용하는 것이 지름길이 아니었습니다. 기본값이었습니다. 브라우저에는 마우스, 키보드 및 보조 기술 전반에 걸쳐 작동하는 도구 설명이라는 기본 개념이 없었습니다. 정확성에 관심이 있다면 유일한 선택은 라이브러리를 사용하는 것이었고, 제가 바로 그렇게 했습니다. 높은 수준에서 패턴은 항상 동일했습니다. 즉, 트리거 요소, 숨겨진 도구 설명 요소 및 이 둘을 조정하는 JavaScript였습니다.
라이브러리는 요소를 가리키거나 초점을 맞추면 표시하고, 흐리게 표시하거나 마우스를 놓으면 숨기고, 스크롤할 때 위치를 변경하거나 크기를 조정할 수 있도록 하는 배선을 처리했습니다.
시간이 지남에 따라 도구 설명이 깨지기 쉬워질 수 있습니다. 작은 변화에는 위험이 따릅니다. 사소한 수정으로 인해 회귀가 발생했습니다. 더 나쁜 것은 새로운 도구 설명을 추가하면 동일한 복잡성이 상속된다는 것입니다. 기술적으로는 효과가 있었지만 결코 안정되거나 완전하다고 느껴지지 않았습니다. 브라우저의 기본 Popover API를 사용하여 툴팁을 다시 작성하기로 결정했을 때의 상황이었습니다. Popover API를 사용해본 순간 새로운 것을 실험하고 싶었기 때문에 Popover API를 사용하도록 전환한 것은 아닙니다. 브라우저가 이미 이해했어야 한다고 믿었던 툴팁 동작을 유지하는 데 지쳤기 때문에 전환했습니다. 처음에는 회의적이었습니다. 대부분의 새로운 웹 API는 단순성을 약속하지만 여전히 탈출하려는 것과 동일한 복잡성을 조용히 재현하는 글루, 엣지 케이스 처리 또는 폴백 논리가 필요합니다. 그래서 최대한 작은 방법으로 Popover API를 사용해보았습니다. 그 모습은 다음과 같습니다.
1. 키보드는 "제대로 작동합니다" 키보드 지원은 올바르게 정렬된 여러 레이어에 달려 있습니다. 초점은 툴팁을 트리거해야 하고, 블러는 이를 숨겨야 하며, Esc는 수동으로 연결해야 하고 타이밍이 중요했습니다. 하나의 극단적인 사례를 놓친 경우 도구 설명은 너무 오랫동안 열려 있거나 읽을 수 있기 전에 사라집니다. 팝오버 속성이 자동 또는 수동으로 설정되면 브라우저가 기본 사항을 대신합니다. Tab 및 Shift+Tab은 정상적으로 작동하고 Esc는 매번 도구 설명을 닫으며 추가 리스너가 필요하지 않습니다.
내 코드베이스에서 사라진 것은 전역 키다운 처리기, Esc 관련 정리 논리, 키보드 탐색 중 상태 확인이었습니다. 키보드 경험은 내가 유지해야 하는 것이 아니라 브라우저 보증이 되었습니다. 2. 스크린리더 예측 가능성 이것은가장 큰 개선. 앞서 설명한 것처럼 신중한 ARIA 작업을 수행하더라도 동작은 다양했습니다. 작은 변화 하나하나가 위험하게 느껴졌습니다. 적절한 역할과 함께 팝오버를 사용하면 앞으로 일어날 일에 대해 훨씬 더 안정적이고 예측 가능해 보이고 느껴집니다.
그리고 또 다른 장점이 있습니다. 전환 후 Lighthouse는 상호 작용에 대한 잘못된 ARIA 상태 경고 플래그 지정을 중단했습니다. 주로 실수로 잘못될 수 있는 사용자 정의 ARIA 상태가 더 이상 없기 때문입니다.
3. 집중관리 예전에는 초점이 약했습니다. 이전에는 포커스 트리거에서 도구 설명 표시, 포커스를 도구 설명으로 이동하고 닫지 않음, 너무 가까우면 흐림 트리거, 도구 설명을 닫고 수동으로 포커스 복원과 같은 규칙이 있었습니다. 이것은 작동하지 않을 때까지 작동했습니다. Popover API를 사용하면 브라우저는 포커스가 팝오버로 더 자연스럽게 이동할 수 있는 간단한 모델을 적용합니다. 팝오버를 닫으면 포커스가 트리거로 돌아가고 보이지 않는 포커스 트랩이나 포커스 손실 순간이 없습니다. 그리고 포커스 복원 코드를 추가하지 않았습니다. 나는 그것을 제거했다.
결론 Popover API는 도구 설명이 더 이상 시뮬레이션할 수 없음을 의미합니다. 브라우저가 이해하는 것입니다. 열기, 닫기, 키보드 동작, 이스케이프 처리 및 접근성의 상당 부분이 이제 임시 JavaScript가 아닌 플랫폼 자체에서 나옵니다. 그렇다고 툴팁 라이브러리가 복잡한 디자인 시스템, 과도한 사용자 정의 또는 레거시 제약 조건에 여전히 적합하기 때문에 더 이상 사용되지 않는다는 의미는 아니지만 기본값이 바뀌었습니다. 처음으로 가장 간단한 툴팁이 가장 정확한 툴팁이 될 수도 있습니다. 궁금하다면 이 실험을 시도해 보세요. 제품의 툴팁 하나만 Popover API로 바꾸고, 모든 것을 다시 작성하지 말고, 전체 시스템을 마이그레이션하지 말고, 하나만 선택하여 코드에서 무엇이 사라지는지 확인하세요. 플랫폼이 더 나은 기본 요소를 제공하면 JavaScript 줄이 줄어들 뿐만 아니라 걱정해야 할 사항도 줄어듭니다. 내 GitHub 저장소에서 전체 소스 코드를 확인하세요. 추가 자료 팝오버 및 관련 API에 대해 더 자세히 알아보려면:
팝핀인', 제프 그레이엄 "팝오버와 대화상자의 관계를 명확히 하기", Zell Liew “팝오버=힌트란 무엇입니까?”, Una Kravets "호출자 명령", Daniel Schwarz "HTML 팝오버를 사용하여 자동 종료 알림 만들기", Preethi 오픈 UI 팝오버 API 설명 “풍선 터뜨리기”, 존 레아 “CSS 앵커 위치 지정”, Juan Diego Rodríguez
MDN은 Popover API에 대한 포괄적인 기술 문서도 제공합니다.
