HTML 5.1

1. 소개

1.1. 배경

이 섹션은 비규범적입니다.

HTML은 월드 와이드 웹의 핵심 마크업 언어입니다. 본래, HTML은 주로 의미론적으로 체계적인 문서를 기술하기 위한 언어로서 설계되었습니다. 그러나, 그것의 일반적인 설계는 이후 몇 년간 다수의 문서와 심지어 어플리케이션을 기술하기 위해 응용될 수 있도록 되었습니다.

1.2. 독자

이 섹션은 비규범적입니다.

이 명세는 이 명세에 정의된 특징을 사용하는 문서와 스크립트의 작성자들과, 이 명세에 정의된 특징을 사용하는 페이지에서 동작하는 도구의 구현자들과, 문서의 정확성이나 이 명세의 요구의 필요성에 대한 구현을 확인하기 원하는 개개인을 위해 의도된 것입니다.

이 문서는 정확성을 위해 명료성을, 그리고 완정성을 위해 간결성을 희생시키기 때문에 적어도 웹 기술 들에 익숙하지 않은 독자들에게는 적합하지 않을 것입니다. 좀 더 이해하기 쉬운 튜토리얼과 작성 가이드들이 그 주제에 적당한 소개를 제공할 수 있습니다.

특히, 이 명세의 약간의 좀 더 기술적인 부분의 완전한 이해를 위해 DOM의 기초에 익숙함이 필요합니다. 웹 IDL, HTTP, XML, 유니코드, 문자 인코딩, 자바스크립트, CSS의 이해 역시 곳곳에서 도움이 되겠지만 필수는 아닙니다.

1.3. 범위

이 섹션은 비규범적입니다.

이 명세는 범위가 정적 문서로부터 동적 어플리케이션까지에 이르는 웹 상의 접근 가능한 페이지를 작성하기 위한 시맨틱 레벨 마크업 언어와 연관된 시맨틱 레벨 스크립팅 API들을 제공하는데 제한됩니다.

이 명세의 범위는 표현의 매체 별 사용자정의에 대한 메커니즘을 제공하는 것을 포함하지 않습니다. (웹 브라우저에 대한 기본 렌더링 규칙이 이 명세의 마지막에 포함되어 있고, CSS로 후킹을 위한 몇 몇 메커니즘이 언어의 일부로서 제공되어 있기는 하지만.)

이 명세의 범위는 전체 운영 체제를 설명하는 것이 아닙니다. 특히, 하드웨어 구성 소프트웨어, 이미지 편집 툴, 날마다 하이엔드 워크스테이션을 가지고 사용할 것으로 예상되는 응용프로그램들은 범위 밖입니다. 응용프로그램의 관점에서, 이 명세는 특히 비정기적으로 사용자들에 의해 사용될 것으로 예상되거나, 정기적이나 다른 위치에서 사용될 것으로 예상되는, 낮은 CPU가 필요한 응용프로그램을 대상으로 합니다. 그러한 응용 프로그램들의 예로는, 온라인 구매 시스템, 검색 시스템, 게임(특히 멀티플레이어 온라인 게임), 전화번호부나 주소책, 통신용 소프트웨어 (이메일 클라이언트, 인스턴트 메세지 클라이언트, 디스커션 소프트웨어), 문서 편집 소프트웨어, 기타 등등 입니다.

1.4. 연혁

이 섹션은 비규범적입니다.

첫 5년 동안(1990-1995), HTML은 처음 CERN에서, 그리고 이후 IETF에서 주로 주최되어 다수의 개정이 이루어졌고 다수의 확장을 겪었습니다.

W3C의 창설과 함께, HTML의 개발은 다시 위치가 변경되었습니다. HTML 3.0으로 알려진 1995년의 HTML 확장에 첫 번째 실패 이후 HTML3.2로 알려진 좀 더 실용적인 접근 방법을 만들었고, 그것이 1997년에 완성되었습니다. HTML 4.01이 빠르게 같은 해에 뒤따랐습니다.

그 다음 해, W3C 회원들은 HTML을 발전시키는 것을 중단하고 대신 XHTML이라 불리는 XML 기반의 동등한 것에 착수하기로 결정했습니다. 이러한 노력은 XHTML 1.0 으로 알려진, XML에서 HTML 4.01의 재구성을 시작하였고, 새로운 직렬화를 제외하고 새로운 기능을 추가하지 않고, 2000년에 완료되었습니다. XHTML 1.0 이후, W3C의 관심은 XHTML 모듈화의 기치 아래, XHTML을 확장하기 위한 다른 작업 그룹을 쉽게 하는 것으로 바뀌었습니다. 이와 병행하여, W3C는 또한 XHTML 2.0이라 불리는 이전의 HTML과 XHTML언어와 호환이 되지 않는 새로운 언어에 착수했습니다.

1998년 HTML의 발전이 종료된 당시에, 브라우저 벤더들에 의해 개발된 HTML에 대한 API의 일부가 DOM Level 1 (1998년), DOM Level 2 Core와 DOM Level HTML (2000년에 시작하여 2003년에 절정에 달하는)라는 이름으로 명세화되고 발행되었습니다. 이러한 노력은 이후 2004년에 몇몇의 DOM Level 3 명세가 발행되었지만 모든 Level 3 초안이 완성되기 전에 작업 그룹이 종료 됨과 함께 점차 작아졌습니다.

2003년, 웹 양식의 다음 세대로 자리잡은 기술인 XForms의 발표는 HTML에 대한 대체품을 찾는 것보다 HTML 자체를 발전시키는 것에 새로워진 관심을 촉발시켰습니다. 이 관심은 웹 기술로서 XML의 발전이 기존의 배포된 기술(HTML 같은)에 대한 대체품으로서 보다, 완전히 새로운 기술(RSS와 이후 Atom 같은)로 제한되는 것에서부터 나타났습니다.

Xforms 1.0이 도입한 많은 기능들을 제공하기 위해 HTML4.01의 양식들을 확장하는 것이 기존의 HTML 웹 페이지와 맞지 않는 렌더링 엔진을 구현하기 위해 브라우저 없이도 가능하다는 것을 보여주는 개념의 증명은 이 새로운 관심사의 첫 결과물이었습니다. 초기 단계에, 초안이 이미 공개적으로 사용 가능했고 정보가 이미 모든 자료들로부터 얻어지고 있었던 반면, 명세는 오직 오페라 소프트웨어의 저작권 아래에 있었습니다.

HTML의 발전이 재개되어야 한다는 아이디어가 2004년 W3C 워크샵에서 검토되었고, 여기서 양식 관련 기능을 대신하는 앞서 언급된 기존의 초안 제안 뿐 아니라, HTML 작업의 기저(아래 설명 된)를 이루는 몇 몇 원칙들이 모질라와 오페라에 의해 공동으로 W3C에 소개되었습니다. 이 제안은 착수되지 않았습니다; 반대자들은 이전에 선택된 웹의 발전에 대한 방향과 충돌된다고 주장했습니다; 대신 W3C는 XML 기반의 대체품 개발을 지속했습니다.

이후 얼마 되지 않아, 애플, 모질라, 오페라가 공동으로 WHATWG라고 불리는 새로운 무대에서 계속하여 노력을 기울일 것을 발표했습니다. 공동 메일링 리스트가 생성되었고, 초안이 WHATWG 사이트로 이관되었습니다. 이후 저작권이 세 벤더들에 의해 공동으로 소유되고 명세의 재사용이 허용되도록 개정되었습니다.

WAHTWG는 몇 가지 핵심 원칙, 특히 기술은 이전과 호환 되어야할 필요가 있고, 명세들과 구현은 구현보다 명세 변경을 의도한다하더라도 일치해야 할 필요가 있으며, 그 명세는 각각의 리버스 엔지니어링 없이 완벽히 상호 운용성을 달성할 수 있도록 충분히 자세해야 할 필요가 있음 등에 근거합니다.

특히 후자의 요구 사항은 HTML 명세의 범위가 세 가지 분리 된 문서: HTML 4.01, XHTML 1.1, DOM Level 2 HTML에 이전에 명시된 것들을 포함할 것을 요구 되었습니다. 이는 또한 이전에 고려된 규범들보다 좀 더 상당히 상세한 것을 포함할 것을 의미합니다.

