그것을 위해 JavaScript가 필요 없습니다

 (htmhell.dev)
3P by GN⁺ | ★ favorite | 댓글 1개
  • 웹 기능 구현은 HTML, CSS, JavaScript 순으로 덜 강력한 기술을 먼저 검토하는 편이 로딩 실패와 접근성 문제를 줄이는 데 유리함
  • JavaScript는 브라우저 동작을 직접 제어할 수 있지만, 추가 리소스와 오류 가능성 때문에 키보드·보조 기술 사용자를 배제하기 쉬움
  • 과거 JavaScript가 필요했던 체크박스 스위치, datalist, input type="color", details/summary, dialog 같은 기능이 이제는 HTML/CSS 기본 기능으로 상당 부분 가능해짐
  • HTML과 CSS의 선언적 기능은 브라우저가 네이티브 동작, 사용자 환경 설정, 접근성 대응을 맡을 수 있어 더 나은 기본값을 제공할 수 있음
  • 익숙한 JavaScript 구현이 계속 동작하더라도 최신 HTML/CSS 대안을 주기적으로 확인하고, 바꿀 때는 접근성 테스트를 함께 해야 함

최소 권한의 규칙

  • 최소 권한의 규칙은 목적을 달성할 수 있는 가장 덜 강력한 언어를 선택하라는 웹 개발 원칙임
  • 웹에서는 보통 HTML을 CSS보다, CSS를 JavaScript보다 먼저 고려하는 방식으로 적용됨
  • JavaScript는 세 기술 중 가장 다재다능하지만 그만큼 부담도 큼
    • 깨질 수 있음
    • 로드에 실패할 수 있음
    • 다운로드, 파싱, 실행에 추가 리소스가 필요함
    • 키보드 사용자와 보조 기술 사용자를 배제하기 쉬움
  • HTML과 CSS는 명령형 JavaScript와 달리 선언적으로 동작함
    • 개발자는 브라우저에 무엇을 원하는지 알리고, 구현 방식은 브라우저가 선택함
    • 브라우저가 더 효율적인 처리 방식을 고를 수 있음
  • 브라우저가 HTML/CSS 기능을 처리하면 성능, 네이티브 동작, 사용자 환경 설정 대응, 접근성 면에서 유리할 수 있음
    • 다만 접근성이 항상 자동으로 보장되는 것은 아님

예전에는 JavaScript가 필요했던 기능들

  • 브라우저 제작자와 명세 작성자는 몇 년 전까지 JavaScript가 필요했던 기능을 CSS와 HTML로 옮겨 왔음
  • 웹은 하위 호환성을 유지하므로, 한 번 익힌 구현 방식이 도구상자에 남아 반복 사용되기 쉬움
  • 어떤 기능에 JavaScript가 필요하다고 알고 있더라도 지금도 그런지 가끔 확인하면 더 나은 웹사이트를 만들 수 있음

체크박스로 만드는 커스텀 스위치

  • 커스텀 스위치는 div, onclick 핸들러, 내부 상태 대신 기본 체크박스와 CSS로 구현할 수 있음
  • <label> 안에 <input type="checkbox">를 넣으면 브라우저가 둘을 연결함
    • 라벨 어디를 클릭해도 체크박스가 토글됨
    • 별도 onclick 핸들러가 필요 없음
  • appearance: none은 브라우저 기본 폼 컨트롤 렌더링을 멈추고 직접 스타일링할 수 있게 함
    • input 자체를 스위치 배경처럼 꾸밀 수 있음
    • ::before를 토글되는 내부 점으로 사용할 수 있음
  • :checked 의사 클래스는 체크 상태에 따라 배경색과 ::before 위치를 바꿀 수 있음
  • 키보드 사용자를 위해 포커스 표시가 필요함
    • outline: none으로 포커스를 숨기는 방식은 좋지 않음
    • :focus-visible은 키보드 상호작용 때만 보기 좋은 포커스 링을 표시할 수 있음
    • outline-offset으로 포커스 윤곽선을 요소 바깥이나 안쪽으로 조정할 수 있음
  • input:focus { outline-color: transparent; }는 일반 상황에서는 윤곽선을 투명하게 만들고, 고대비 모드에서는 사용자가 선택한 색으로 다시 보이게 할 수 있음
  • 강제 색상 모드는 forced colors explained에서 더 볼 수 있음

