2P by GN⁺ | ★ favorite | 댓글 1개
  • Interop 2024는 주요 브라우저 엔진 팀이 같은 웹 기능을 더 일관되게 구현하도록 맞추는 공동 프로젝트이며, 올해는 17개 중점 영역과 3개 조사 프로젝트로 진행됨
  • 상호운용성 개선은 Web Platform Tests 같은 자동화 테스트로 측정되며, WPT는 180만 개 이상 테스트를 갖고 주요 브라우저 전체에서 95% 이상 통과함
  • Interop 2023은 선정 테스트의 3대 브라우저 엔진 공통 통과율을 48%에서 95%로 끌어올렸고, P3 color, Subgrid, Container Queries, :has(), Web Components, Media Queries 4 지원을 크게 정렬함
  • 올해는 96개 제안 중 16개를 고르고 2023년 작업 일부를 이어받아 Accessibility, CSS Nesting, Custom Properties, IndexedDB, Layout, Popover, URL 등 17개 영역에 집중함
  • Microsoft Edge가 Interop 대시보드에 별도 열로 추가되어 브라우저별 진행 상황을 더 직접적으로 비교할 수 있게 됨

브라우저 상호운용성을 맞추는 방식

  • 웹은 다양한 기기에서 동작하도록 설계되어 수십억 명이 협업, 학습, 연결에 사용할 수 있음
  • 개발자가 모든 브라우저와 모든 사용자에게 같은 경험을 제공하려면, 웹 기술의 브라우저 구현이 서로 비슷해야 함
  • 구현 일관성은 웹 표준 프로세스에서 만들어지며, 새 웹 기술의 동작은 상세한 기술 문서로 정의됨
  • 브라우저가 웹 표준을 따르는지는 자동화 테스트로 확인함
    • Web Platform Tests에는 180만 개가 넘는 테스트가 있음
    • 주요 브라우저 전체에서 95% 이상의 WPT가 통과함

Interop 2023이 만든 변화

  • Interop 2023은 2023년 1월 선정 테스트의 48%가 3대 브라우저 엔진에서 모두 통과하는 상태로 시작함
    • 기준 브라우저는 사용자에게 배포된 Chrome과 Firefox 데스크톱 Linux, Safari on macOS Monterey였음
  • 1년 뒤 통과율은 95% 로 상승함
    • 기준 브라우저는 Chrome Dev, Firefox Nightly 데스크톱 Linux, Safari Technology Preview on macOS Ventura였음
  • 여러 웹 기능의 브라우저 간 지원이 개선됨
    • P3 color는 출시 시작 7년 뒤 모든 브라우저에서 완전 지원됨
    • Form controls는 웹 역사상 처음으로 세로 쓰기 모드를 지원함
    • CSS border-image는 원래 의도대로 동작하게 됨
    • Subgrid, Container Queries, :has(), Motion Path, CSS Math Functions, inert, @property가 모든 최신 브라우저에서 지원됨
    • Offscreen Canvas, Modules in Web Workers, Import Maps, Import Assertions, JavaScript Modules 등 Web API가 개선됨
    • Media Queries 4 전체 명세가 더 쉬운 문법과 함께 어디서나 지원됨
    • Web Components는 adoptedStyleSheets, ElementInternals, Form-Associated Custom Elements, Shadow DOM과 Custom Elements 기본 동작에서 개선됨
    • :nth-child(), :nth-last-child(), :modal, :user-valid, :user-invalid 같은 CSS 의사 클래스의 일관된 브라우저 지원을 기대할 수 있게 됨
    • Feature queries는 폰트 기능 감지를 새로 지원함
    • Font Palettes는 컬러 폰트 지원을 강화함
    • CSS Masking, HTML Forms, Pointer and Mouse Events, Scrolling, Transforms, URL, WebCodecs, 웹 호환성 버그 묶음에서도 상당한 진전이 있었음
  • Interop 2023의 26개 중점 영역 중 20개는 성공으로 종료됨
  • 2024년에도 Custom Properties, Pointer and Mouse Events, URL, 그리고 Flexbox·Grid·Subgrid를 묶은 Layout 작업은 계속됨