2006년에, 마침내 W3C는 HTML 5.0의 개발에 참여하는 것에 관심을 나타냈고, 2007년에 HTML 명세의 개발에 WHATWG와 함께 작업하기 위해 인가된 워킹 그룹이 형성되었습니다. 애플, 모질라, 오페라는 WAHTWG 사이트에 제한이 적은 라이센스를 가진 버전을 유지하는 동시에, W3C가 W3C 저작권 하에 명세를 발행하는 것을 허용했습니다.

수 년간, 이후 두 그룹은 동일한 편집자 하에 함께 작업하였습니다: Ian Hickson. 2011년에, 그룹들은 서로 다른 목표를 가지고 있다는 결론에 도달했습니다: W3C는 HTML 5.0 권고안에 대한 기능을 분명히 선을 긋기를 원한 반면, WHATWG는 계속적으로 명세를 유지하고 새로운 기능을 추가하여 HTML에 대해 라이브 표준에 작업이 계속되기를 원했습니다. 2012년 중반에, HTML 5.0 권고안 생성을 책임지고 다음 HTML 버전에 대한 규격 초안을 준비하기 위한 새로운 편집 팀이 W3C에 도입되었습니다.

그때부터, W3C HTML WG는 W3C HTML 명세에 등록되거나 유저 에이전트들에 실제 구현되어 좀 더 정밀하게 나타난 버그들이 해결된 것을 WHATWG로부터 패치를 체리 피킹하고 있습니다.이 문서의 발행 시점에, WHATWG HTML 명세로부터 패치들은 2016년 1월 12일까지 병합되었습니다. W3C HTML 편집자들은 또한 WHATWG에 의해 공유되지 않은 버그들로부터 버그 수정한 것 뿐 아니라 W3C HTML WG에 의해 만들어진 논의와 결정으로 나온 패치들을 추가하였습니다.

별도의 문서에 이 문서에 명시된 HTML과 HTML 4.01 명세 내 설명된 언어 사이의 다른점이 발행되었습니다. [HTML5-DIFF]

1.5. 설계 노트

이 섹션은 비규범적입니다.

HTML의 많은 측면들이 첫 눈에 무의미하고 규범에 맞지 않게 보일 수 있음을 인정해야 합니다.

HTML, HTML의 지원 DOM API들 뿐 아니라 많은 HTML의 지원 기술들은 서로 다른 우선권들을 가진, 많은 경우 서로의 존재를 모르는 다수의 사람들에 의해 몇 십년 동안 개발되어 왔습니다.

이 기능들은 이와 같이 많은 자료들로부터 생겨났고, 특히 일관된 방법으로 항상 설계되지 않았습니다. 뿐만 아니라, 웹의 고유한 특징들 때문에 구현 버그는 콘텐트가 종종 그 버그들이 해결될 수 있기 전에 그것들에 의존하여 그 방법으로 무심결에 작성되기 때문에 종종 사실 상의 그리고 정식 표준이 되었습니다.

그럼에도 불구하고, 노력은 명확한 설계 목적을 충실히 지켜져 왔습니다. 이것들은 다음 몇 세부항목에 기술됩니다.

1.5.1. 스크립트 실행의 직렬화

이 섹션은 비규범적입니다.

웹 작성자를 멀티스레딩의 복잡도에 노출되지 않도록 하기 위해, HTML과 DOM API들은 다른 스크립트들의 동시 실행을 감지하는 스크립트가 없도록 설계됩니다. 심지어 workers에도, 의도는 모든 브라우징 컨텍스트의 모든 스크립트의 실행이 완전히 직렬화 하는 것으로 고려될 수 있는 구현의 반응입니다.

1.5.2. 다른 명세 준수

이 섹션은 비규범적입니다.

이 명세는 매우 다양한 다른 명세들과 상호 작용하며 이들을 필요로 합니다. 불행하게도, 특정 상황에서 상반되는 요구들은 이 명세가 이러한 다른 명세들의 요구 사항들을 위반하는 것으로 이어집니다. 이것이 발생될 때마다, 위반은 "고의적인 위반"으로 언급되고, 위반에 대한 이유가 언급됩니다.

1.5.3. 확장성

이 섹션은 비규범적입니다.

HTML은 안전한 방법으로 의미(semantics)를 추가하기 위해 사용될 수 있는 다수의 확장성 메커니즘을 가집니다:

• 작성자는 요소를 확장하기 위해 가장 적절한 기존의 "실제" HTML 요소를 사용하면서 효과적으로 요소들을 생성하여, class 속성(attribute)를 사용할 수 있기 때문에, 브라우저들과 확장에 관해 알지 못하는 다른 툴들이 여전히 어느 정도 잘 지원할 수 있습니다. 예를 들어, 이것은 마이크로포맷에 의해 사용되는 방침입니다.

• 작성자는 data-*="" 속성(attirbute)를 사용하여 인라인 클라이언트 사이드 스크립트나 서버 사이드 사이트 전체 스크립트가 처리하기 위한 데이터를 포함할 수 있습니다. 이는 브라우저에 의해 결코 수정되지 않음이 보장되고, 스크립트가 찾고 처리할 수 있는 HTML 요소의 데이터를 포함하는 것을 허용합니다.

• 작성자는 메타데이터 이름들의 미리 정의된 세트 확장을 등록하여 페이지 전체 메타데이터를 포함하기 위해 meta name="" content="" 메커니즘을 사용할 수 있습니다.

• 작성자는 링크 유형의 미리 정의된 세트 확장을 등록하여 링크에 특정 의미(meanings)를 가진 주석을 달기 위해 rel="" 메커니즘을 사용할 수 있습니다.

• 작성자는 인라인이나 서버 사이드 스크립트로 추가 처리를 위해, 커스텀 유형을 가진 script type="" 메커니즘을 사용하여 원시 데이터를 끼워 넣을 수 있습니다.

• 작성자는 embed 요소를 사용하여 플러그인을 생성하고 그것들을 작동시킬 수 있습니다. 이것이 플래시(Flash)가 작동하는 방법입니다.

• 작성자는 자바스크립트 프로토타이핑 메커니즘을 사용하여 API들을 확장할 수 있습니다. 예를 들어, 이것은 스크립트 라이브러리에서 폭넓게 사용됩니다.

1.6. HTML vs XHTML

이 섹션은 비규범적입니다.

이 명세는 문서와 어플리케이션을 기술하기 위해 추상적인 언어와 이 언어에서 사용하는 리소스의 메모리 내부 표현과 상호작용을 위한 몇 API들을 정의합니다.

메모리 내부 표현은 "DOM HTML", 혹은 요약하여 "DOM"으로 알려져 있습니다.

이 추상적인 언어를 사용하는 리소스를 전송하는데 사용될 수 있는 여러 구체적인 구문이 있는데, 이 명세에서 정의되는 것이 두 가지입니다.

그 첫 번째 구문은 HTML 구문입니다. 이것은 대다수 작성자에게 권장되는 형식입니다. 대다수 레거시 웹 브라우저들과 호환됩니다. 브라우저가 text/html MIME 타입으로 전송된다면, 웹 브라우저들에 의해 HTML 문서로 처리 될 것입니다. 이 명세는 "HTML 5.1"로 알려진 HTML 문법의 가장 최근 버전을 정의합니다.

두 번째 구문은 XHTML 구문이고, 이것은 XML의 적용입니다. 문서가 application/xhtml+xml와 같은, XML MIME 타입으로 전송된다면, XML 처리기에 의해 해석되기 위해, 웹 브라우저들에 의해 XML 문서로 취급됩니다. 작성자는 XML과 HTML에 대한 처리가 다름을 상기해야 합니다; 특히, HTML 구문에서는 무시될 사소한 구문 오류 조차 XML로 분류된 문서가 완전히 렌더링 되는 것을 방해할 것입니다. 이 명세는 "XHTML 5.1"로 알려진, XHTML 구문의 최신 버전을 정의합니다.

DOM, HTML 구문, XHTML 구문은 모두 동일한 콘텐트를 나타낼 수 없습니다. 예를 들어, 네임스페이스는 HTML 구문을 사용하여 표현될 수 없지만, DOM과 XHTML 구문에서는 지원됩니다. 비슷하게, noscript 기능을 사용하는 문서는 HTML 구문을 사용하여 표현될 수 있지만, DOM과 XHTML 구문에서는 표현될 수 없습니다. 문자열 "-->"를 포함한 주석은 HTML, XHTML 구문에서는 사용할 수 없고 오직 DOM에서만 표현될 수 있습니다.

