WHATWG

WHATWG 는 브라우저가 따르는 웹 표준 문서를 쓰고 고쳐 나가는 모임입니다. 웹 페이지를 읽고 그리는 핵심 규칙이 여기서 나옵니다. 판 번호를 매겨 끝내는 대신 한 문서를 늘 고쳐 씁니다.

쉽고 빠른 이해

브라우저가 웹 페이지를 어떻게 읽고 그릴지 정한 규칙 문서를 관리하는 모임입니다. 서버가 보낸 웹 페이지 문서를 브라우저가 어떻게 해석하는지도 이 모임의 문서가 정합니다.

규칙이 한 곳에 모여 있어야 브라우저마다 같은 페이지를 같게 보여 줍니다. 두 단체가 같은 이름의 문서를 따로 내면 개발자는 어느 쪽을 믿어야 할지 모릅니다.

어떻게 도는가:

브라우저 제작사와 편집자가 문서 하나를 고쳐 나갑니다
여섯 달쯤마다 그 시점의 사본을 만들어 따로 남깁니다
특허 걱정 없이 쓰도록 고정된 사본이 필요합니다. 남긴 사본으로 특허 검토를 합니다

대가도 있습니다. 문서가 늘 바뀌니 「어느 판을 지켰다」고 못 박기 어렵습니다.

상세

단골 식당 주방 벽에는 그날 들어온 재료에 맞춰 이름과 값을 지웠다 다시 쓰는 칠판 메뉴가 걸려 있습니다. 전단을 새로 돌릴 때가 되면 그날의 칠판을 그대로 옮겨 적은 종이 한 장을 따로 남깁니다. 손님에게 하는 약속은 지우지 않는 그 종이가 맡습니다.

WHATWG(Web Hypertext Application Technology Working Group)는 웹 표준을 만드는 모임입니다. 웹 브라우저가 무엇을 어떻게 처리해야 하는지를 표준 문서로 적습니다. HTML(HyperText Markup Language) 문서를 읽는 법, 주소를 해석하는 법, 네트워크 요청을 보내는 법이 여기에 들어갑니다.

생겨난 까닭

2004년에 Apple · Mozilla · Opera 에서 일하던 사람들이 이 모임을 세웠습니다. 당시 웹 표준을 내던 기구인 W3C(World Wide Web Consortium)는 HTML 대신 XHTML(Extensible HyperText Markup Language) 쪽으로 방향을 잡고 있었습니다.

XHTML 은 HTML 을 XML(Extensible Markup Language) 문법처럼 엄격하게 쓰게 한 판입니다. 태그 하나만 잘못 닫아도 브라우저가 페이지를 보여 주지 않고 오류를 냅니다. 이미 있는 웹 페이지는 대부분 조금씩 틀린 HTML 이라서, 세 곳은 이 방향이 실제 웹과 멀다고 보았습니다.

그래서 HTML 을 발전시키는 일을 따로 떠맡았습니다. 브라우저를 만드는 쪽이 직접 문서를 썼다는 점이 이 모임의 성격을 정했습니다. 표준 문서가 이상보다 브라우저가 실제로 하는 동작을 적는 쪽으로 기울었습니다.

Living Standard

WHATWG 의 문서는 Living Standard 라고 부릅니다. 「HTML 5」「HTML 5.1」 처럼 판 번호를 붙여 끝내지 않습니다. 의견이 들어오면 문서를 고칩니다. 새 기능도 시간을 두고 더합니다.

고칠 때는 이미 있는 웹 페이지가 깨지지 않게 합니다. 이것을 하위 호환을 지킨다고 합니다. 버그를 찾으면 새 판을 기다리지 않고 바로 문서에 반영합니다.

판 번호가 없으면 곤란한 일이 하나 생깁니다. 표준을 따르는 누구도 특허 사용료를 물지 않게, 참여 회사들이 「이 문서에 담긴 기술로 특허 소송을 걸지 않겠다」고 약속합니다. 그런데 문서가 늘 바뀌면 약속이 어느 내용에 대한 것인지 정할 수 없습니다.

그래서 여섯 달쯤마다 그 시점의 사본을 만들어 Review Draft 로 남깁니다. Review Draft 는 고치지 않는 고정 사본입니다. 특허 약속과 검토는 이 사본을 대상으로 합니다.

flowchart TD
    A["편집자 · 브라우저 제작사가 고친다"] --> B["Living Standard · 늘 최신"]
    B -->|"여섯 달쯤마다 사본을 만든다"| C["Review Draft · 고정 사본"]
    C --> D["특허 검토"]
    B -->|"고치기는 멈추지 않는다"| A

