HTML Living Standard

HTML Living Standard 는 웹 페이지를 적는 법과 브라우저가 그 페이지를 읽는 법을 정합니다. 태그 하나의 뜻부터 잘못 적힌 페이지를 고쳐 읽는 절차까지 한 문서에 담습니다. 판 번호를 붙여 마무리하지 않고 같은 문서를 계속 고쳐 씁니다. 주요 브라우저는 모두 이 문서를 기준으로 페이지를 처리합니다.

쉽고 빠른 이해

웹 페이지를 어떻게 적고 브라우저가 그것을 어떻게 다뤄야 하는지 적은 규칙 문서입니다. 닫는 태그를 빠뜨린 문단을 만났을 때 브라우저가 문단을 어디서 끊는지도 여기 적혀 있습니다.

이 문서가 없으면 브라우저마다 같은 페이지를 다르게 읽습니다. 예전에는 브라우저를 만드는 회사들이 남의 브라우저에 페이지를 넣어 보고 결과를 따라 맞춰야 했습니다.

이렇게 돕니다.

브라우저를 만드는 회사들이 한 문서를 함께 고칩니다
고친 내용은 판 번호 없이 곧바로 표준에 들어갑니다
표준과 브라우저 동작이 어긋나면 어느 쪽이든 고쳐 맞춥니다

대가도 있습니다. 표준이 늘 바뀌므로 「어느 판을 지켰다」고 못 박기 어렵습니다.

처음 배울 때는 해설서를 읽습니다. 이 표준은 브라우저 동작을 따져야 할 때, 해설서끼리 설명이 갈릴 때 폅니다.

상세

HTML(HyperText Markup Language, 하이퍼텍스트 마크업 언어)은 웹 페이지를 적는 언어입니다.  나 <img> 처럼 꺾쇠괄호로 감싼 태그를 붙여 글의 각 부분이 무엇인지 표시합니다. HTML Living Standard 는 이 언어의 규칙을 정한 표준 문서입니다.

이 표준을 관리하는 곳은 WHATWG(Web Hypertext Application Technology Working Group)입니다. WHATWG 는 브라우저를 만드는 회사들이 중심이 되어 웹 표준을 쓰는 모임입니다. 브라우저는 서버에서 페이지를 받아 화면에 그려 주는 프로그램입니다.

이 절은 여섯 소절입니다. 앞의 셋이 이 표준의 뼈대입니다. 판 번호 없이 굴러가는 방식, HTML 문서를 쓰는 사람과 브라우저에게 따로 거는 요구, 잘못 적힌 HTML 문서를 읽는 규칙입니다. 뒤의 셋은 이 표준이 정하는 범위, W3C 와 갈라졌다 다시 합친 내력, 이 표준을 펴는 때를 봅니다.

판 번호가 없는 표준

표준 문서는 흔히 판 번호를 붙여 내놓습니다. 한 판을 마치면 그 판은 더 고치지 않고, 바꿀 것은 다음 판에 모읍니다. HTML 도 한때 HTML4 처럼 번호가 붙은 판으로 나왔습니다.

Living Standard(살아 있는 표준)는 이 방식을 버립니다. 표준 문서는 하나뿐입니다. 고칠 것이 생기면 그 문서를 바로 고칩니다. 첫머리에는 판 번호 대신 마지막으로 고친 날짜가 붙습니다.

이렇게 하는 까닭은 브라우저가 쉬지 않고 새 버전을 내놓기 때문입니다. 몇 년에 한 번 판을 묶으면 그 사이에 브라우저 동작과 표준이 벌어집니다. 알려진 문제를 안은 채로 판을 얼려 두는 일도 생깁니다. 늘 고쳐 쓰는 표준은 이 간격을 좁힙니다.

흔히 듣는 HTML5(HTML 다섯 번째 판)는 원래 HTML4 다음 판의 이름이었습니다. 그 판을 만들던 작업이 판을 매기지 않는 이 표준으로 이어졌습니다. 어떻게 이어졌는지는 아래 「W3C 와 갈라졌다 다시 합친 내력」 소절에서 봅니다.