1.7. 이 명세의 구조

이 섹션은 비규범적입니다.

이 명세는 다음 주요 섹션들로 나뉘어 있습니다:

1.7.1. 이 명세를 읽는 방법

이 명세는 모든 다른 명세들처럼 읽어야(should) 합니다. 먼저, 처음부터 끝까지, 여러 번 읽어야(should) 합니다. 그 후, 적어도 한 번은 거꾸로 읽어야(should) 합니다. 그리고 나서 콘텐트 리스트에서 임의의 섹션을 고르고 모든 상호 참조를 따라서 읽어야(should) 합니다.

아래 적합성 요구 사항 섹션에서 설명된대로, 이 명세는 여러 적합성 클래스들에 대한 적합성 기준을 설명합니다. 특히, 제작자, 예를 들어 작성자와 그들이 만드는 문서에 적용되는 적합성 요구 사항이 있고, 소비자, 예를 들어 웹 브라우저들에 적용되는 적합성 요구 사항이 있습니다. 이것들은 요구하는 것에 의해 구별될 수 있습니다: 소비자 입장에서 요구 사항은 소프트웨어가 어떻게 동작해야 하는가인 반면, 제작자 입장에서 요구 사항은 무엇이 허용되는가 입니다.

생산자에 대한 요구 사항은 소비자에 아무런 관련이 없습니다.

1.7.2. 표기법

interface Example {
    // 이것은 IDL 정의입니다.
};

/* 이것은 CSS 코드 조각입니다. */

1.8. 개인 정보 보호

이 섹션은 비규범적입니다.

HTML의 일부 기능은 사용자 개인 정보의 정책과 사용자 편의를 맞바꿉니다.

일반적으로, 인터넷의 아키텍쳐 때문에, 사용자는 사용자의 IP 주소에 따라 서로 구별 될 수 있습니다. IP 주소는 사용자와 전적으로 일치하지 않습니다; 사용자는 디바이스에서 디바이스로, 혹은 네트워크에서 네트워크로 이동하기 때문에, IP 주소는 변화합니다; 비슷하게, NAT 라우팅, 프록시 서버, 공유 컴퓨터는 단일 IP 주소로부터 오는 모든 것이 실제로는 여러 사용자에게 대응하는 것으로 나타나는 패킷이 가능하게 합니다. 어니언 라우팅 같은 기술은 인터넷의 한 노드에서 단일 사용자로부터의 요청이 네트워크의 많은 다른 부분으로부터 오는 것으로 나타내기 위해 요청을 더욱 익명으로 하는 데 사용될 수 있습니다.

그러나, 사용자의 요청에 사용되는 IP 주소는 사용자의 요청이 서로 연관 될 수 있는 유일한 메커니즘은 아닙니다.

예를 들어, 쿠키는 이것이 가능하도록 특별히 설계되었고, 이것은 계정을 가지고 있는 사이트에서 로그인 하는 것을 가능하게 하는 대다수 웹 세션 기능의 근간입니다.

응용프로그램 캐시는 개인정보에 대하여 비슷한 방향을 가집니다. 예를 들어 캐시를 제공할 때 사이트가 사용자를 식별할 수 있다면, 캐시에 쿠키 부활에 사용될 수 있는 데이터를 저장할 수 있습니다.

좀 더 영리한 다른 메커니즘이 있습니다. 사용자의 시스템의 어떤 특성은 각각으로부터 사용자 그룹을 구별하는데 사용될 수 있습니다; 그러한 정보를 충분히 수집함으로써, 개인 사용자의 브라우저의 "디지털 지문"은 계산될 수 있고, 이것은 동일한 사용자로부터 요청을 확인하는 방법으로 IP 주소로는 아니더라도 더 좋을 수 있습니다.

이 방법으로 요청을 그룹핑하는 것은, 특히 여러 사이트에 걸쳐, 악의적인 목적 뿐 아니라, 모두 유익한 (그리고 거의 틀림없이 긍정적인) 목적으로 사용될 수 있습니다. 상당히 유익한 목적의 예는 특정한 사람이 강아지 삽화가 있는 사이트를 선호하는 것 같이 보이는지 반대로 고양이 삽화가 있는 사이트를 선호하는 것 같이 보이는지 여부를 결정하고(그들이 해당 사이트를 방문하는 빈도에 기반하여) 그 후 연관된 사이트에 차후 방문 시 선호된 삽화를 자동으로 사용하도록 하는 것일 것입니다. 그러나, 악의적인 목적은 선거에서 어떤 이가 투표하는 것을 막을 것인지를 결정하기 위해 그 사람의 집 주소(사이트에서 운전 경로를 얻을 때 사용하는 주소로부터 알아낸)와 같은 정보와 그들의 분명한 정당 소속(그가 참여한 포럼 사이트를 조사하여 알아낸) 정보를 결합하는 조직을 포함할 수 있습니다.

악의적인 목적은 매우 악랄할 수 있기 때문에, 유저 에이전트 구현자들은 사용자의 지문을 채취하는데 사용될 수 있는 유출되는 정보를 최소화 하는 툴을 가지고 사용자에게 제공하는 방법을 고려하는 것이 권장됩니다.

아쉽게도, 이 섹션의 첫 문단이 의미하듯이, 때때로 지문을 채취하는 목적으로 사용될 수 있는 바로 그 정보를 노출하여 말미암는 대단한 이익들이 종종 있기 때문에, 모든 가능한 유출을 간단히 막는 것은 아주 손쉬운 것은 아닙니다. 예를 들어, 특정 ID로 게시하는 사이트에 로그인 할 수 있는 기능은 동일한 사용자로부터의 모든 사용자의 요청이 식별 가능하도록 요구 됩니다. 좀 더 미묘하긴 하지만, 캔버스에 텍스트를 그리는 것을 포함하는 많은 효과(예를 들어, 텍스트 주변에 테두리를 그리는 것을 포함하는 효과)가 필요한 큰 텍스트와 같은 정보 또한 사용자의 요청을 그룹핑 하는데 필요할 수 있는 정보(이 경우, 잠재적으로 노출함으로서 악랄한 수색을 통해, 사용자가 어떤 폰트를 설치했는지, 사용자마다 상당히 달라질 수 있는 정보)를 유출합니다.

이 명세에서 사용자의 지문 채취에 사용될 수 있는 기능들은 이 문단처럼 표시됩니다.

플랫폼에서 다른 기능들은 아래 내용을 포함하더라도 제한되지 않고 같은 목적으로 사용될 수 있습니다:

• 유저 에이전트들이 지원하는 기능의 정확한 목록.

• 스크립트에서 재귀에 대한 최대 허용 스택 깊이.

• 미디어 쿼리와 Screen 객체 같이, 사용자의 환경을 설명하는 기능. [MEDIAQ] [CSSOM-VIEW]

• 사용자의 표준 시간대.

1.9. HTML 간단한 소개

이 섹션은 비규범적입니다.

기본적인 HTML 문서는 다음과 같습니다:

<!DOCTYPE html>
<html>
  <head>
    <title>Sample page</title>
  </head>
  <body>
    <h1>Sample page</h1>
    <p>This is a <a href="demo.html">simple</a> sample.</p>
    <!-- this is a comment -->
  </body>
</html>

HTML 문서는 요소(element)와 텍스트의 트리로 구성됩니다. 각 요소(element)는 "body"와 같은 시작 태그와 "/body>"과 같은 종료 태그로 소스에 표시됩니다. (특정 시작 태그와 종료 태그는 어떤 경우에 생략될 수 있고 다른 태그들에 함축될 수 있습니다.)

태그는 서로 중복되는 일 없이, 요소들이 서로 안에 완전히 있도록 중첩되어야 합니다:

<p>This is <em>very <strong>wrong</em>!</strong></p>

<p>This <em>is <strong>correct</strong>.</em></p>

이 명세는 요소들이 중첩될 수 있는 방법에 대한 규칙과 함께, HTML에 사용될 수 있는 요소의 세트를 정의합니다.

요소는 속성(attribute)를 가질 수 있고, 이것은 요소들이 동작하는 방법을 제어합니다. 아래 예에서, a 요소와 href 속성(attirbute)을 사용하여 형성되는 하이퍼링크가 있습니다:

<a href="demo.html">simple</a>

속성은 시작 태그 내에 위치하고, "=" 문자로 구분되는 이름과 값으로 구성됩니다. 속성 값은 공백 문자나 " ' ` = < >를 포함하지 않는 다면 따옴표 없이 남을 수 있습니다. 그렇지 않으면, 홑따옴표나 쌍따옴표를 사용하여야 합니다. 속성 값은 값이 빈 문자열이라면 "=" 문자와 함께 생략될 수 있습니다.

<!-- empty attributes -->
<input name=address disabled>
<input name=address disabled="">

<!-- attributes with a value -->
<input name=address maxlength=200>
<input name=address maxlength='200'>
<input name=address maxlength="200">

HTML 유저 에이전트들은 (예를 들어, 웹 브라우저) 이 마크업을 해석한 이후, DOM(Document Object Model) 트리로 바꿉니다. DOM 트리는 문서의 메모리 내 표현입니다.

DOM 트리는 여러 종류의 노드, 특히 DocumentType 노드, Element 노드, Text 노드, Comment 노드, 경우에 따라서는 ProcessingInstruction 노드를 포함합니다.

이 섹션의 가장 처음에 있는 마크업 조각은 다음 DOM 트리로 바뀔 것 입니다:

• DOCTYPE: html
• html
  • head
    • #text: ⏎␣␣
    • title
      • #text: Sample page
    • #text: ⏎␣
  • #text: ⏎␣
  • body
    • #text: ⏎␣␣
    • h1
      • #text: Sample page
    • #text: ⏎␣␣
    • p
      • #text: This is a
      • a href="demo.html"
        • #text: simple
      • #text: sample.
    • #text: ⏎␣␣
    • #comment: this is a comment
    • #text: ⏎␣⏎

이 트리의 루트 요소(element)는 html 요소(element)이고, 이것은 항상 HTML 문서의 루트에서 발견됩니다. 이 요소는 두 요소(element), head와 body 뿐 아니라 둘 사이에 Text 노드로 구성됩니다.

소스가 다수의 공백(여기에는 "␣"로 표기 된)과 DOM에서 Text 노드가 되는 모든 줄 바꿈("⏎")을 포함하기 때문에, 초기에 예상할 수 있는 것보다 DOM 트리에는 더욱 많은 Text 노드가 있습니다. 하지만, 역사적인 이유로 원본 마크업의 모든 공백과 줄바꿈은 DOM에 나타나지 않습니다. 특히, head 시작 태그 전의 모든 빈공간은 묵시적으로 생략되게 되고, body 종료 태그 후의 모든 빈공간은 body의 끝에 위치하게 됩니다.

head 요소(element)는 title 요소를 포함하고, title 요소는 문자열 "Sample page"를 가진 Text 노드를 포함합니다. 비슷하게 body 요소(element)는 h1 요소(element), p 요소(element), 주석을 포함합니다.

이 DOM 트리는 페이지의 스크립트에 의해 조작될 수 있습니다. 스크립트(일반적으로 자바스크립트)는 script 요소(element)를 사용하거나 이벤트 핸들러 콘텐트 속성(attribute)를 사용하여 삽입될 수 있는 작은 프로그램입니다. 예를 들어, "Hello World"를 출력하기 위해 양식의 output 요소(element)의 값을 설정하는 스크립트를 가진 양식이 있습니다.

<form name="main">
  Result: <output name="result"></output>
  <script>
    document.forms.main.elements.result.value = 'Hello World';
  </script>
</form>

DOM 트리 내 각 요소(element)는 객체로 나타나고, 이 객체들은 API들을 가지기 때문에 조작될 수 있습니다. 예를 들어, 링크(예를 들어 위 트리에서 a 요소(element))는 몇 가지 방법으로 변경된 "href" 속성(attribute)을 가질 수 있습니다:

var a = document.links[0]; // obtain the first link in the document
a.href = 'sample.html'; // change the destination URL of the link
a.protocol = 'https'; // change just the scheme part of the URL
a.setAttribute('href', 'https://example.com/'); // change the content attribute directly

DOM 트리는 HTML 문서가 처리되고 실행에 의해 표현될 때 (특히 웹 브라우저 같은 대화형 실행) HTML 문서를 나타내는 방식으로 사용되기 때문에, 이 명세는 위에 기술된 마크업 대신에, 일반적으로 DOM 트리의 관점으로 표현됩니다.

HTML 문서는 대화형 콘텐트의 매체 독립 설명을 나타냅니다. HTML 문서는 스크린이나 음성 합성 장치를 통해, 혹은 점자 디스플레이에 렌더링 될 수 있습니다. 그러한 렌더링이 일어나는 방법에 정확히 영향을 주기 위해, 작성자는 CSS 같은 스타일링 언어를 사용할 수 있습니다.

다음 예에서, 페이지는 CSS를 사용하여 파란색 위에 노랜색으로 만들어졌습니다.

<!DOCTYPE html>
<html>
  <head>
    <title>Sample styled page</title>
    <style>
      body { background: navy; color: yellow; }
    </style>
  </head>
  <body>
    <h1>Sample styled page</h1>
    <p>This page is just a demo.</p>
  </body>
</html>

HTML을 사용하는 방법에 더 자세한 내용에 대해, 작성자는 튜토리얼과 가이드를 찾아볼 것이 권장됩니다. 이 명세에 포함된 몇 몇 예제들은 사용 될 수도 있지만, 초급 작성자는 이 명세가 처음에 이해하기에 어려울 수 있는 자세한 수준으로 언어를 설명할 수 밖에 없기 때문에 주의가 주어집니다.

1.9.1. HTML로 안전한 어플리케이션 작성

이 섹션은 비규범적입니다.

HTML이 대화형 사이트를 생성하는데 사용될 경우, 사이트 자체나 사이트의 사용자의 무결성을 위태롭게 할 수 있는 공격자를 통해 취약성을 도입하지 않도록 주의할 필요가 있습니다.

이 문제의 포괄적인 연구는 이 문서의 범위 밖에 있고, 작성자 좀 더 자세하게 문제를 연구할 것을 강력히 권장됩니다. 다만, 이 섹션은 HTML 어플리케이션 개발에 일부 공통된 위험들에 대한 간단한 소개를 제공하려고 합니다.

웹의 보안 모델은 "origins" 개념에 기초하고, 많은 웹 상의 잠재적인 공격은 그에 대응하여 교차 출처(cross-origin) 행동을 수반합니다. [ORIGIN]

사용자 입력의 유효성을 검사하지 않음

교차 사이트 스크립팅 (XSS)

SQL 인젝션(injection)

신뢰할 수 없는 입력, 예를 들어, 텍스트 주석 같은 사용자 생성 콘텐트, URL 파라미터 안의 값, 서드 파티 사이트로부터의 메세지, 등을 받아들일 경우, 데이터는 사용하기 전에 반드시 검증되어야 하고, 표시 될 때 적절히 이스케이프(escape)되어야 합니다. 이를 수행하는 것이 실패하는 것은, 가짜 나이 같은 가짜 사용자 정보를 제공하는 것과 같은 잠재적으로 무해한 것에서부터 사용자가 정보를 포함하는 페이지를 보는 매 순간 스크립트를 실행하는 것 같은 심각한 것까지, 잠재적으로 처리 중 공격을 전파하여 서버 내 모든 데이터를 삭제하는 것 같은 최악까지, 적대적인 사용자의 다양한 공격 수행을 허용할 수 있습니다.

사용자 입력을 검증하기 위한 필터를 작성할 경우, 필터는 반드시, 알려진 안전한 구조를 허용하고 모든 다른 입력은 불허하여, 항상 안전한 목록 기반으로 되어야 합니다. 알려진 해로운 입력을 불허하고 나머지 모든 것을 허용하는 차단 목록 기반 필터는 해로운 모든 것이 아직 다 알려진 것이 아니기 때문에(예를 들어, 미래에 만들어 질 수도 있기 때문에) 안전하지 않습니다.

예를 들어, 다음 경우와 같이, 무엇을 표시할 것인지를 결정하기 위해 페이지가 URL의 쿼리 스트링을 보고, 그 후 메세지를 표시하기 위해 그 페이지로 사용자를 리다이렉트 시킨다고 가정해 봅시다:

<ul>
  <li><a href="message.cgi?say=Hello">Say Hello</a>
  <li><a href="message.cgi?say=Welcome">Say Welcome</a>
  <li><a href="message.cgi?say=Kittens">Say Kittens</a>
</ul>

메세지가 사용자에게 이스케이프 없이 바로 표시되었다면, 적대적인 공격자는 스크립트 요소(element)가 포함된 URL을 만들 수 있습니다:

https://example.com/message.cgi?say=%3Cscript%3Ealert%28%27Oh%20no%21%27%29%3C/script%3E

공격자가 이후 공격 대상자가 이 페이지를 방문할 것으로 확신했다면, 공격자가 선택한 스크립트는 페이지에서 실행될 것입니다. 그런 스크립트는 사이트가 제공하는 것에 의해서만 제한되고, 얼마든지 적대적인 행동을 할 수 있습니다: 예를 들어, 사이트가 e-커머스 상점이라면 그러한 스크립트는 사용자 모르게 마음대로 많은 원치않는 구매를 야기할 수 있습니다.

이것이 교차 사이트 스크립팅(cross-site scripting) 공격이라고 불립니다.

사이트를 속여서 코드를 실행하게 하는데 사용될 수 있는 많은 구성 요소들이 있습니다. 안전한 목록 필터들을 작성할 경우 작성자가 고려하도록 권장되는 몇 가지가 있습니다:

• img 처럼 무해해 보이는 요소(element)를 허용할 경우, 최소 권한의 원리를 집행하고 요소의 속성(attribute)를 오직 요구되는 것(예를 들어, 안전 목록)으로만 제한시킵니다. 모든 속성(attribute)이 허용된다면 공격자는 예를 들어, 임의의 스크립트를 수행하기 위해 onload 속성(attribute)을 사용할 수 있습니다.

• 제공된 URL(예를 들어 링크)이 허용되는 경우, 각 URL의 스키마는 악용 될 수 있는 많은 스키마들이 있기 때문에 명시적으로 안전목록에 있을 필요가 있습니다. 가장 유명한 예는 "javascript:"이지만, 유저 에이전트들은 다른 스크립트를 구현할 수 있습니다. (그리고 실제로 역사적으로 구현 되었습니다.)

• base 요소(element)가 삽입되는 것을 허용하는 것은 페이지 내에 관련 링크를 가진 script 요소(element)들이 탈취될 수 있음을 의미하고, 유사하게 양식 전송이 적대적인 사이트로 리다이렉트 될 수 있습니다.

교차 사이트 요청 위조 (CSRF)

사이트가 사용자가 사용자 특정 사이드 이펙트를 가진 양식 전송, 예를 들어 사용자의 이름으로 포럼에 메세지를 게시하거나, 구매하거나, 여권을 신청하는 것이 이루어지는 것을 허용한다면, 요청이 사용자 모르게 요청을 만들도록 속이는 다른 사이트가 아니라,사용자에 의해 의도적으로 만들어진 것인지 검증하는 것이 중요합니다.

이 문제는 HTML 양식이 다른 origin으로 전송될 수 있기 때문에 존재합니다.

사이트들은 사용자 특정 숨김 토큰을 가진 양식을 채우거나, 모든 요청에 Origin 헤더를 검사하여 그런 공격을 막을 수 있습니다.

클릭잭킹

사용자가 수행되는 것을 원하지 않는 행동을 수행하는 인터페이스를 사용자에게 제공하는 페이지는 사용자가 속아서 인터페이스를 활성화 할 수 있는 가능성이 방지되도록 설계 될 필요가 있습니다.

사용자가 속을 수 있는 하나의 방법은 적대적인 사이트가 작은 iframe에 공격 대상 사이트를 위치시키고 사용자가 클릭하도록 믿게 하는 것 ,예를 들어 사용자가 반응 게임을 하도록 하는 것입니다. 일단 사용자가 게임을 하면, 적대적인 사이트는 사용자가 클릭 할 때 빠르게 마우스 커서 아래에 iframe을 위치 시키고, 따라서 사용자가 공격 대상 사이트의 인터페이스를 클릭하도록 속입니다.

이를 방지하기 위해, 프레임 사용이 예상되지 않는 사이트는 인터페이스가 프레임 내에 있지 않음이 감지되는 경우(예를 들어, Window 객체와 top 속성(attribute)의 값을 비교하여) 에만 활성화 되도록 권장됩니다.

1.9.2. API 스크립팅을 사용하는 경우를 막는 일반적인 위험

이 섹션은 비규범적입니다.

HTML 내 스크립트는 일반적으로 브라우저가 추가적인 이벤트를 발생시키거나, 문서 해석을 계속하는 것 같은 다른 것을 수행하기 전에 중단하지 않고 스크립트를 수행 함을 의미하는 "run-to-completion" 의미(semantics)를 가집니다.

다른 한편으로, HTML 파일의 해석은 병렬로 그리고 파서가 스크립트를 수행하는 지점에서 중단 됨을 의미하는, 점진적으로 발생합니다. 이것은 일반적으로 좋은 일이지만, 이는 작성자가 이벤트가 되도록 발생한 이후에 이벤트 핸들러를 후킹하는 것을 방지하도록 조심해야 할 필요가 있음을 의미합니다.

이것을 확실하게 수행하기 위한 두 가지 기술이 있습니다: 이벤트 핸들러 콘텐트 속성(attribute)을 사용하거나 동일한 스크립트에서 요소(element)를 생성하고 이벤트 핸들러를 추가하는 것입니다. 앞서 언급 되었듯이, 스크립트는 더 많은 이벤트들이 발생하기 전에 스크립트는 수행부터 완료되기 때문에 후자가 안전합니다.

<img src="games.png" alt="Games" onload="gamesLogoHasLoaded(event)">

<script>
var img = new Image();
img.src = 'games.png';
img.alt = 'Games';
img.onload = gamesLogoHasLoaded;
// img.addEventListener('load', gamesLogoHasLoaded, false); // would work also
</script>

<!-- Do not use this style, it has a race condition! -->
<img id="games" src="games.png" alt="Games">
<!-- the 'load' event might fire here while the parser is taking a
    break, in which case you will not see it! -->
<script>
var img = document.getElementById('games');
img.onload = gamesLogoHasLoaded; // might never fire!
</script>

1.9.3. HTML을 작성할 때 실수를 찾는 방법: 유효성 검사기와 적합성 검사기

이 섹션은 비규범적입니다.

작성자는 적합성 검사기(유효성 검사기로 알려진)의 사용으로 일반적인 실수를 찾도록 권장됩니다. W3C는 Nu Markup Validation Service를 포함하여 다수의 온라인 유효성 서비스를 제공합니다.

1.10. 작성자를 위한 적합성 요구사항

이 섹션은 비규범적입니다.

HTML 명세의 이전 버전과는 달리, 이 명세는 유효한 문서 뿐 아니라 유효하지 않은 문서에 대한 처리에 요구되는 몇 가지 자세한 사항으로 정의합니다.

그러나, 비록 유효하지 않은 콘텐트의 처리가 대부분의 경우 명확하지만, 문서에 대한 적합성 요구사항은 여전히 중요합니다: 실제로는, 상호운용성은 (모든 구현이 믿을 만하고 똑같거나 동등한 수준의 방법으로 특정 콘텐츠를 처리하는 상황) 문서 적합성 요구 사항의 목적만은 아닙니다. 이 섹션은 적합한 문서와 오류가 있는 문서를 구별하기 위한 몇 가지 더 일반적인 이유들을 상술합니다.

1.10.1. 표현 마크업

이 섹션은 비규범적입니다.

HTML의 이전 버전에서의 대다수 표현 기능은 더 이상 허용되지 않습니다. 일반적으로 표현 마크업음 많은 문제를 가지고 있는 것이 발견되었습니다:

표현 요소(element)의 사용은 낮은 접근성으로 이어집니다.

보조 기술(AT) 사용자에게 적절한 경험을 제공하는 방법으로(예를 들어, ARIA를 사용하여) 표현 마크업을 사용하는 것이 가능한 반면, 그렇게 하는 것은 의미론적으로 적절한 마크업을 사용하여 그렇게 하는 경우보다 상당히 더 어렵습니다. 게다가, 표현 마크업은 비 AT 사용자, 비 그래픽 유저 에이전트(텍스트 모드 브라우저 같은)에 대한 접근성을 보장하지 않습니다.