그림에서 고치는 일은 위쪽에서 멈추지 않고 돕니다. 아래로 떨어져 나오는 Review Draft 만 고정된 사본입니다.

W3C 와의 관계

W3C 는 WHATWG 보다 오래전부터 웹 표준을 내던 기구입니다. 한동안 W3C 와 WHATWG 가 HTML 과 DOM(Document Object Model, 문서 객체 모델) 문서를 각자 냈습니다. 개발자는 같은 이름의 문서가 둘이라 어느 쪽을 따라야 할지 헷갈렸습니다.

2019년에 W3C 와 WHATWG 가 합의해 이 갈림을 정리했습니다. HTML 과 DOM 은 주로 WHATWG 에서 만듭니다. W3C 는 따로 내던 HTML · DOM 문서를 멈췄습니다.

대신 W3C 는 WHATWG 의 Review Draft 에 의견을 냅니다. 그리고 그 사본을 W3C 권고로 승인합니다. 권고는 W3C 가 정식 표준으로 확정한 문서를 부르는 이름입니다.

지금 HTML 이나 DOM 의 정본을 찾으면 WHATWG 문서로 갑니다. W3C 는 CSS(Cascading Style Sheets) 나 웹 접근성 같은 다른 영역의 표준을 이어서 냅니다.

관리하는 표준 문서

WHATWG 는 HTML 하나만 다루지 않습니다. 브라우저 동작을 나눠 여러 문서로 적습니다. 아래는 백엔드 개발자도 자주 마주치는 것들입니다.

문서	무엇을 정하나
HTML	문서 구조, 파싱 방법, 브라우저가 스크립트에 내주는 기능 대부분
DOM	페이지를 트리로 다루는 객체와 이벤트
Fetch	네트워크 요청을 보내는 절차, CORS(Cross-Origin Resource Sharing) 확인
URL(Uniform Resource Locator)	주소 문자열을 해석하는 방법
Encoding	바이트를 글자로 바꾸는 문자 인코딩 이름과 규칙
Streams	데이터를 조각으로 흘려 읽고 쓰는 방법

표의 CORS 는 다른 출처로 보내는 요청을 브라우저가 허락할지 정하는 규칙입니다. 서버가 Access-Control-Allow-Origin 헤더를 왜 보내야 하는지가 Fetch 문서에 있습니다.

백엔드 코드에서 만나는 WHATWG

브라우저 밖에서도 이 표준을 따르는 코드가 있습니다. Node.js 의 URL 클래스가 WHATWG URL 표준대로 주소를 해석합니다. 주소 맨 앞에서 http 처럼 방식을 적는 부분을 스킴이라고 합니다. 아래 코드는 대문자 스킴과 .. 경로가 어떻게 정리되는지 보입니다.

JavaScript

const u = new URL("HTTP://a.com/x/../y");
u.href      // "http://a.com/y"
u.pathname  // "/y"

스킴은 소문자로 바뀌었습니다. x/../ 는 지워졌습니다.

URL 규칙은 이것 하나가 아닙니다. IETF(Internet Engineering Task Force)가 따로 낸 URL 규칙이 RFC 3986(Request for Comments 3986)입니다. 두 규칙은 틀린 주소를 다루는 방식에서 갈립니다.

예를 들어 WHATWG URL 은 http 주소 안의 역슬래시(\)를 / 처럼 읽습니다. RFC 3986 에서 역슬래시는 주소에 쓸 수 없는 글자라, 이 규칙을 따르는 해석기는 오류로 보거나 다르게 처리합니다.

JavaScript

new URL("http://a.com\\b").pathname // "/b"

주소를 검사하는 코드와 요청을 보내는 코드가 서로 다른 해석기를 쓰면, 검사를 통과한 주소가 실제로는 다른 곳으로 요청을 보낼 수 있습니다. 그래서 두 코드가 같은 해석기를 쓰는지 확인해야 합니다.

WHATWG

상세

생겨난 까닭

Living Standard

W3C 와의 관계

관리하는 표준 문서

백엔드 코드에서 만나는 WHATWG

관련 항목

WHATWG 가 관리하는 표준 문서

WHATWG 의 작업 방식을 이루는 개념

웹 표준을 함께 만드는 표준화 기구

이 표준을 따르는 구현체

이 표준 문서들이 다루는 웹 기술