그래서 좁게 말하면 이 표준이 곧 HTML5 입니다. 넓게는 요즘 웹 기술을 두루 부르는 유행어로도 쓰입니다.

판이 없으니 기준 시점이 흐려집니다. 「HTML 표준을 지켰다」고 말하려면 어느 날짜의 표준인지를 함께 대야 합니다. 그래서 WHATWG 는 법적 검토처럼 고정된 문서가 필요한 일에 쓰려고, 날짜를 박은 사본을 정기적으로 따로 남깁니다.

HTML 문서를 쓰는 쪽과 읽는 쪽

이 표준은 요구를 두 독자에게 나눠 겁니다. 한쪽은 HTML 문서를 쓰는 사람입니다. 그 문서를 만들어 내는 Thymeleaf · Jinja 같은 템플릿 엔진도 여기 듭니다. 다른 쪽은 HTML 문서를 받아 처리하는 브라우저입니다.

쓰는 쪽에 거는 요구는 「이렇게 써야 올바른 HTML 문서다」입니다. 이미지를 넣는 <img> 태그에 alt 속성을 붙이는 것이 한 예입니다. 속성은 태그 안에 이름="값" 꼴로 덧붙이는 정보입니다. alt 에는 이미지를 볼 수 없는 사람에게 대신 읽어 줄 글인 대체 텍스트를 담습니다.

이런 요구를 모두 지킨 문서를 적합한 문서(conforming document)라고 부릅니다. 적합한지는 HTML 검사기에 HTML 문서를 넣어 확인합니다. 검사기는 쓰는 쪽 요구를 어긴 줄을 찾아 알려 줍니다.

읽는 쪽에 거는 요구는 「받은 문서를 이렇게 처리해라」입니다. 여기에는 적합하지 않은 문서를 받았을 때의 처리까지 들어 있습니다. 브라우저는 틀린 문서라고 거절하지 않습니다. 정해진 절차대로 고쳐 읽습니다.

틀린 문서도 어차피 읽힌다면 쓰는 쪽 요구는 왜 두나 싶습니다. 브라우저마다 같게 읽히는 것만이 목표가 아니기 때문입니다. 올바르게 쓴 문서는 화면을 소리로 읽어 주는 스크린 리더도 제대로 다룹니다. 이것이 접근성입니다.

요구의 세기는 must · should · may 같은 낱말로 나타냅니다. must 는 어기면 표준을 안 지킨 것입니다. should 는 까닭이 있으면 따르지 않아도 됩니다. may 는 해도 되고 안 해도 되는 것입니다.

이 낱말들의 뜻은 RFC 2119(Request for Comments 2119) 를 따릅니다. RFC 는 인터넷 표준을 싣는 문서 묶음입니다.

잘못 적힌 HTML 문서를 읽는 규칙

이 소절은 브라우저가 받은 바이트를 문서 트리로 바꾸는 과정을 봅니다. 닫지 않은 태그가 든 문서 하나를 가지고 따라갑니다.

웹에는 닫는 태그를 빠뜨리거나 순서를 뒤섞은 페이지가 많습니다. 예전 표준은 올바른 문서를 읽는 법만 정했습니다. 틀린 문서를 읽는 법은 브라우저마다 따로 정했습니다. 다른 브라우저와 맞추려면 서로의 동작을 뜯어보며 흉내 내야 했습니다.

HTML Living Standard 는 틀린 문서의 처리까지 한 단계씩 정합니다. 어떤 바이트가 들어와도 결과로 나오는 트리가 하나로 정해집니다. 그래서 같은 페이지를 어느 브라우저에서 열어도 같은 트리가 나옵니다.

문서를 읽어 구조를 뽑아내는 일을 파싱이라 합니다. 그 일을 하는 부품이 파서입니다. HTML 파서는 네 단계를 거칩니다.