반면, 매체 독립 마크업을 사용하는 것은 좀 더 많은 사용자(예를 들어 텍스트 브라우저 사용자들)에 대한 "접근 가능"한 방법으로 작성된 문서에 대한 쉬운 방법을 제공합니다.

유지보수의 높은 비용

마크업이 스타일 독립적인 방법으로 작성된 사이트를 유지보수하는 것은 상당히 쉽습니다. 예를 들어, <font color="">를 사용하는 사이트의 색상을 변경하는 것은 전체 사이트에 걸쳐 변경을 요구하는 반면, CSS 기반의 사이트를 비슷하게 변경하는 것은 단일 파일의 변경으로 가능합니다.

큰 문서 크기

표현 마크업은 더구나 불필요한 경향이 있고, 따라서 큰 문서 크기의 결과를 가져옵니다.

그러한 이유로, 이 버전에서는 HTML로부터 표현 마크업이 제거되었습니다. 이 변화는 놀라운 일이 아닙니다; HTML 4.0은 수 년전부터 표현 마크업을 반대했고, 사용자가 표현 마크업으로부터 떠나도록 돕는 모드(HTML Transitional)를 제공했습니다; 이후, XHTML 1.1은 더 나아가 그 기능들을 완전히 폐기했습니다.

HTML에 유일하게 남은 표현 마크업 기능은 style 속성(attribute)과 style 요소(element)입니다. style 속성(attribute)의 사용은 생산 환경에서 다소 지양되지만, 빠른 프로토타이핑(그것의 규칙이 나중에 별도의 스타일 시트로 직접 옮겨질 수 있는)과 별도의 스타일 시트가 충족시키지 못하는 일반적이지 않은 상황에서 특정 스타일을 제공에 유용할 수 있습니다. 비슷하게, style 요소(element)는 그룹핑이나 페이지 특정 스타일에 유용할 수 있지만, 일반적으로 외부 스타일 시트는 스타일이 여러 페이지에 적용되는 경우 더 많은 편리할 가능성이 있습니다.

몇 몇의 이전의 표현 요소(element)들이 이 명세에서 매체 독립적으로 재정의 되는 것에 주목할 가치가 있습니다: b, i, hr, s, small, u.

1.10.2. 구문 오류

이 섹션은 비규범적입니다.

HTML의 구문은 다양한 갖가지 문제들을 방지하게 만듭니다.

비직관적인 이벤트 핸들링 동작

특정한 유효하지 앟은 구문 구성은, 해석 될 때, 매우 비직관적인 DOM 트리를 야기합니다.

예를 들어, 다음 마크업 조각은 DOM에서 table 요소(element)와 상응하는 앞선 형제인 hr을 야기합니다:

<table><hr>...

선택적 오류 복구를 가진 오류

더 기이하고 난해한 오류 처리 규칙을 구현할 필요 없이 유저 에이전트들이 환경이 제어될 수 있도록 사용되는 것을 허용하기 위해, 유저 에이전트들은 해석 오류를 맞닥뜨릴 때 마다 실패하는 것을 허용합니다.

오류 처리 행동이 스트리밍 유저 에이전트들과 호환되지 않는 오류

위에 언급된 <table><hr>...예에 대한 행동 같은, 일부 오류 처리 행동은 스트리밍 유저 에이전트들과 (상태를 저장하지 않고 단일 패스(one-pass)로 HTML 파일을 처리하는 유저 에이전트들) 호환되지 않습니다. 그러한 유저 에이전트들로 상호운용성 문제를 방지하기 위한, 그러한 행동을 야기하는 어떠한 구문도 유효하지 않은 것으로 고려됩니다.

infoset 강제를 야기하는 오류

XML 기반의 유저 에이전트가 HTML 해석기에 연결되는 경우, 주석은 두 개의 연속된 하이픈을 포함해서는 안 된다는 것과 같은, XML이 강요하는 특정한 불변성은 HTML 파일에 의해 위반 될 것입니다. 이를 처리하는 것은 해석기가 HTML DOM을 XML 호환 infoset으로 강제하는 것을 요구할 수 있습니다. 그러한 처리를 요구하는 대부분의 구문은 유효하지 않은 것으로 고려됩니다. considered invalid.

균형이 맞지 않는 빈약한 성능을 초래하는 오류

특정 구문 구성은 균형이 맞지 않는 빈약한 성능을 초래할 수 있습니다. 그런 구성의 사용을 막기 위해 그것들은 일반적으로 부적합이 됩니다.

예를 들어, 다음 마크업은, 모든 닫히지 않은 i 요소(element)가 각 문단에서 재구성되어야 하기 때문에, 각 문단에서 계속해서 더 많은 요소(element)들을 야기하여 빈약한 퍼포먼스를 야기합니다:

<p><i>He dreamt.
<p><i>He dreamt that he ate breakfast.
<p><i>Then lunch.
<p><i>And finally dinner.

이 코드 조각에 대한 결과 DOM은 다음이 될 것입니다:

• p
  • i
    • #text: He dreamt.
• p
  • i
    • i
      • #text: He dreamt that he ate breakfast.
• p
  • i
    • i
      • i
        • #text: Then lunch.
• p
  • i
    • i
      • i
        • i
          • #text: And finally dinner.

취약한 구문 구조를 수반하는 오류

역사적인 이유로, 상대적으로 취약한 구문 구조가 있습니다. 뜻하지 않게 그러한 문제로 빠지는 다수의 사용자를 줄이기 위해, 그것들은 부적합이 됩니다.

예를 들어, 속성 내 특정한 명명된 문자 참조의 해석은, 닫는 세미콜론이 생략된 경우에도 발생됩니다. 명명된 문자 참조를 형성하지 않는 글자가 따르는 앰퍼샌드를 포함하는 것이 안전하지만, 글자가 명명된 문자 참조를 형성하는 문자열로 변경된다면, 그것들은 문자열 대신 그 문자로 해석 될 것입니다.

이 코드 조각에서, 속성의 값은 "?bill&ted"입니다:

<a href="?bill&ted">Bill and Ted</a>

하지만 다음 코드 조각에서 속성의 값은 심지어 마지막 세미콜론이 없기 때문에, "&copy"는 "©"과 같은 것으로 처리되고 따라서 "©"로 해석되어, 의도된 "?art&copy"아니라 실제로 "?art©" 입니다:

<a href="?art&copy">Art and Copy</a>

이 문제를 방지하기 위해, 모든 명명된 문자 참조들은 세미콜론으로 종료되는 것이 요구되고, 세미콜론이 없이 명명된 문자 참조의 사용은 오류로 표시됩니다.

따라서, 위 경우를 나타내기 위한 올바른 방법은 다음과 같습니다:

<a href="?bill&ted">Bill and Ted</a> <!-- &ted 는 명명된 문자 참조가 아니기 때문에 ok -->

<a href="?art&amp;copy">Art and Copy</a> <!-- &copy 는 명명된 문자 참조 이기 때문에 &는 이스케이프 되어야 합니다. -->

레거시 유저 에이전트들에서 알려진 상호 운용성 문제를 수반하는 오류

특정 구문 구성은 레거시 유저 에이전트들에서 특히 미묘하거나 심각한 문제를 야기하는 것으로 알려져 있고, 그러므로 작성자가 그것들을 방지하는 것을 돕기 위해 부적합으로 표기됩니다.

예를 들어, 이것은 U+0060 억음 악센트 문자가 따옴표 없는 속성(attribute)에 허용되지 않는 이유입니다. 특정 레거시 유저 에이전트들에서, 그것은 종종 따옴표 문자로 취급됩니다.

이것의 또 다른 예는 DOCTYPE이고, 이것은 비쿼크 모드를 발생시키도록 요구되는데, 이는 쿼크 모드에서의 레거시 유저 에이전트들의 동작은 종종 주로 비문서화 되기 때문입니다.

작성자를 보안 공격에 노출시키는 리스크 오류

특정 제약사항은 순수하게 알려진 보안 문제들을 방지하기 위해 존재합니다.

예를 들어, UTF-7 사용의 제약사항은 순수하게 UTF-7를 사용하여 알려진 교차 사이트 스크립팅 공격의 희생양이 되는 것을 방지하기 위해 존재합니다. [RFC2152]