Interop 2024의 구성

  • 2024년에는 96개 중점 영역 제안이 검토됐고 최종적으로 16개가 선택됨
  • 일부 새 제안을 묶고 2023년 작업 일부를 이어받으면서 Interop 2024는 총 17개 중점 영역을 갖게 됨
  • 안정 버전 브라우저 기준 Interop 2024의 전체 점수는 우연히 다시 48%에서 시작함
  • 올해부터 Interop dashboardMicrosoft Edge 자체 열이 추가됨
    • 현재 이 열은 Windows 10에서 실행되는 Edge와 Edge Dev를 나타냄

2024년 중점 영역

  • Accessibility

    • Interop 2023의 Accessibility 조사 프로젝트에서 Apple 접근성 팀이 WPT용 접근성 테스트 인프라를 만들고 1,300개가 넘는 접근성 테스트를 작성함
    • 이 테스트들이 Interop 2024 중점 영역에 포함되어 브라우저의 접근성 지원 개선을 유도함
    • 새 접근성 테스트 대부분은 WAI-ARIA를 다룸
    • 특히 Roles ModelAccessible Name and Description Computation이 중심임
    • 이들은 보조 기술 사용자가 요소의 목적과 할 수 있는 일을 이해하도록 일관된 메커니즘을 제공함
    • HTML Accessibility API Mappings specification 관련 테스트도 포함됨
    • HTML 요소의 기본 접근성 의미와 <label>, 이미지 alt 텍스트 같은 기능의 브라우저 동작 규칙을 정의함
    • display: contents 접근성 테스트도 새로 포함됨
    • 이 CSS 표시 모드는 Flexbox나 Grid를 위해 부모·자식·손자 관계를 조정할 때 콘텐츠 주변 박스를 제거하는 데 유용함
    • 초기 구현에서는 박스를 제거하면 접근성 트리에서도 콘텐츠가 완전히 사라져 보조 기술 사용자에게 문제가 됨
    • 브라우저에서 대부분의 문제가 수정됐지만 모든 상황에서 완전히 해결된 것은 아님
  • CSS Nesting

    • CSS Nesting은 구현 차이를 줄이고 개발자가 신뢰하고 사용할 수 있도록 Interop 2024에 포함됨
    • CSS 중첩 기능은 2023년에 4대 주요 브라우저 모두에 출시됨
    • Chrome, Edge, Safari는 4월과 5월에 먼저 출시함
    • Firefox는 8월에 출시함
    • 웹 표준은 5월과 8월 사이 약간 바뀌어 모든 중첩 선택자가 기호로 시작해야 한다는 초기 요구사항이 완화됨
    • 개발자는 & article 대신 article을 쓸 수 있음
    • 구현은 모두 업데이트됐지만, Nesting의 복잡한 세부 동작이 CSS Working Group에서 정리되는 동안 상호운용성 개선 여지가 남아 있음
    • Safari의 테스트 실패 대부분은 중첩 CSS가 Shadow DOM과 :host를 통해 상호작용하는 방식과 관련됨
  • Custom Properties

    • @property at-rule은 최근 몇 년 동안 브라우저에 출시되기 시작함
    • Interop 2023의 Custom Properties 영역은 모든 안정 브라우저 공통 테스트 통과율이 4%에서 7.6%로 올랐고, 프리뷰 브라우저 전체에서는 90.7%가 통과함
    • Firefox가 마지막으로 지원을 추가하는 브라우저이며, 현재 Firefox Nightly에서 작업 중임
    • 작업이 끝나지 않아 2024년에도 중점 영역으로 계속됨
    • @property를 사용하면 CSS 커스텀 속성의 문법, 상속 동작, 초기값을 브라우저 엔진이 CSS 속성을 정의하는 방식과 비슷하게 선언할 수 있음
    • 이를 통해 그라디언트나 transform의 특정 부분처럼 이전에는 CSS로 불가능했던 애니메이션이 가능해짐
  • Declarative Shadow DOM

    • Declarative Shadow DOM은 JavaScript 없이 HTML만으로 재사용 가능한 위젯과 컴포넌트를 만들 수 있는 선언형 API임
    • Safari 16.4는 2023년 3월부터, Chrome 90은 2021년 4월부터 지원함
    • Firefox는 Firefox Nightly에서 구현을 갖고 있음
    • State of HTML 2023 설문에서 자주 요청된 기능 중 하나였고, 모든 브라우저에서 상호운용성을 확보하기 위해 Interop 2024에 포함됨
  • Font size adjust

    • font-size-adjust는 오래된 기술에 집중하는 유용성을 보여주는 사례임
    • Firefox는 2008년에 처음 구현했지만 웹 디자이너와 개발자 사이에서 거의 사용되거나 논의되지 않음
    • 초기 명세는 시간이 지나며 두 값 문법을 통해 더 많은 언어를 지원하고, from-font 값으로 사용성이 개선됨
    • WebKit 팀은 Safari 16.4에서 기본 버전을 구현했고 Safari 17.0에서 업데이트를 추가함
    • Mozilla는 Firefox 118에서 구현을 업데이트했으며 Safari와 Firefox는 현재 모든 테스트를 100% 통과함
    • Chrome은 2015년에 실험적 구현을 시작했지만 아직 출시하지 않음
    • Font size adjust는 텍스트 문자열 안의 여러 폰트가 같은 시각적 크기로 보이도록 맞추는 방법을 제공함
    • 예를 들어 1.4rem 텍스트에서 x-height, cap height, ch width, ic width, ic height를 맞출 수 있음
    • 코드와 일반 텍스트를 섞거나 여러 언어를 한 문장에 섞을 때 유용함
  • HTTPS URLs for WebSocket

    • WebSocket API는 ws:wss:라는 비 HTTP(S) 스킴을 사용해야 하는 특성이 있음
    • URL 동작은 HTTP(S) URL과 거의 같기 때문에 API 사용이 번거로울 수 있음
    • WebKit 팀은 웹 개발자 피드백을 바탕으로 API가 HTTP(S) URL도 지원하도록 했고 Safari 17.0에 출시함
    • 기존에는 location.protocol에 따라 wss: 또는 ws:로 바꾸는 코드가 필요했지만, 이제 new WebSocket(path)처럼 쓸 수 있음
    • Interop 2024에 포함해 다른 브라우저도 이를 채택하도록 하는 것이 목표임
  • IndexedDB

    • IndexedDB는 객체 지향 데이터베이스 형태로 클라이언트 측에 데이터를 저장하는 API임
    • 2011년부터 브라우저에 출시되기 시작했고, 웹 표준은 계속 발전해 옴
    • version 2와 version 3는 모든 주요 브라우저가 지원함
    • version 2는 완전히 상호운용되지만 version 3는 구현 품질을 맞추기 위한 추가 작업이 필요함
  • Layout

    • CSS GridFlexbox는 2021년 원래 Interop 프로젝트에 포함됨
    • Subgrid는 Interop 2023에 추가됨
    • 세 레이아웃 방식은 모두 좋은 상태지만 아직 완벽하지는 않음
    • 2024년에는 세 영역의 테스트가 Layout이라는 하나의 중점 영역으로 합쳐짐
    • 복잡한 경계 사례의 상호운용성을 높이는 작업이 계속됨
    • 개발자는 Flexbox, Grid, Subgrid 모두를 신뢰하고 사용할 수 있으며, 모든 브라우저가 견고하게 지원함
  • Pointer and Mouse Events

    • Pointer events는 마우스, 펜·스타일러스, 하나 이상의 손가락 터치 같은 포인팅 입력 장치를 하나의 DOM 이벤트 모델로 처리함
    • 이 API는 2012년부터 브라우저에 출시되기 시작했고 2019년까지 모든 브라우저에 도입됐지만 상호운용성은 불안정했음
    • Interop 팀은 2022년에 Pointer and Mouse Events 조사 프로젝트를 시작해 합의를 명확히 하고 이를 반영하는 테스트를 작성함
    • Interop 2023에서 이 테스트가 중점 영역으로 들어갔고 통과율은 34%에서 81% 로 상승함
    • 아직 할 일이 남아 있어 2024년에도 중점 영역으로 계속됨
  • Popover

    • HTML의 popover 속성은 페이지 최상위 레이어에 요소가 나타나도록 하는 브라우저 내장 방법을 제공함
    • 전체 웹 페이지를 덮는 오버레이를 만들 때는 dialog 요소가 가장 적합함
    • 다른 요소를 팝업 메시지, 사용자 인터페이스, 나타났다 사라지는 콘텐츠로 만들고 싶을 때 popover가 프레임워크를 제공함
    • popover 지원은 2023년에 Chrome 114와 Safari 17.0에 출시됨
    • Firefox는 Firefox Nightly에서 지원 작업 중임
  • Relative Color Syntax

    • Relative Color Syntax는 다른 색상을 참조해 CSS 색상을 정의하는 새 방법임
    • 기존 색상을 일정량 밝게 또는 어둡게 만들거나, 색상 변수의 채도를 조정해 두 번째 변수에 할당할 수 있음
    • 디자인 시스템을 만들 때 특히 강력할 수 있음
    • Safari 16.4가 2023년 3월 최초로 지원을 출시함
    • Chrome 119와 Edge 119는 2023년 10월과 11월에 지원을 출시함
    • 현재 구현 중 currentcolor를 Relative Color Syntax와 함께 사용하는 기능을 지원하는 것은 없음
    • Interop 2024의 Relative Color Syntax 영역은 전체 지원 여부가 아니라 currentcolor 지원과 색역 밖 동작 테스트에 좁게 집중함
    • P3 color를 지원하지 않는 디스플레이에서 어떤 일이 일어나는지 확인함
  • requestVideoFrameCallback

    • <video> 요소는 웹에서 비디오를 넣는 강력한 기능을 제공함
    • HTMLVideoElement는 JavaScript에서 비디오 객체를 조작하는 속성과 메서드를 제공함
    • requestVideoFrameCallback()은 비디오 프레임별 작업을 효율적으로 수행할 수 있게 함
      • 비디오 처리나 분석
      • canvas에 그리기
      • 오디오 소스와 동기화
    • Chrome 83과 Safari 15.4부터 지원됨
    • Interop 2024 포함은 브라우저 구현을 완성하고 다듬는 데 도움을 줌
  • Scrollbar Styling

    • Scrollbar Styling 영역은 스크롤바 스타일링에 사용할 수 있는 두 CSS 속성을 포함함
    • scrollbar-widthauto, thin, none 세 값을 제공함
      • auto는 기본 너비임
      • thin은 더 얇은 스크롤바를 제공함
      • none은 콘텐츠 스크롤은 유지하면서 스크롤바를 숨김
    • Firefox 64는 2018년 12월에 지원을 구현했고, Chrome 121과 Edge 121에도 막 출시됨
    • scrollbar-gutter는 스크롤바 공간을 예약해 스크롤바 존재 여부와 상관없이 같은 레이아웃을 유지하게 함
    • scrollbar-gutter: stable은 스크롤바가 없어도 공간을 예약하도록 브라우저에 지시함
    • 스크롤바 필요 상태가 바뀔 때 레이아웃 이동을 막을 수 있음
    • Chrome 94, Edge 94, Firefox 97에 2021~2022년에 출시됨
    • Safari가 이 중점 영역을 완료하기 위해 가장 많은 작업을 해야 함
    • Chrome과 Firefox는 이미 테스트를 100% 통과함
    • Safari는 2009년에 ::-webkit-scrollbar-* 9개 의사 요소로 스크롤바 스타일링 기능을 먼저 제공했지만, 이 방식은 공식 CSS 웹 표준이 되지 않음
    • CSS Working Group은 훨씬 단순한 접근을 선택함
  • @starting-style and transition-behavior

    • 이 영역은 애니메이션 제어를 위한 두 새 기능에 집중함
    • 두 기능 모두 2023년 9월 Chrome 117과 Edge 177에 출시됨
    • @starting-style은 특정 요소의 시작 값을 정의하게 해줌
    • 요소가 transition을 거치려 할 때 필요함
    • display:none으로 들어가거나 나오는 전환 방법도 제공함
    • transition-behavior는 이전에 애니메이션에서만 가능했던 이산 애니메이션 가능 속성 처리를 CSS transition으로 확장함
    • 요소를 보이거나 숨길 때 display 속성을 전환할 수 있는 길을 엶
  • Text Directionality

    • 텍스트 흐름 방향은 웹 조판에서 중요한 요소임
    • 일부 언어는 왼쪽에서 오른쪽으로, 일부 언어는 오른쪽에서 왼쪽으로 흐름
    • dir attribute는 HTML 요소에 방향을 left, right, auto로 표시할 수 있게 함
    • auto는 첫 글자를 보고 브라우저가 방향을 추정하도록 요청함
    • 방향성과 shadow tree의 상호작용은 최근까지 잘 정의되어 있지 않았음
    • 표준 수준에서 이 문제가 다뤄졌고, Interop 2024 포함으로 구현 정렬을 확인함
  • text-wrap: balance

    • 웹 디자이너는 매우 짧거나 한 단어뿐인 줄을 막을 방법을 오래 원해 왔음
    • 반응형 웹 디자인과 컬럼 너비 제어 부족으로 이 문제는 더 어려워짐
    • text-wrap은 특정 사용 사례에 맞춰 줄바꿈 계산 방식을 브라우저에 알려주는 여러 옵션을 제공함
    • text-wrap: balance는 제목에 적합한 해결책임
    • 몇 줄의 텍스트를 균형 있게 배치해 각 줄이 비슷한 양의 텍스트를 갖도록 함
    • Chrome 114와 Firefox 121에 출시됐고 Safari Technology Preview에 구현됨
    • Interop 2024는 text-wrap-mode, text-wrap-style, white-space-collapse의 동작 테스트도 포함함
    • CSS Working Group이 최근 이 longhand들이 서로 상호작용하는 방식을 바꿔 브라우저 간 지원이 현재 고르지 않음
  • URL

    • URL은 웹의 가장 근본적인 요소 중 하나이며, URL 없이는 웹이 존재하지 않음
    • 웹 초기 역사에 발명된 많은 것처럼 URL 지원도 아직 완전히 상호운용되지 않음
    • WHATWG는 URL이 정확히 어떻게 동작해야 하는지 상세히 담은 URL Living Standard를 작성함
    • 이 표준을 지원하는 테스트는 Interop 2023 중점 영역이었고 통과율은 77%에서 85%로 향상됨
    • 2024년에도 상호운용성 확보를 위해 작업이 계속됨
    • Safari는 테스트의 99.7% 를 통과함