인코딩 판별 — 바이트가 어떤 문자 인코딩으로 적혔는지 알아내 문자로 바꿉니다. 문자 인코딩은 글자를 바이트로 적는 약속입니다
토큰화 — 문자를 여는 태그, 닫는 태그, 글자 조각으로 끊습니다
트리 구성 — 끊은 조각을 부모와 자식으로 이어 나무 모양으로 쌓습니다. 빠진 태그를 채우고 순서를 바로잡는 일은 대부분 이 단계에서 합니다
DOM 완성 — 쌓은 트리가 DOM(Document Object Model, 문서 객체 모델)이 됩니다. DOM 은 JavaScript 가 읽고 고칠 수 있는 문서 트리입니다

1단계에서 인코딩을 알아내는 단서는 두 곳에 있습니다. 하나는 서버가 응답에 붙이는 Content-Type 헤더의 charset 입니다. 다른 하나는 HTML 문서 앞부분에 적는 <meta charset="utf-8"> 같은 선언입니다. 이 선언을 meta charset 이라 부릅니다.

아래 문서에는 <html> · <head> · <body> 가 하나도 없습니다. 첫  는 닫히지도 않았습니다.

HTML

<title>메모</title>
<p>첫째<p>둘째

파서는 빠진 세 태그를 채워 넣습니다. 둘째  를 만나는 순간 첫째 문단을 닫습니다.  안에는 다른  가 들어갈 수 없기 때문입니다. 그렇게 쌓인 트리는 이렇습니다.

flowchart TD
    H["html"] --> HE["head"]
    H --> B["body"]
    HE --> T["title · 메모"]
    B --> P1["p · 첫째"]
    B --> P2["p · 둘째"]

스크립트로 세어 보면 같은 모양이 나옵니다. document 는 브라우저가 DOM 을 스크립트에 내주는 입구입니다.

JavaScript

document.head.children.length  // 1
document.body.children.length  // 2

head 아래에는 title 하나가, body 아래에는 문단 둘이 있다는 뜻입니다. 파서가 채운 태그와 닫은 문단이 그대로 트리에 들어갔습니다.

이 표준이 정하는 범위

이름만 보면 태그 목록을 모은 문서 같지만 범위가 훨씬 넓습니다. 페이지가 브라우저 안에서 도는 방식 대부분이 여기 들어 있습니다. 큰 대목만 추리면 아래와 같습니다.

대목	정하는 것	예
요소와 속성	어떤 태그가 있고 무슨 뜻이며 어디에 넣을 수 있나	`<img>` 의 `alt`
문서 읽기(파싱)	바이트를 DOM 으로 바꾸는 절차	닫지 않은 `<p>` 의 처리
인코딩 선언	HTML 문서가 자기 인코딩을 알리는 법	`<meta charset="utf-8">`
폼 제출	입력값을 요청 본문에 싣는 법	`enctype` 속성
스크립트 실행	스크립트와 이벤트를 어떤 순서로 돌리나	이벤트 루프
브라우저 저장	페이지가 값을 남겨 두는 곳	localStorage

백엔드 개발자가 자주 만나는 대목은 두 가지입니다. 서버가 내려보내는 HTML 의 인코딩 선언, 그리고 폼이 보내오는 요청 본문의 모양입니다. enctype 은 폼이 입력값을 어떤 꼴로 실어 보낼지 정하는 속성입니다. 이 속성을 적지 않으면 입력값은 name=kim&age=30 처럼 & 로 이어진 꼴로 옵니다.

이 표준이 모든 것을 혼자 정하지는 않습니다. 기초가 되는 규칙은 다른 표준 문서에서 가져다 씁니다.

가져다 쓰는 표준	맡는 것
DOM Standard	위 파싱이 만든 문서 트리, 곧 DOM 의 기본 구조와 그것을 고치는 법
WHATWG Encoding Standard	인코딩 이름과 바이트를 문자로 푸는 법
URL Standard	주소를 해석하는 법
Fetch Standard	네트워크로 자원을 가져오는 법
ECMAScript	스크립트 언어 자체의 문법과 동작