작성자의 의도가 분명하지 않은 경우

작성자의 의도가 매우 분명하지 않은 마크업은 종종 부적합이 됩니다. 이 오류들을 초기에 보완하는 것이 차후 유지보수를 쉽게 만듭니다.

예를 들어, 다음은 h1 헤딩이 되는지 h2 헤딩이 되는지 작성자가 의도한 것이 분명하지 않습니다:

<h2>Contact details</h1>

오타일 가능성이 있는 경우

사용자가 단순 오타를 만들 경우, 오류가 쉽게 잡힐 수 있다면 이는 작성자의 디버깅 시간을 단축시킬 수 있기 때문에 유용합니다. 그러므로 이 명세는 보통 이 명세에 정의 된 이름과 일치하지 않는 요소(element)명, 속성(element)명 등등을 사용하는 것을 오류로 간주합니다.

예를 들어, 작성자가 <caption> 대신에 <capton>라고 타이핑 했다면, 이 오류로 표기될 것이고 작성자는 즉시 오타를 수정할 수 있습니다.

미래에 새로운 구문과 충돌할 수 있는 오류

언어 구문이 미래에 확장 되는 것을 허용하기 위해, 특정한 다른 무해한 기능들이 허용되지 않습니다.

예를 들어, 종료 태그 안의 속성(attribute)들은 현재 유효하지 않고 무시됩니다. 언어에 대한 향후 변화는 이 구문 기능을 사용할 수 있고 이미 배포된(그리고 유효한!) 콘텐트와 충돌 없이 사용할 수 있습니다.

일부 작성자는, HTML 구문의 유연성을 이용하여 제공된 간결함의 작은 편의 넘어 그런 습관으로부터 얻어진 일관성을 택하여, 항상 모든 속성(attribute)들을 따옴표로 묶는 것과 모든 선택적 태그들을 포함하는 것에 노력을 기울이는 것이 유용하다는 것을 발견합니다. 그러한 작성자들을 지원하기 위해, 적합성 검사기는 그러한 규칙이 적용되는 운영 모드를 제공할 수 있습니다.

1.10.3. 콘텐트 모델과 속성(attribute) 값에 대한 제한 사항

이 섹션은 비규범적입니다.

언어의 구문을 넘어서, 이 명세는 또한 요소(element)와 속성(attribute)가 명시될 수 있는 방법에 대한 제한사항을 둡니다. 이 제한사항들은 비슷한 이유로 존재합니다:

모호한 의미(semantics)를 가진 콘텐트를 수반하는 오류

정의된 의미(meanings)를 가진 요소의 오용을 방지하기 위해, 콘텐트 모델들은 중첩이 모호한 값을 발생 시킬 수 있는 경우 요소들이 중첩될 수 있는 방법에 대한 제한이 정의됩니다.

예를 들어, 이 명세는, 작성자가 전체 섹션이 입력되어야 할 것이라고 나타낼 가능성이 아주 없기 때문에, kbd 요소(element) 안에 section 요소(element)가 중첩되는 것을 불허합니다.

전달된 의미(semantics)에 충돌을 수반하는 오류

비슷하게, 요소(elememt) 사용의 잘못에 작성자의 관심을 끌기 위해, 전달된 의미(semantics)의 분명한 모순 역시 접합성 오류로 간주됩니다.

예를 들어 아래 코드 조각에서, 의미(semantics)는 말도 안됩니다: 구분선은 동시에 셀이 될 수 없으며, 라디오 버튼 또한 진행 바(progress bar)가 될 수 없습니다.

<hr role="cell">

<input type=radio role=progressbar>

또 다른 예는 ul 요소(element)의 콘텐트 모델의 제약사항인데, li 자식 요소(element)만을 허용합니다. 정의에 따라 리스트는 0개 이상의 리스트 항목으로 구성되고, 따라서 ul 요소(element)가 li 요소(element)가 아닌 다른 어떤 것을 포함한다면, 의미하는 바가 불분명한 것입니다.

기본 스타일이 혼란을 이끌어 낼 가능성이 있는 경우

특정 요소(element)들은 특정 조합이 혼란을 이끌어 낼 가능성을 만들어내는 기본 스타일이나 동작을 가집니다. 이 요소(element)들이 이 문제 없는 동등한 수준의 대안을 가지는 경우, 혼란스러운 조합은 불허됩니다.

예를 들어, div 요소(element)는 블럭 박스로 렌더링 되고, span 요소(element)는 인라인 박스로 렌더링 됩니다. 인라인 박스 안에 블럭 박스를 두는 것은 불필요하게 혼란스럽습니다; div 요소(element)만을 중첩하거나, span 요소(element)만을 중첩하거나, div 요소(element) 안에 span 요소(element) 중첩하거나 모두 span 요소(element) 안에 div 요소(element)를 중첩하는 것과 동일한 목적을 제공하지만, 후자만이 인라인 박스 안에 블럭 박스를 수반하기 때문에 후자의 조합은 불허됩니다.

또 다른 예는 인터랙티브 콘텐트가 중첩될 수 있는 방법은 없다는 것 입니다. 예를 들어 button 요소(element)는 textarea 요소(element)를 포함할 수 없습니다. 이것은 그렇게 인터랙티브 요소(element)들을 중첩하는 것의 동작은 사용자를 매우 혼란스럽게 만들 것입니다. 이 요소(element)들을 중첩하는 대신 나란히 위치시킬 수 있습니다.

명세를 오해할 가능성을 나타내는 오류

때때로, 어떤 것들은 작성자를 혼란에 빠뜨릴 가능성을 허용하기 때문에 불허됩니다.

예를 들어, disabled 속성(attribute)를 "false" 값으로 설정하는 것은, 요소가 활성화 되었음을 의미하는 것의 표현임에도 불구하고 실은 요소가 비활성화 되었음을 의미하기 때문에 불허됩니다. (속성(attribute)의 존재가 구현의 문제이지 값의 문제는 아닙니다.)

단순히 언어를 간소화 하기 위해 도입된 제한을 수반하는 오류

어떤 적합성 오류는 작성자가 학습할 필요가 있는 언어를 간소화 합니다.

예를 들어, area 요소의 shape 속성(attribute)은, circ과 circle 값을 실제로 동의어로서 모두 허용함에도 불구하고, 튜토리얼과 다른 학습 지원을 간소화 하기 위해, circ 값의 사용을 불허합니다. 둘을 허용하는 것에 이득은 없는 반면, 언어를 가르칠 경우 추가적인 혼란을 야기할 수 있습니다.

해석기의 특이점을 수반하는 오류

특정 요소(element)들은 기이한 방법으로 해석되고(보통 역사적인 이유로), 그것들의 콘텐트 모델 제약사항들은 작성자가 이 이슈에 노출되는 것을 방지하기 위해 의도된 것입니다.

예를 들어, form 요소(element)는 HTML로 해석되는 경우 form 요소(element)의 시작 태그는 p 요소(element)의 종료 태그를 암시하기 때문에 프레이징 콘텐트 안에 허용되지 않습니다. 따라서 다음 마크업은 하나가 아닌 두 문단을 야기합니다:

<p>Welcome. <form><label>Name:</label> <input></form>

이것은 정확히 다음과 같이 해석됩니다:

<p>Welcome. </p><form><label>Name:</label> <input></form>

디버그 하기 어려운 방법으로 스크립트 실패를 야기할 가능성이 있는 오류

어떤 오류들은 디버그 하기 어려울 스크립트 문제들을 방지하는 것을 돕기 위해 의도되었습니다.

예를 들어, 동일한 값을 가진 두 id 속성(attribute)을 가지는 것은 부적합 사유입니다. 중복 ID는, 종종 원인을 규명하기 어려운 형편없는 효과와 함께, 선택되는 잘못된 요소를 이끌어 냅니다.

작성 시간을 낭비하는 오류

어떤 구조는 역사적으로 많은 낭비된 작성 시간의 원인이 되어왔기 때문에 비허용되고, 그것들을 만드는 것을 방지하기 위해 작성자에게 권장하여 작성자가 앞으로의 수고를 줄일 수 있습니다.

