HTML의 숨은 기능: JavaScript 없이 dialog·popover·details 활용하기

네이티브 HTML이 다시 주목받는 이유

Hacker News에서 화제가 된 'HTML Can Do That' 논의는 브라우저가 제공하는 기능을 애플리케이션 코드로 중복 구현하는 문제를 짚습니다. 작은 코드가 언제나 좋은 것은 아니지만 표준 기능은 키보드와 보조기기 동작을 함께 제공하는 경우가 많습니다.

dialog와 popover의 차이

dialog는 사용자의 주의를 묶는 모달 확인창에, popover는 버튼 주변의 보조 정보나 메뉴에 어울립니다. 목적에 맞는 요소를 선택해야 포커스 이동과 닫기 동작이 자연스럽습니다.

details로 만드는 공개·접기 UI

details와 summary는 FAQ나 추가 설명을 접고 펼칠 때 유용합니다. 같은 name을 사용해 그룹 동작을 만들 수 있지만 사용자가 여러 항목을 동시에 비교해야 한다면 하나만 열리는 아코디언이 불편할 수 있습니다.

datalist와 입력 경험

datalist는 자유 입력을 유지하면서 추천 값을 제시합니다. 브라우저와 모바일 환경별 표현 차이가 있으므로 핵심 기능을 datalist에만 의존하지 말고 실제 대상 기기에서 테스트해야 합니다.

React·프론트엔드 적용 순서

• 요구 동작에 맞는 시맨틱 요소를 찾습니다.
• 키보드와 스크린리더로 기본 동작을 확인합니다.
• CSS로 시각 디자인을 맞춥니다.
• 부족한 상태와 비동기 처리만 JavaScript로 보완합니다.

편집부 분석: 삭제한 코드도 성과다

네이티브 HTML 전환은 번들 크기뿐 아니라 키보드 접근성 결함, 포커스 버그, 테스트 수와 유지보수 시간을 전후로 비교해야 합니다. React 컴포넌트를 한 번에 교체하기보다 FAQ의 details처럼 상태가 단순한 영역부터 전환하는 것이 안전합니다.

기능별 선택 기준 한눈에 보기

표준 요소를 쓴다는 이유만으로 접근성이 자동 완성되지는 않습니다. 제목과 레이블, 오류 메시지, 포커스 순서를 실제 키보드로 확인하고 주요 브라우저에서 기능이 지원되지 않을 때도 핵심 작업을 완료할 수 있어야 합니다.

자주 묻는 질문

네이티브 HTML이면 JavaScript가 필요 없나요?

아닙니다. 표준 동작은 HTML로 처리하고 복잡한 데이터와 상태 로직에 JavaScript를 사용하면 됩니다.

모든 브라우저에서 똑같이 보이나요?

지원 범위와 기본 스타일이 다를 수 있어 호환성 표와 실제 기기 테스트가 필요합니다.

React에서도 dialog를 써도 되나요?

가능합니다. 컴포넌트 상태와 DOM 메서드의 역할을 명확히 나누고 포커스를 테스트하세요.