datalist로 만드는 네이티브 자동완성

  • datalist는 사용자가 입력하는 동안 옵션 목록을 보여주는 브라우저 내장 자동 제안 기능임
  • 구성은 단순함
    • datalist 요소에 id와 여러 option을 넣음
    • input의 list 속성으로 해당 datalist와 연결함
  • 사용자가 입력하면 브라우저가 드롭다운을 표시하고, 입력 내용에 맞게 옵션을 자동 필터링함
  • 기본 입력 필드이므로 목록에 없는 값을 직접 입력할 수도 있음
  • 입력 필드를 선택한 뒤 화살표 키로 목록을 탐색하거나, 브라우저가 추가한 드롭다운 아이콘을 클릭해 전체 옵션을 볼 수 있음

input type="color"의 기본 컬러 피커

  • <input type="color"> 한 줄로 브라우저 네이티브 컬러 피커를 사용할 수 있음
  • 많은 JavaScript로 만든 캔버스 UI와 슬라이더를 대체할 수 있음
  • Chromium 브라우저의 네이티브 컬러 피커는 사이트 내부뿐 아니라 화면 어디에서든 색을 고를 수 있음
  • 모든 사용자가 브라우저 컬러 피커를 쓸 수 있는 것은 아니므로, 일반 텍스트 입력처럼 색을 고르는 다른 방법을 함께 제공하는 편이 좋음

details와 summary로 만드는 아코디언

  • details와 summary 요소는 콘텐츠를 접었다 펼치는 아코디언을 브라우저 기본 기능으로 제공함
  • 기본 동작은 단순함
    • details 안의 내용은 summary를 제외하고 숨겨짐
    • 사용자가 summary를 클릭하면 나머지 내용이 표시됨
  • open 속성은 처음 열린 상태를 지정함
    • 사용자 상호작용 후 고정되는 값이 아니라, 사용자가 열고 닫으면 상태가 바뀜
  • summary::marker로 기본 삼각형 마커를 스타일링할 수 있음
    • 콘텐츠를 이모지 등으로 바꿀 수 있음
    • 배경색, 배경 이미지, 글꼴 크기 등을 조정할 수 있음
    • 많은 CSS 속성은 동작하지 않으며, 완전히 다른 위치로 배치하는 식의 스타일링은 제한됨
  • Safari에서는 ::-webkit-details-marker 의사 요소가 필요함
  • 마커 콘텐츠 변경은 보조 기술이 아코디언을 알리는 방식에 영향을 줄 수 있으므로 details/summary inconsistencies를 참고할 수 있음
  • summary는 클릭 가능하지만 기본적으로 링크처럼 포인터 커서가 나오지 않고 버튼처럼 보이지도 않으므로, hover와 focus 상태를 추가해 클릭 가능성을 드러내야 함

