브라우저 지원 기준
크로스 브라우징 기준을 미리 정해두지 않으면 새 기능을 만날 때마다 판단이 흔들립니다.
SLUR UX/UI System의 기준은 한 줄입니다.
검증은 Chrome과 Safari 두 곳. 네이티브 기능 채택의 리트머스는 Safari.
이 문서는 그 결론이 어디서 왔는지 — 웹이 처음 약속한 것, IE 시절의 크로스 브라우징이 실제로 어떤 일이었는지, 무엇이 바뀌어서 지금의 기준이 성립하는지를 기록합니다.
웹이 약속한 것 — 보편성
섹션 제목: “웹이 약속한 것 — 보편성”웹을 만든 팀 버너스리(Tim Berners-Lee)의 설계 철학은 **보편성(universality)**입니다. 용어는 어렵지만 내용은 단순합니다.
“누가, 어떤 기기로, 어떤 프로그램으로 열어도 같은 정보에 닿을 수 있어야 한다.”
웹이 태어난 1989년의 CERN 연구소에는 컴퓨터마다 운영체제와 문서 시스템이 달라서, 옆 팀의 문서를 읽으려면 옆 팀의 장비와 프로그램이 필요했습니다. 정보가 기계에 갇혀 있던 것입니다.
버너스리의 답은 “모두 같은 기계를 쓰자”가 아니라 **“기계는 달라도 되니, 공통 규칙만 함께 쓰자”**였습니다. 주소는 URL, 전송은 HTTP, 문서는 HTML — 이 규칙이 표준이고, 특정 회사의 소유가 아니라 공개되어 있어서 누구든 표준을 구현한 브라우저를 만들면 웹에 참여할 수 있습니다. 이 표준을 중립적으로 관리하는 곳이 W3C·WHATWG입니다.
“웹의 힘은 보편성에 있다.” — 팀 버너스리
보편성의 범위에는 기기·브라우저뿐 아니라 신체 조건도 들어갑니다. 접근성이 부가 기능이 아니라 웹의 기본 설계인 이유입니다.
SLUR UX/UI System은 이 철학에 깊이 공감하고, 여기에 맞춰 만들어지려고 노력합니다. 시맨틱 마크업과 접근성을 선택 사항이 아니라 문법의 일부로 두는 것, 특정 브라우저의 전용 기능이 아니라 표준 네이티브 기능을 우선하는 것이 그 실천입니다.
이 철학에서 역할 분담이 나옵니다. 저자는 표준에 맞춰 한 번만 쓰고, 같은 결과를 그려내는 책임은 표준을 구현하는 브라우저 쪽에 있습니다. 저자가 브라우저마다 따로 맞추는 것은 원래 설계에 없던 일입니다.
크로스 브라우징이라는 문제는, 이 약속이 브라우저 쪽에서 깨졌을 때 저자에게 청구되는 비용입니다.
IE 시절 — 크로스 브라우징이 “진짜 문제”였던 이유
섹션 제목: “IE 시절 — 크로스 브라우징이 “진짜 문제”였던 이유”1990년대 브라우저 전쟁(Netscape vs IE)을 거치며 브라우저들은 표준 대신 자기 전용 기능으로 경쟁했고, 승자가 된 IE는 2001년 IE6 이후 5년간 업데이트를 멈췄습니다.
한국은 특히 심했습니다. 공인인증서·ActiveX 생태계가 IE에 묶이면서 세계가 IE를 떠난 뒤에도 IE6·IE7 대응이 실무의 전제였습니다.
그 시절의 크로스 브라우징은 표준 준수 확인이 아니라 오차 보정 노동이었습니다.
- 조건부 주석 —
<!--[if lte IE 7]>로 IE 전용 CSS를 따로 서빙 - CSS 핵 —
* html, 속성 앞_·*같은 파서 버그를 역이용한 선택자 - 렌더링 버그 대응 —
hasLayout, 더블 마진 버그, PNG 알파 투명도 스크립트 - JS 분기 —
attachEventvsaddEventListener,document.all분기
문제의 본질은 두 가지였습니다. 표준을 안 따르는 엔진이 있었고, 그 엔진이 업데이트되지 않았다는 것. 같은 코드가 브라우저마다 다르게 그려지니, 브라우저 수만큼 검증하고 브라우저 수만큼 예외 코드를 쌓아야 했습니다.
무엇이 바뀌었나
섹션 제목: “무엇이 바뀌었나”이 구조는 2010년대를 지나며 무너졌습니다.
- 에버그린 브라우저 — Chrome(2008)이 시작한 자동 업데이트가 표준이 되어, “몇 년 묵은 브라우저”라는 변수 자체가 사라졌습니다.
- IE의 종료 — 2022년 지원 종료. 표준을 안 따르는 엔진이 퇴장했습니다.
- 엔진의 수렴 — 렌더링 엔진은 사실상 셋(Blink·WebKit·Gecko)이고, Edge·Whale 등 국내 브라우저 대부분이 크로미움(Blink) 계열입니다.
- 표준 프로세스의 성숙 — 브라우저 제조사들이 Interop 프로젝트로 매년 호환성 목표를 함께 맞추고, 지원 현황이 공개 데이터(caniuse, Baseline)로 관리됩니다.
그 결과 크로스 브라우징의 성격이 바뀌었습니다. “브라우저별 오차를 보정하는 일”에서 “지원 범위를 결정하는 일”로. 표준대로 작성한 코드는 이제 기본적으로 어디서나 같게 동작하고, 남는 질문은 “아직 덜 구현된 새 기능을 언제부터 쓰는가”뿐입니다.
지금의 기준 — 검증은 Chrome과 Safari 두 곳
섹션 제목: “지금의 기준 — 검증은 Chrome과 Safari 두 곳”- Chrome — 크로미움 계열(Edge·Whale 등)을 대표합니다.
- Safari — macOS·iOS의 WebKit을 대표합니다. iOS에서는 타 브라우저도 WebKit 엔진을 쓰므로, Safari 검증이 곧 iOS 전체 검증입니다.
국내 사용 환경에서 이 두 엔진이 사실상 전부를 커버합니다.
네이티브 기능 채택의 리트머스는 Safari
섹션 제목: “네이티브 기능 채택의 리트머스는 Safari”리트머스 시험지가 색 하나로 산성인지 즉시 판별해 주듯, 새 네이티브 웹 기능(HTML·CSS·JS)을 쓸지 말지는 “Safari가 지원하는가” 라는 질문 하나로 판정이 끝납니다. 크로미움이 대부분의 기능을 먼저 구현하므로 — 검증하는 두 브라우저 중 늦는 쪽은 항상 Safari라 — 실질적인 관문은 Safari 하나입니다.
Safari가 아직 지원하지 않는 기능은 둘 중 하나로 처리합니다.
- 제외 — 동작에 필수라면 쓰지 않습니다.
- 향상 전용(progressive enhancement) — 없어도 화면과 동작이 성립한다면, 지원 브라우저에서만 더 좋아지는 방향으로만 씁니다.
예 (2026-08 기준): closedby="any", popover="hint"(WebKit 26.5에서 지원 확인 — 이전 Safari가 남아 있는 동안은 같은 취급), appearance: base-select
이 목록은 고정된 규칙이 아니라 시점의 기록입니다. Safari가 지원을 시작하면 다시 채택 후보가 되며, 바뀌면 변경 이력에 남깁니다.
Firefox는 검증하지 않는다
섹션 제목: “Firefox는 검증하지 않는다”Firefox(Gecko)는 표준을 성실히 따르는 엔진이지만, 검증 대상에 넣지 않습니다.
- 국내 점유율이 낮아, 검증을 유지하는 비용이 효용을 넘어섭니다.
- 표준대로 작성하는 한 Gecko에서 깨질 위험 자체가 낮습니다 — IE처럼 “표준 밖에서 다르게 그리는” 엔진이 아니기 때문입니다.
- 따라서 Firefox의 미지원·지연도 채택 판단에서 무시합니다.
예:
@starting-style진입 애니메이션은 Firefox 지원이 늦었지만 무관하므로 채택합니다.
주의할 것은, 이것이 Firefox를 차단한다는 뜻이 아니라는 점입니다. IE 시절의 “지원 안 함”은 그 브라우저에서 화면이 깨진다는 뜻이었지만, 표준 기반으로 작성된 SLUR 코드는 검증하지 않는 브라우저에서도 대체로 그대로 동작합니다. 표준에 맞춰 쓰는 것 자체가 보편성을 지키는 방법이고, 검증 범위는 그 위에서 비용을 관리하는 선택일 뿐입니다. 브라우저에 맞추던 시절에서, 표준에 맞추고 검증만 좁히는 시절로 — 이것이 웹이 처음 약속한 구조로 돌아온 형태입니다.
왜 범위를 좁히는가
섹션 제목: “왜 범위를 좁히는가”검증 브라우저 하나를 늘리는 것은 그 브라우저의 테스트·폴백·우회 코드가 수명 내내 따라온다는 뜻입니다. IE 시절의 크로스 브라우징 비용이 정확히 그것이었습니다.
범위를 Chrome·Safari로 좁히면
- 폴리필과 우회 코드 없이 네이티브 기능을 먼저 쓸 수 있고,
- 채택 판단이 “Safari가 되는가” 한 문장으로 끝나며,
- 크로스 브라우징 QA가 두 곳으로 고정되어 비용을 예측할 수 있습니다.
판단의 방향은 기능 절제 원칙과 같습니다. 기본은 최소, 근거가 있을 때만 넓힌다.