조사 프로젝트와 진행 추적

  • Interop 2024에는 3개의 조사 영역도 포함됨
    • Accessibility Testing
    • Mobile Testing
    • WebAssembly Testing
  • 조사 영역은 Interop 팀이 더 많은 테스트를 작성하고 실행 가능하게 만드는 과제임
  • Mobile Testing 조사 프로젝트는 모바일 운영체제에서 브라우저를 테스트할 수 있도록 WPT에 필요한 인프라를 완성하는 것을 목표로 함
    • 향후 Interop 프로젝트 대시보드에 모바일 점수가 포함될 가능성도 있음
  • 세 조사 중 두 개는 작년부터 이어지는 프로젝트지만, 2024년에는 모두 0% 완료 상태에서 시작함
  • 참여 팀들은 올해 새 목표를 정하고 대시보드는 그 목표 대비 진행 상황을 표시함
  • Interop 2024 진행 상황은 Interop 2024 dashboard에서 확인할 수 있음
  • 상호운용성은 웹의 성공을 만드는 근본 축 중 하나이며, Interop 2022와 2023의 작업을 바탕으로 2024년에도 협업이 계속됨

댓글과 토론

Hacker News 의견들
  • 여기에는 확실히 멋진 변화가 있고, 지원이 좋아지는 건 반가움
    예를 들어 CSS 중첩은 SASS와 LESS가 유용했던 핵심 이유 중 하나라서 큰 변화임. 변수처럼 전처리기 기능이기보다 CSS 핵심 기능으로 들어가는 편이 원래 더 맞았음
    커스텀 속성으로 무엇을 할 수 있는지도 늘 흥미롭고, Shadow DOM과 커스텀 요소 다음 단계로 보기 좋음. popover도 의외로 괜찮아서, 이제 JavaScript 없이 팝업 모달 같은 걸 만들 수 있다는 점은 매우 유용함. 커스텀 모달, 드롭다운 메뉴, 햄버거 버튼 등에 시간을 낭비하는 일을 줄여줄 수 있음
    다만 이런 프로젝트에서 도 더 신경 써줬으면 함. HTML 5 시기의 여러 필드가 브라우저마다 지나치게 다르고, 표시를 위해 독자 의사 클래스 스타일링에 기대며, 전반적으로 커스터마이즈가 어렵다는 현재 상태는 거의 무엇이든 할 수 있는 플랫폼치고는 놀랄 만큼 낡아 보임

    • UI 디자이너가 마음대로 움직일 수 있으면, 예전에는 좋아했더라도 이런 새 기본 모달·메뉴·버튼을 원하지 않는 경우가 많음
      이 변화가 도움이 되긴 하겠지만, UI에서는 일관성이 모두가 추구해야 할 기능이 아니라 약점처럼 취급되는 듯함
    • CSS 중첩은 CSS 전처리기를 쓰는 마지막 이유임
      Safari 17.2+가 더 널리 퍼지면 그냥 순수 CSS를 쓸 수 있음
      그 외에는 @media 쿼리용 변수도 이유이긴 한데, 이건 덜 흔한 필요임
  • 결국 JPEG XL은 들어가지 않은 듯함. 아주 오랜만에 전반적으로 확실한 개선을 가져온 첫 이미지 형식이라는 점을 생각하면 꽤 이해하기 어려움
    Interop이 Google이 사실상 채택을 막는 상황을 멈추게 해주길 기대했지만, 널리 쓰이는 낡은 형식들의 어설픈 대체물이 계속 쌓이는 동안 더 기다려야 할 듯함

    • 이 점은 나도 아쉬움
      Google이 JPEG XL에 대해 뭐가 불만인지 모르겠음
  • “모든 브라우저가 P3 색상을 완전히 지원하게 됐다”는 말은 사실과 좀 다름
    Firefox는 여전히 색상을 장치로 보내기 전에 모두 sRGB로 클램프함. https://bugzilla.mozilla.org/show_bug.cgi?id=1626624#c16

  • 웹 작업을 아주 가끔 하는 정도라 내가 주요 대상은 아니지만, WebKit에서 가장 눈에 띄는 빠진 기능은 SVG 파비콘 지원 부족임
    정말 이해하기 어렵고, 크기가 다른 Apple 전용 아이콘들을 모두 챙기는 건 나 같은 가벼운 웹 개발자에게 꽤 번거로움

    • 이제는 예전 같지 않아서 기쁠 것임. 지금은 Apple 전용 아이콘 하나만 있으면 됨 [1]:
      [1]: https://evilmartians.com/chronicles/how-to-favicon-in-2021-s...
    • 약간 관련된 얘기지만, Chrome은 ico 파비콘이 있으면 SVG 파비콘을 쓰지 않음. (https://bugs.chromium.org/p/chromium/issues/detail?id=145085...) 그래서 PNG 파비콘과 SVG 파비콘을 함께 배포함
    • 참고로 Safari는 이 형식의 단색 SVG 파비콘을 지원함
      Vite 같은 걸 쓰면 단일 원본 이미지에서 파비콘과 홈 화면 아이콘 생성을 전부 자동으로 만들 수도 있음
    • SVG는 원하는 방식으로 스케일되지 않음. 예를 들어 256px 정사각형 이미지를 벡터로 만들었더라도, 벡터 변환만으로 24px에서 보기 좋게 만들 수는 없음
    • 맞는 말임. 이런 아이콘들을 전부 생성해야 할 필요가 없어야 함
      그리고 목록도 스타일링할 수 있으면 좋겠음. 예를 들어 요소에 깃발 같은 걸 붙이는 식으로
      CSS 페이지 전환이나 스크롤 기반 애니메이션도 언급이 없는데, 이것들도 상용구 JavaScript를 줄일 수 있음
  • 생각보다 이 글을 읽고 훨씬 더 신났음
    참여 컨소시엄에 왜 PWA 중점 영역이 없는지 궁금함

    • 역사적으로 Interop은 CSS에 더 초점을 맞춘 편이었지만, 점점 바뀌고 있음
      그래도 많은 테스트 영역에 워커 테스트가 포함되어 PWA 상태도 좋아지게 되어 있음. 2023년에는 Modules 섹션 전체가 있었고, PWA/워커 특화 기능을 많이 테스트했음. OffscreenCanvas나 모바일 테스트처럼 테스트·조사 대상인 API 상당수도 여러 PWA 애플리케이션과 관련이 큼
      올해는 작년처럼 CSS 중심성이 가장 낮은 Interop임. 내가 보기엔 PWA가 주로 의존하는 IndexedDB, WebSocket, 중요한 접근성 개선 섹션이 있음. 조사 영역 3개인 WebAssembly, 접근성, 모바일 테스트도 모두 PWA와 관련이 큼
      구체적으로 어떤 API에 더 집중하길 바라는지 궁금함
    • 기억하기로 컨소시엄은 대략 12명 정도이고, 이 사람들은 브라우저 회사에서도 일함
      목표는 모여서 현재 로드맵과 업무량을 고려해 1년 동안 함께 작업하거나 개선할 수 있는 기능을 찾는 것임. Interop은 본업의 주요 기능 개발 사이에 처리할 수 있는 작은 추가 티켓처럼 보면 됨
      지금까지 초점은 브라우저가 콘텐츠를 렌더링하는 방식의 아주 낮은 수준 세부 사항에 맞춰져 있었음. JavaScript API는 대체로 표준화되어 “상류”에서 병합되어 있기 때문에, 개선 여지가 가장 큰 영역이 여기임
      모든 엔진에서 새 기능을 동시에 구현하자는 흐름이 나오기 전에, 브라우저 간 빈틈을 메우는 작업이 계속 더 많이 이뤄질 것 같음
      다만 Apple이 마침내 모바일 Safari에 웹 푸시를 추가하면서, PWA 기능의 이점을 얻을 웹 앱 대부분이 필요로 하는 부분에는 꽤 가까워지고 있음. 아직 브라우저 공통으로 없는 기능 중 어떤 걸 쓰고 싶은지 궁금함
    • PWA 중점 영역에 무엇이 포함된다고 보는지 궁금함
      다른 곳에서 https://web.dev/learn/pwa/capabilitieshttps://whatpwacando.today를 링크했지만, 그 기능 상당수는 본질적으로 PWA 기능이라고 보기 어렵다고 생각함. 정말 많은 기능이 PWA 밖에서도 널리 쓰이므로, 그것들을 “PWA” 묶음에 넣는 건 의미가 희미해짐. 웹 개발자에게는 “저장소”나 “미디어” 같은 묶음이 더 의미 있을 가능성이 큼
      PWA의 기본 정의를 보면 주로 manifest와 service worker, 그리고 이들을 웹 플랫폼과 조합해 쓰는 것에 관한 것임
      manifest는 자동 테스트가 어려움. 내용이 브라우저 UI의 서로 다른 부분에 표시되는데, UI는 대체로 웹 표준에서 명시되지 않음. 벤더들이 자체 UI 결정을 내릴 자유를 원하기 때문임. 그래서 포함하기 어렵고, 상호운용성 문제가 얼마나 있는지도 불명확함
      service worker는 제안될 수는 있음. 최근 몇 년간은 제안되지 않았지만, 이쪽도 요즘 상호운용성 문제가 그렇게 많았다고 보지는 않음
    • PWA는 앱스토어 모델을 우회함. 브라우저에서 직접 앱을 설치할 수 있음
      그래서 이 문제를 질질 끌고 PWA 경험을 일부러 덜 매력적으로 만드는 게 그들에게 이익임
      Firefox가 PWA 지원을 뺀 건 잘 모르겠지만, 아마 유지보수 비용 때문일 수 있음
    • “콘텐츠 표시”라는 훨씬 더 넓은 용도에 비하면 PWA는 틈새 사용 사례이기 때문임
  • 폰트
    CSS 타이포그래피에 더 많은 노력이 들어가면 좋겠음
    특히 leading-trimmargin-trim이 필요함
    https://medium.com/microsoft-design/leading-trim-the-future-...
    https://developer.mozilla.org/en-US/docs/Web/CSS/margin-trim

  • 가장 큰 성과는 Safari 업데이트가 운영체제 업데이트에 묶이지 않게 되는 것임

    • macOS에서는 가능함
      다만 iOS에서는 안 됨
      그리고 iOS 업데이트가 3~4개월마다 새로 나오므로, 실제로 iOS에서는 문제가 되지 않음
  • 이것이 WebKit이 WebAssembly 기능을 따라잡기 시작한다는 신호인지 궁금함
    현재 Chrome과 Firefox에 비해 꽤 뒤처져 있고, multiple memories나 garbage collection 같은 크고 중요한 기능이 없음

    • 둘 다 아직 Wasm 명세에 포함되지 않았고 표준화 중임
      Google은 “준비! 발사! 조준! 다시 발사!”에 가까워서 완성되지 않은 명세 구현을 더 쉽게 내보내는 편이고, Apple은 “준비! 조준! 조준! 발사!”에 가까워서 일반적으로 그런 일을 꺼림. Firefox에 대해서는 말하기 어려움
  • 아직 Cookie Store API가 공식 구현되지 않았다는 게 믿기지 않음
    2024년인데도 이름으로 쿠키 하나 가져오려고 거대하고 지저분한 문자열을 파싱해야 한다니 말이 되나

    • HTML 5 localStorage가 생겼기 때문 아닐까
  • WebSocket 프로토콜 이슈는 이해가 잘 안 됨
    업그레이드 이후 연결은 더 이상 http(s) 프로토콜이 아니니, 여기서 http나 https 사용을 허용하는 건 오해를 부르지 않나? 삼항 연산자를 쓰거나 현재 페이지가 이동한 값과 다른 값을 갖는 게 그렇게 끔찍한가? 브라우저 정규화 작업을 하는 건 반갑지만, 이 항목은 바꿀 가치가 있다 해도 우선순위가 꽤 낮아 보임