dialog로 만드는 모달

  • alert(), prompt(), confirm()은 사용자에게 알리거나 확인을 받을 수 있지만 메인 스레드를 잠그고 디자인에 맞게 스타일링하기 어려움
  • 직접 다이얼로그를 만들면 접근성 처리가 복잡해짐
    • 포커스를 다이얼로그 안에 유지해야 함
    • 모달임을 알려야 함
    • 사용자가 실수로 빠져나가지 않게 해야 함
    • 매우 높은 z-index를 가진 위젯과 충돌할 수 있음
  • 브라우저의 dialog 요소는 네이티브 다이얼로그를 제공함
  • 현재는 다이얼로그를 열기 위해 JavaScript가 필요함
    • JavaScript 없이 여는 변경이 진행 중이지만 아직 완전히 명세화되거나 구현되지는 않음
    • showModal() 함수로 다이얼로그를 열 수 있음
  • dialog는 top layer에 열림
    • top layer는 HTML과 분리된 새 레이어임
    • 이 레이어의 요소는 z-index와 스태킹 컨텍스트 중첩과 관계없이 항상 위에 표시됨
    • 개념 설명은 MDN의 Top layer를 참고할 수 있음
  • dialog는 기본 닫기 UI를 제공하지 않으므로 직접 UI를 넣어야 함
    • form method="dialog"가 제출되면 브라우저가 다이얼로그를 닫음
    • 두 개의 제출 버튼에 서로 다른 value를 넣으면 확인 다이얼로그처럼 사용할 수 있음
    • close 이벤트에서 dialog.returnValue를 읽어 사용자가 누른 버튼 값을 확인할 수 있음
    • 추가 폼 데이터는 FormData로 읽을 수 있음
  • dialog::backdrop은 다이얼로그와 나머지 페이지 사이의 레이어임
    • 배경을 어둡게 하거나 흐리게 해 사용자의 주의를 다이얼로그로 유도할 수 있음
    • 브라우저가 배치하므로 스크롤, 고정 요소, 브라우저 크기 변경을 직접 처리할 필요가 없음