위 넷은 WHATWG 가 함께 관리하는 문서입니다. ECMAScript 는 다른 단체가 정합니다. HTML Living Standard 는 이 표준들을 이름으로 불러 씁니다. 그래서 인코딩 이름 하나를 확인하려면 Encoding Standard 를 펴야 합니다.

W3C 와 갈라졌다 다시 합친 내력

W3C(World Wide Web Consortium)는 웹 표준을 만드는 또 다른 단체입니다. HTML4 까지는 W3C 가 HTML 을 맡았습니다. 그 뒤 W3C 는 HTML 을 더 키우지 않기로 했습니다. 대신 XML(Extensible Markup Language, 확장 가능한 마크업 언어) 문법을 따르는 XHTML(Extensible HyperText Markup Language)로 옮겨 가려 했습니다.

Mozilla 와 Opera 가 HTML 을 계속 키우자는 제안을 W3C 에 냈지만 받아들여지지 않았습니다. 그러자 2004년 Apple · Mozilla · Opera 가 WHATWG 를 세워 작업을 이어 갔습니다. 이들이 내건 원칙은 셋입니다.

이미 있는 페이지를 깨뜨리지 않습니다
표준과 브라우저 동작이 어긋나면, 브라우저 대신 표준을 고치는 한이 있어도 둘을 맞춥니다
서로 흉내 내지 않고도 똑같이 구현할 수 있을 만큼 자세히 적습니다

W3C 는 몇 해 뒤 방향을 바꿔 WHATWG 의 작업을 받아들였습니다. 한동안은 두 곳이 그 작업을 바탕으로 HTML5 를 함께 만들었습니다. 목표가 다시 갈린 것은 W3C 가 「다 된」 HTML5 를 판으로 묶어 내려 했기 때문입니다. WHATWG 는 판을 얼리지 않고 계속 고쳐 가기를 바랐습니다.

그 뒤 두 곳이 비슷한 HTML 표준을 따로 내는 때가 이어졌습니다. 나중에 두 단체는 앞으로 HTML 표준을 하나만 두기로 합의했습니다. 그 하나가 HTML Living Standard 입니다.

이 표준을 펴는 때

이 표준은 웹을 처음 배우는 용도로는 맞지 않습니다. 정확하게 쓰려고 읽기 쉬움을 양보한 문서이기 때문입니다. 입문용 해설서는 따로 있습니다. MDN Web Docs 가 그런 해설서입니다.

이 표준을 펴는 것은 동작을 따져야 할 때입니다. 브라우저가 어떤 인코딩으로 페이지를 읽을지, 폼이 어떤 본문을 보낼지, 틀린 마크업이 어떤 트리가 될지가 그렇습니다. 해설서끼리 설명이 갈릴 때 판정을 내려 주는 문서가 이것입니다.

표준에 있다고 모든 브라우저가 이미 구현한 것은 아닙니다. 새 기능이 표준에 먼저 들어가기도 합니다. 브라우저 구현은 그 뒤를 따릅니다. 브라우저별 지원 여부는 호환성 표에서 따로 확인합니다.

HTML Living Standard

상세

판 번호가 없는 표준

HTML 문서를 쓰는 쪽과 읽는 쪽

잘못 적힌 HTML 문서를 읽는 규칙

이 표준이 정하는 범위

W3C 와 갈라졌다 다시 합친 내력

이 표준을 펴는 때

관련 항목

이 표준을 관리하는 표준 단체

이 표준이 기대어 쓰는 표준 문서

이 표준이 규칙을 정하는 언어와 문법

이 표준이 정하는 브라우저 동작과 그 결과

문서의 문자 인코딩을 알리는 수단

이 표준 위에 얹히는 웹 기술

이 표준을 구현하거나 검사하는 프로그램

이 표준이 지키려는 성질