예를 들어, script 요소(element)의 src 속성(attribute)은 요소(element)의 콘텐츠가 무시되는 것을 야기합니다. 하지만 이것은, 특히 요소(element)의 콘텐츠가 실행 가능한 스크립트 — 작성자로 하여금 실행되고 있지 않음을 깨닫지 못하고 인라인 스크립트를 디버그하기 위한 노력에 많은 시간을 소모하게 만들 수 있는,를 나타낸다면, 명확하지 않습니다. 이 문제를 줄이기 위해 ,이 명세는 src 속성(attribute)이 존재할 경우, script 요소(element) 안에 실행 가능한 스크립트를 가지는 것을 부적합으로 만듭니다. 이것은 그들의 문서를 감사하는 작성자가 이러한 종류의 실수로 시간을 허비할 가능성이 적음을 의미합니다.

XHTML으로 그리고 XHTML로부터 마이그레이션 하는 작성자에게 영향을 주는 영역을 수반하는 오류

일부 작성자는 비슷한 결과를 가지는 XML과 HTML 양쪽 모두로 해석될 수 있는 파일을 작성하는 것을 좋아합니다. 이 습관이 무수히 많은 미묘한 복잡한 문제들이 수반되기 때문에(특히 스크립팅, 스타일링, 임의의 종류의 자동화 된 직렬화 등을 수반하는 경우) 일반적으로 권장되지 않기는 하지만, 이 명세는 최소한 어느 정도 어려움을 완화하기 위한 몇 가지 제약사항들을 가집니다. 이는 HTML과 XHTML 사이에서 마이그레이션 하는 경우 과도기적 단계로 작성자가 이것을 사용하는 것을 더 쉽게 합니다.

예를 들어, 동기화를 유지하도록 의도된 lang과 xml:lang 속성(attribute) 주위의 다소 복잡한 규칙이 있습니다.

또 다른 예는 HTML 직렬화에서 xmlns 속성(attribute)의 값에 대한 제약사항들 일 것이고, 이는 적합한 문서에서 요소(element)들이 HTML로 처리되든 XML로 처리되든 동일한 네임스페이스에 있게 되는 것을 보장하도록 의도된 것입니다.

미래 확정을 위해 예약된 영역을 수반하는 오류

언어의 향후 개정에서 새로운 구문을 허용하도록 의도된 구문의 제약사항과 마찬가지로, 요소(element)의 콘텐트 모델과 속성(attribute)의 값의 일부 제약사항은 HTML 어휘의 미래 확장을 허용하도록 의도됩니다.

예를 들어, U+005F 밑줄 문자 (_)로 시작하는 target 속성(attribute)의 값을 오직 특정한 미리 정의된 값으로 제한하는 것은 새로운 미리 정의된 값이 미래에 작성자에 의해 정의된 값과 충돌 없이 도입되는 것을 허용합니다.

다른 명세의 오용을 나타내는 오류

특정 제약사항은 다른 명세에 의해 만들어진 제약사항을 지원하도록 의도됩니다.

예를 들어, 미디어 쿼리 목록을 취하는 속성(attribute)이 오직 유효한 미디어 쿼리 목록을 사용함을 요구하는 것은 그 명세의 적합성 규칙을 따르는 것의 중요성을 강화합니다.

1.11. 추천 읽을 거리

이 섹션은 비규범적입니다.

다음 문서들은 이 명세의 독자들이 관심을 가질 수 있습니다.

Character Model for the World Wide Web 1.0: Fundamentals [CHARMOD]

이 구성적인 명세는 명세의 작성자들, 소프트웨어 개발자들, 콘텐트 개발자에게, 유니코드 표준과 ISO/IEC 10646 공동으로 정의된 국제 부호화 문자 집합을 기반으로 하여, 월드 와이드 웹 상의 상호 운용적 텍스트 조작을 위한 일반적인 참조를 가지고 제공합니다. 제기된 주제는 "문자", "인코딩", "문자열", 참조 처리 모델, 문자 인코딩의 선택과 식별, 문자 이스케이핑, 문자열 인덱싱 이라는 용어의 사용을 포함합니다.

Unicode Security Considerations [UNICODE-SECURITY]

유니코드는 매우 많은 수의 문자들을 포함하고 세상의 다양한 작성 시스템을 포함하기 때문에, 잘못된 사용은 프로그램이나 시스템이 보안 공격이 가능하게 노출시킬 수 있습니다. 이것은 특히 더 많은 제품들이 국제화 되기 때문에 중요합니다. 이 문서는 프로그래머, 시스템 분석가, 표준 개발자, 사용자들이 고려해야하는 약간의 보안 고려사항을 설명하고, 문제의 리스크를 줄이기 위한 명세 권고안을 제공합니다.

Web Content Accessibility Guidelines (WCAG) 2.0 [WCAG20]

웹 콘텐트 접근성 지침 (WCAG) 2.0은 웹 콘텐트를 더 접근 가능하게 만들도록 권고안의 넓은 범위를 다룹니다. 이 지침들을 따르는 것은, 전맹과 저시력, 난청과 청력 손실, 학습 장애, 인지 장애, 상지 장애, 언어 장애, 광선과민증과 장애의 복합을 포함하여, 넓은 범위의 장애를 가진 사람들에게 범위 접근 가능한 콘텐트를 만들 것입니다. 이 지침을 따르는 것은 또한 일반적인 사용자에게도 종종 당신의 웹 콘텐트를 더 유용하게 만듭니다.

Authoring Tool Accessibility Guidelines (ATAG) 2.0 [ATAG20]

이 명세는 장애를 가진 사람들을 위한 더 접근 가능한 웹 콘텐트 저작 도구 설계에 대한 지침들을 제공합니다. 이 지침을 따르는 저작 도구는 접근 가능한 유저 인터페이스를 장애를 가진 저작자에게 제공하여, 게다가 모든 저작자에 의한 접근 가능한 웹 콘텐트 제품을 활성화하고 지원하고 촉진하여 접근성을 촉진할 것입니다.

User Agent Accessibility Guidelines (UAAG) 2.0 [UAAG20]

이 문서는 장애를 가진 사람들을 위한 웹 접근성에 대한 장벽을 낮추는 유저 에이전트 설계에 대한 지침을 제공합니다. 유저 에이전트들은 브라우저와 웹 콘텐트를 검색하고 렌더링 하는 다른 형태의 소프트웨어를 포함합니다. 이 지침을 따르는 유저 에이전트들은, 다른 기술과 통신하기 위한 능력(특히 보조 기술)을 포함하여, 그 자신의 유저 인터페이스를 통해 그리고 다른 내부 기능을 통해 접근성을 촉진할 것입니다. 뿐만 아니라, 장애를 가진 사용자 뿐 아닌, 모든 사용자들은 지침을 따르는 유저 에이전트들이 더 유용함을 찾을 수 있어야 합니다.

Polyglot Markup: HTML-Compatible XHTML Documents [HTML-POLYGLOT]

여러 언어를 사용하는 마크업(polyglot 마크업)을 사용하는 문서는 HTML로 해석할 때와 XML로 해석 할 때 동일한 문서 트리로(루트 요소(element)에 xmlns 속성(attribute)의 예외가 있는) 해석하는 일련의 바이트인 문서입니다. 잘 정의된 제약사항 세트를 만나는 polyglot 마크업은, 그것들이 HTML로 해석되든 XHTML로 해석되든 상관 없이, HTML 명세에 대하여 호환 가능한 것으로 해석됩니다. polyglot 마크업은 특정 DOCTYPE, 네임스페이스 선언, 요소(element)와 속성(attribute) 이름에 대해 특정 대소문자 — 일반적으로 소문자이지만 가끔 카멜 케이스 — 를 사용합니다. 더 나아가 제약사항은 빈 요소(element), 명명된 엔티티 참조, 스크립트와 스타일의 사용에 그것들을 포함합니다.

HTML Accessibility APIs Mappings 1.0 [HTML-AAM-1.0]

유저 에이전트가 HTML 5.1 요소(element)들과 속성(attibute)들을 플랫폼 접근성 API에 대응시키는 방법을 정의합니다. 이러한 매핑을 문서화 하는 것은 역할(role), 상태(state), 속성(property)과 접근성 API들에 의해 구현된 이벤트의 상호 운용 가능한 노출을 촉진하고 이 정보가 작성자 의도와 일관된 방식으로 나타남을 보장하는 것을 돕습니다.