더 적은 JavaScript로 가능한 기능들

  • JavaScript를 줄일 수 있는 기능은 더 많음
    • scroll-behavior: smooth를 이용한 네이티브 부드러운 스크롤
      • prefers-reduced-motion: no preference가 맞을 때만 사용하는 조건이 붙음
    • scroll-snap을 이용한 네이티브 캐러셀
    • position: sticky를 이용한 “in-view” 요소
    • 컨테이너 쿼리
  • 앞으로 추가될 기능도 있음
    • 스크롤 기반 애니메이션
    • masonry.js 없이 grid-template-rows: masonry로 만드는 Masonry 레이아웃
    • 새 selectlist 요소를 통한 완전 스타일링 가능한 select
    • JavaScript 선택 코드의 한 범주를 줄일 수 있는 :has() 선택자
  • 발표 영상 Stop Using JavaScript for That: Moving Features from JS to CSS and HTML.에서 관련 내용을 더 볼 수 있음
  • 기존에 검증된 구현을 새로운 방식으로 바꿀 때는 특히 접근성을 테스트해 누구도 배제하지 않도록 해야 함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 이 글에서 빠진 점은 이런 곳에 JavaScript를 쓰는 이유가 호환성이 더 낫기 때문이라는 것임
    새 JavaScript는 트랜스파일할 수 있지만, 빠진 CSS나 HTML 기능을 폴리필하는 건 훨씬 어렵고 어떤 경우엔 불가능함. 게다가 그 폴리필도 결국 JavaScript를 씀
    appearance는 MDN에서도, appearance: none조차 철저히 테스트하라는 주의가 많음. 최신 브라우저만 지원하면 덜 중요할 수 있지만, 오래된 Safari 버전은 생각보다 오래 남아 있음
    datalist는 Firefox Android에서 아무 기능도 하지 않고, 제겐 제안조차 없는 입력 상자로만 보임
    색상 선택기는 멋지지만 극도로 비표준적이라 대부분의 비즈니스에선 치명적임. 디자이너만 불평하는 게 아니라 고객지원이 사용자를 돕기 어려워짐. Chromium은 페이지에서 집거나 임의 색상을 고르는 기능까지 주지만, Firefox Android는 무지개, 회색, 흑백 정도만 줌
    글 자체도 details와 dialog의 불일치를 인정함. 언젠가 이런 기능을 지원하지 않거나 서로 일관되게 지원하지 않는 브라우저가 더는 쓰이지 않길 바라지만, 당분간 이런 요소들은 지원 브라우저를 완전히 통제할 수 있는 사이드 프로젝트에서나 쓸 듯함

    • 색상 선택기가 비표준적이라는 말에는 동의하기 어려움
      iPhone에서 버튼을 누르면 실제 시스템 네이티브 색상 선택기가 뜸. OS가 제공해서 여러 앱에서 보이는 바로 그 컨트롤이고, 맞춤 제작한 것보다 훨씬 선호함
    • 호환성이 더 낫다는 건 모든 사용자가 JavaScript를 써야 한다는 가정을 깔 때만 맞음
      JavaScript 없는 웹을 훨씬 선호하고, 노트북 배터리 수명에도 몇 시간 단위로 영향을 줌. 어떤 사이트는 이것과 호환되지 않아 빈 페이지만 렌더링하거나 텍스트를 보여주려면 JavaScript가 필요하다고 불평함
      반면 Amazon은 JavaScript 없는 전자상거래 사이트 복제판도 갖고 있어서, 그런 거대한 일도 JavaScript 없이 가능하다는 걸 보여줌
    • dialog 요소는 이제 지원 범위가 꽤 깊고, 2021년대 Firefox나 Safari를 쓰는 몇 퍼센트 사용자를 위한 폴리필도 충분히 괜찮음
      모달을 만든다면 강력 추천하고, 접근성 개선이 훌륭함
    • 고객지원이 사용자를 돕기 어려워진다는 건 큼
      예전 직장에서 이 문제를 적극적으로 논의했고, datalist 같은 것 대신 JS 구현을 쓰기로 했음. 특히 datalist는 시도해 봤지만 결과가 너무 일관되지 않아 버려야 했음
      결국 브라우저 간 불일치 때문에 Chrome 외에는 지원을 중단하기도 했음
    • 아님. JavaScript는 실패하면 완전히 실패해서 콘텐츠 자체가 사라짐
      HTML 예시는 오래된 브라우저에서 모양이 틀릴 수는 있어도 실제 콘텐츠는 남아 있음. JS는 그냥 아무것도 없음. 접근성을 완전히 깨뜨림
      HTML이면 스크린리더가 적어도 읽을 수 있지만, JS로 생성한 콘텐츠는 그걸 막음. JS가 JS를 실행할 수 없을 때는 어떤 폴리필이나 다른 JS도 JS를 구할 수 없음. 처음부터 “작동”해야만 접근성에 괜찮고, 그 경우엔 원래 논점이 무의미해짐

  • Datalist를 몰랐는데, 적어도 Chrome Android에서는 제대로 작동하는 것 같지 않음
    옵션이 자동완성 제안이 뜨는 키보드 영역에 보이긴 함: https://imgur.com/a/Ecb4503
    모바일 웹 UI의 폼 컨트롤에서 그런 방식은 처음 봤고, 비밀번호 자동완성 앱이 같은 공간을 쓰는 경우 말고는 본 적이 없음
    나쁘진 않음. 엉성하게 만든 맞춤 JS 드롭다운을 어색하게 스크롤하는 것보단 훨씬 낫지만, 일반 사용자가 이걸 쓰는 법을 알아낼 거라는 확신이 없음. 그래서 모바일에선 사실상 가망이 없다고 봄
    Firefox Android에서는 아예 지원되지 않음: https://caniuse.com/?search=datalist

    • 브라우저 제작자들, datalist 드롭다운에 스타일 지정 좀 가능하게 해줄 수 없나?
      참고: https://adrianroselli.com/2023/06/under-engineered-comboboxe...
    • 이런 해결책이 널리 자리 잡는 데 오래 걸리는 이유가 이거임
      JavaScript는 꽤 잘 표준화돼 있지만, HTML과 CSS는 상대적으로 덜함
    • input 요소에 autocomplete="off"를 추가하면 동작이 바뀌는지 궁금함
      어쨌든 datalist를 정상적으로 쓰려면 필요함. 그렇지 않으면 값 선택 기록이 드롭다운 목록에 덧붙음. Chromium에서 관찰했음
      또한 기본값이 설정된 경우처럼 어떤 상황에서는 datalist도 여전히 JS가 필요함. 우회책과 브라우저별 특이 동작 메모를 새 LibreOffice 웹사이트 코드에 정리해 둠: https://git.libreoffice.org/infra/libreofficeorg/+/835a5cc59...
      좋은 소식은 Firefox 개발자가 datalist 동작 개선을 살펴볼 계획이라, 한 번 클릭만으로 목록을 표시할 수 있게 될 수도 있음
    • 키보드 위를 봤나?
      제 경우엔 보통 단어 제안이 표시되는 키보드 위 영역에 옵션이 보임
    • datalist 옵션이 키보드 안에 보이는 건 최근 몇 달 사이에 생긴 변화임
      예전에는 “정상적”이었는데, 누군가 바꾸기 위해서만 바꾸고 싶었던 것 같음

  • scroll-behavior: smooth로 네이티브 부드러운 스크롤을 쓰는 건 제발 제한적으로만 써야 함
    생각보다 대부분의 사용처에서 좋은 생각이 아니고, 원치 않는 부작용이 자주 있음
    scroll-snap으로 네이티브 캐러셀을 만든다지만, 캐러셀은 여전히 나쁜 아이디어라 scroll-snap의 정당한 활용 범위는 극히 제한적임
    스크롤 기반 애니메이션을 쓰는 페이지는 대개 그걸 제거하면 더 좋아짐

    • 이 글의 요점은 어떤 디자인 요소를 쓰라고 지시하는 게 아니라, 그런 디자인을 더 사용자 친화적으로 구현하는 방법을 보여주는 것임
      부드러운 스크롤이 좋은 예임. 네이티브 API는 사용자가 언제든 중단할 수 있게 해줌. 대부분의 JS 구현은 끔찍하게 버벅이고 사용자가 고생함
      디자인 선택을 얼마든지 꾸짖을 수는 있지만, “캐러셀은 여전히 나쁘다”는 실제 이유를 제시하지 않으면 귀 기울여지길 기대하긴 어려움
    • 저도 캐러셀을 싫어함
      하지만 Amazon 홈페이지는 캐러셀을 눈에 띄게 쓰고, Amazon은 홈페이지 변형을 가차 없이 A/B 테스트하는 걸로 알고 있음. 그렇다면 캐러셀이 테스트에서 잘 나왔을 가능성이 있고, 어떤 보편적·객관적 의미에서 정말 “나쁘다”고 말하긴 애매함
    • 네이티브 부드러운 스크롤이 왜 대부분의 경우 좋은 아이디어가 아닌가?
      보통 목차 스타일 앵커를 구현한 직후엔 적어도 추가하는 편임
    • 어쨌든 그런 것들에는 JavaScript가 필요 없긴 함

  • 2023년에도 아직 폼과, 사용자가 데이터를 입력하는 일반 UX를 두고 싸우고 있다는 게 놀라움
    datalist와 색상 선택기 관련 댓글만 봐도 그렇고, 왜 아직 해결된 영역이 아닌지 이해가 안 됨
    예전에 XForms로 이걸 한 번에 해결하려는 시도가 있었지만 브라우저에 구현되지 않았음
    대신 거의 모든 CSS/JS 컴포넌트 프레임워크가 서로 다른 의미론을 가진 제한적인 폼 요소 묶음을 각자 제공하고 있음

    • XML 기술을 거부한 결과, 웹은 XML이 제공하던 것의 형편없는 버전을 끝없이 재구현할 운명에 처했음
      우리는 평생 기본 UI 컨트롤을 직접 구현하게 될 듯함
    • 이미 해결돼 있음. React에 넣고 인생을 계속 살면 됨
      “해결되지 않았다”는 건 일부 사람들이 JavaScript를 피하려는 이상한 집착 때문에 반쯤 익은 대안을 억지로 끼워 넣으려 해서 그렇게 보일 뿐임
    • 폼이 “해결됐다”는 게 무슨 뜻일까?
      지루하고 기본적인 기술에 머무를 거라면 이미 해결돼 있음. 하지만 React로 다시 해결하고, React hooks로 또 해결하고, 끝없이 다시 해결하겠다고 고집하면 해결되지 않은 것이 됨
    • CSRF 때문에 사람이 할 수는 있어도 우리가 못 하는 일이 몇 가지 있음
      의도는 프로그램으로 판별할 수 있는 게 아니라서, 어떤 상황에서는 멋진 기능을 가질 수 없음
      마지막으로 작업한 복잡한 폼에서는 브라우저가 허용하도록 클릭 이벤트가 폼 제출을 꽤 직접적으로 발생시키게 만들어야 했음
    • 누군가 어딘가에서는 폼으로 서로 다른 것들을 제출하고 싶어 해서 폼이 해결되지 않은 것임
      웹페이지를 통해 색상을 제출하는 방법을 요청한 적은 없음

  • JavaScript 대신 details를 쓰면 Ctrl+F가 그 안을 검색하고 열어줄 수 있음
    JavaScript 아코디언은 그렇게 열 수 없음

    • hidden="until-found"를 쓰면 JS 기반 아코디언이나 다른 숨김 콘텐츠에서도 가능해지지만, 안타깝게도 지금은 Chromium 기반 브라우저에만 있음: https://developer.chrome.com/articles/hidden-until-found/
    • 검색은 허용하면서 숨길 수 있는 다른 방법이 있나?
    • 문서를 훑다가 비슷한 문제를 방금 겪었음

  • 대부분은 동의하지만, dialog는 충분히 써보지 않아 의견이 없고 datalist는 내부 도구가 아니라면 유효한 선택지가 아니라고 봄
    못생겼고, 할 수 있는 일이 제한적이며, 스타일 지정도 안 됨. “그냥 내장 기능을 쓰라”는 주장 대부분의 문제가 이거임. date picker도 마찬가지
    기본값이 별로일 뿐 아니라 바꾸고 싶어도 바꿀 수 없음. 스타일이나 동작 변경에서 수많은 벽 중 하나에 부딪히면, 예를 들어 주를 월요일부터 시작하고 싶어도 안 됨. 그러면 선택지는 대개 JS를 쓰는 완전 대체 라이브러리뿐임
    더 가벼운 선택지를 쓰는 데 찬성하고 HTML > CSS > JS라는 계층에도 동의하지만, 보기 좋은 UI와 원하는 기능을 모두 갖추려면 때로는 JS가 유일한 답임

    • 검색 제안 상자를 구현하다가 datalist가 도움이 될까 생각했음
      입력한 내용으로 엄격히 시작하지 않는 옵션을 표시하고 싶어지는 순간까지는 잘 작동함. 예를 들어 입력에 오타가 있으면 옵션이 표시되지 않음
      모든 항목을 강제로 표시할 방법이 없어서 결국 순서 있는 목록을 택했음
    • 내장 의미론적 마크업을 JS로 확장하는 방식은 미래 지향적 접근이라는 점을 항상 기억할 만함
      웹 개발을 시작했을 때는 변화에 최대 10년이 걸렸음. IE6도 우리 모두를 붙잡았지만 당시 w3c도 꽤 힘이 없었음. 지금은 변화가 빠름
      내년에는 세 주요 브라우저에서 datalist 스타일 지정이 접두사 없이 가능해질 수도 있지만, 맞춤 JS 해결책에 묶여 있으면 비즈니스가 재구축 비용을 내지 않을 것임
      네이티브 기능을 JS로 확장하면 지원이 충분해졌을 때 낮은 비용으로 JS를 제거할 수 있음. 네이티브 컨트롤이 받아들일 만한 곳에서는 지금 쓰고, JS는 폴리필처럼 적용하면 됨
    • 주의 시작일이나 input[type=date]에 대해 흔히 제안되는 맞춤 설정 대부분은 개발자가 제어하지 못하는 게 오히려 좋음
      표시할 적절한 달력은 로케일 의존적이어야 함. 사용자의 플랫폼은 사용자가 효과적으로 쓸 가능성이 가장 높은 방식으로 설정하고 표시하는 기능을 이미 갖고 있음
      플랫폼의 날짜 선택기가 직접 만든 이상한 것보다 낫다

  • 그 토글 버튼은 정말 좋음
    이 글에 프론트엔드 밈 개발자들이 분노하는 듯하지만 핵심은 맞음. 왜 이렇게 많은 어리석은 사이트를 JS로 만드는가? 사람들이 HTML 같은 하나의 표준만 따르면 모든 것이 일관될 수 있고, 접근성이나 번역 같은 것도 쉽게 맞출 수 있음
    요즘 사이트에 들어가 보면 모든 걸 단일 페이지에서 동적으로 로드하느라 뒤로 가기 버튼조차 작동하지 않음

    • 사람들이 HTML 같은 하나의 표준을 따른다고 해도, 브라우저 제작자들이 구현을 일관되게 해야 함
      그리고 새 기능이 도입된 뒤 충분히 널리 지원되어 유용해지기까지 몇 년이 걸릴 수 있는, “사람들이 업데이트하기를 기다리는” 문제도 여전히 있음
      나쁜 구현과 복잡한 JavaScript 장치가 많다는 데는 대체로 동의함. 동적 콘텐츠에서도 뒤로 가기 기능을 유지하는 표준화된 해법은 꽤 있고, 인기 웹 프레임워크들은 기본적으로 지원하는 걸로 알고 있음
    • 정말 분노하고 있나?
      상위 댓글을 읽어봤지만 분노라고 부를 만한 건 별로 안 보이고, 브라우저 지원에 대한 타당한 점을 제기하는 사람들이 보일 뿐임

  • 올바른 방향으로 가는 한 걸음이긴 하지만, CSS도 Philip Greenspun이 말한 “artistes”가 읽기 힘든 페이지를 만드는 데 남용하는 또 다른 도구임
    Gemini 지지자는 아니지만, 기본적으로 레이아웃과 타이포그래피의 모든 측면은 브라우저로 돌아가야 하고 사용자가 제어해야 함. 디자이너들은 그걸 믿고 맡길 수 없다는 걸 끝없이 보여줬음

  • 취지는 마음에 들고, 스위치도 멋지며, summary/details도 가끔 유용함
    하지만 datalist 요소는 장난감이나 프로토타입을 넘는 용도에서는 거의 현실적인 선택지가 아님

  • 제가 좋아하는 “JS 없이 CSS로 충분한” 것들은 사이드바 드로어와 캐러셀임
    DaisyUI라는 TailwindCSS 컴포넌트 라이브러리에도 바로 쓸 수 있는 컴포넌트가 있음
    https://daisyui.com/components/drawer/
    https://daisyui.com/components/carousel/

    • 드로어를 스크린리더에 어떻게 알리나?
      드로어와 페이지에 나타나는 다른 콘텐츠는 알려져야 하고, 제어 대상 옆에 aria-expanded 상태가 있어야 함
      여전히 진짜 질문임. 방법이 있을 수도 있고, 개발자들이 collectively 중요하지 않다고 생각할 수도 있음. 감사 담당자들은 동의하지 않겠지만
    • 이런 프레임워크를 보면 처음엔 늘 기대되지만, 테스트해 본 다른 모든 프레임워크처럼 DaisyUI도 iOS Safari와 다른 브라우저에서 여러 문제가 있음
      이런 프레임워크 작성자들은 브라우저 전반에서 실제로 작동하게 만들려면 얼마나 많은 테스트가 필요한지 심하게 과소평가하는 것 같음
      컴포넌트가 그만큼 많고, 게다가 테마까지 가능해지면 기존 테마와 애플리케이션을 깨지 않고 고칠 수 있을지도 장담하기 어려움
    • components/carousel/의 “Snap to [start|center|end]”는 처음 봄
      도대체 snap이 무엇이고 어떻게 동작하나? 제 화면은 손가락 클릭에 반응하지 않음
      알려지지 않은 상호작용 방식은 UI 요소 라이브러리의 좋은 추천 근거가 아니라고 봄
답변달기