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들에 의해 구현된 이벤트의 상호 운용 가능한 노출을 촉진하고 이 정보가 작성자 의도와 일관된 방식으로 나타남을 보장하는 것을 돕습니다.

2. 공통 인프라

2.1. 전문 용어

이 명세는 종종 동일한 상황에서 HTML과 XML 속성(attribute)와 IDL 속성(attribute) 양쪽 모두를 지칭합니다. 어떤 것을 지칭하고 있는지 분명하지 않을 경우, 그것들은 HTML과 XML 속성(attribute)에 대해서는 콘텐트 속성(attribute)으로, IDL 인터페이스에서 명시된 것에 대해서는 IDL 속성(attribute)으로 지칭합니다. 유사하게, "속성(property)"이라는 용어는 자바스크립트 객체 속성(property)와 CSS 속성(property) 모두에 대해 사용됩니다. 이것들이 모호한 경우 각각 객체 속성(property)과 CSS 속성(property)으로서 자격이 주어집니다 .

일반적으로, 명세가 기능이 HTML 구문 혹은 XHTML 구문에 적용된다고 서술하는 경우, 둘 다 포함하는 것입니다. 기능이 명확하게 두 언어 중 하나에만 적용하는 경우 "HTML에 대해, ... (이것은 XHTML에 적용하지 않습니다)" 처럼, 다른 형식에 적용하지 않는다고 명시적으로 서술하여 불립니다.

이 명세는 짧은 정적 문서로부터 긴 에세이나 리치 멀티미디어가 있는 리포트, 뿐만아니라 훌륭한 인터랙티브 어플리케이션에 이르기까지 모든 HTML의 사용에 지칭하는데 document이라는 용어를 사용합니다. 이 용어는 Document 객체와 그 객체의 후손 DOM 트리 둘 모두를 지칭하는데, 그리고 상황에 따라 HTML 구문이나 XHTML 구문을 사용하여 직렬화된 바이트 스트림을 지칭하는데 사용됩니다.

DOM 구조의 경우, HTML 문서와 XML 문서라는 용어는 DOM 명세에서 정의된 대로 사용되고, Document 객체가 찾아질 수 있는 두 다른 모드를 명확하게 지칭합니다. [DOM] (그런 사용법은 항상 그들의 정의에 하이퍼링크 되어 있습니다.)

바이트 스트림의 경우, HTML 문서라는 용어는 text/html로 라벨링 된 리소스를 지칭하고, XML 문서라는 용어는 XML MIME 타입으로 라벨링 된 리소스를 지칭합니다.

XHTML 문서라는 용어는 상황에 따라, HTML 네임스페이스 내 요소(element) 노드를 포함하는 XML 문서 모드인 문서와 HTML 네임스페이스의 요소를 포함하는 XML MIME 타입으로 라벨링 된 바이트 스트림을 지칭하는데 사용됩니다.

간결성을 위해, shown, displayed, visible와 같은 용어들은 (종종) 문서가 사용자에게 렌더링되는 방법을 지칭할 경우 사용됩니다. 이 용어들은 시각적 매체를 의미하는 것이 아닙니다; 동등한 방법으로 다른 매체에도 적용될 수 있도록 고려되어야 합니다.

알고리즘 B가 다른 알고리즘 A로 돌아간다 말하는 경우, A가 B를 호출했음을 의미합니다. A로 돌아가면, 구현은 B의 호출에서 멈춘 곳에서부터 계속 진행해야 합니다. 일부 알고리즘은 병렬로 수행합니다; 이것은 알고리즘의 다음 단계가 명세 내 다른 로직과 동시에 (예를 들어, 이벤트 반복이 동시에) 잇따라서 수행 됨을 의미합니다. 이 명세는 다른 하이퍼쓰레드, 코어, CPU, 기계 등을 사용하여 시분할 다중 작업, fibers, 프로세스가 달성되는 정밀한 메커니즘을 정의하지 않습니다. 그와 대조적으로, 즉시 수행하기 위한 작업은 현재 수행 중인 작업을 중단하고 수행해야 하며, 그후 이전에 수행 작업을 재개해야 합니다.

"투명한 검정"이라는 용어는 빨강, 초록, 파랑, 알파 채널이 모두 0으로 설정된 색상을 지칭합니다.

2.1.1. 리소스

유저 에이전트가 외부 리소스의 의미(semantics)를 디코딩할 수 있는 구현을 가지는지를 지칭하는 경우 명세는 지원된다라는 용어를 사용합니다. 형식(format)이나 유형(type)은 구현이 외부 리소스의 중요한 측면이 무시되지 않고 그 형식(foramt)이나 유형(type)의 리소스를 처리할 수 있다면 지원된다고 불립니다. 특정 리소스가 지원되는지 여부는 리소스의 형식이 사용되는 기능에 따라 달라질 수 있습니다.

예를 들어, PNG 이미지는 구현에 알려지지 않은 이미지가 애니메이션 데이터를 포함하고 있다 하더라도 픽셀 데이터가 디코드되고 렌더링 될 수 있다면 구현 지원되는 형식(format)으로 간주될 것입니다.

MPEG-4 비디오 파일은 사용된 압축 형식(format)이 지원되지 않았다면, 구현이 파일의 메타데이터로부터 영상의 크기를 결정할 수 있다하더라도 지원되는 형식(format)으로 간주되지 않을 것입니다.

일부 명세가, 특히 HTTP 명세에서, 표현(representation)으로 지칭된 것은 이 명세에서 리소스로 지칭됩니다. [HTTP]

MIME 타입 이라는 용어는 프로토콜 문서에서 종종 인터넷 미디어 타입으로 불리는 것을 지칭하는데 사용됩니다. 이 명세에서 media 타입 이라는 용어는 CSS 명세에 의해 사용된 것 처럼, 표현을 위해 의도된 미디어의 유형을 지칭하는데 사용됩니다. [RFC2046] [MEDIAQ]

문자열이 media-type 규칙과 일치한다면 유효한 MIME 타입입니다. 특히 유효한 MIME 타입은 MIME 타입 파라미터들을 포함할 수 있습니다. [HTTP]

문자열이 media-type 규칙과 일치하지만, 어떤 U+003B 세미콜론 문자 (;)도 포함하지 않는다면 파라미터를 가지지 않는 유효한 MIME 타입입니다. 다시 말해, 그것이 MIME 타입 파라미터 없이 오로지 타입과 서브 타입으로만 구성된다면. [HTTP]

HTML MIME 타입 이라는 용어는 MIME 타입 text/html를 지칭하는데 사용됩니다.

리소스의 중요한 하위 리소스들은 완전히 처리되기 위해 사용 가능(available)해야 하는 것이 필요한 리소스 입니다. 어떤 자원이 중요한 것으로 간주되거나 그렇지 않은 지는 리소스의 형식(format)을 정의하는 명세에 의해 정의되어 있습니다.

data: URL이라는 용어는 data: 스킴을 URLs 사용하는 URL들을 지칭합니다. [RFC2397]

2.1.2. XML

HTML에서 XHTML로 쉽게 마이그레이션 하기 위해, 이 명세를 따르는 유저 에이전트들은 적어도 DOM과 CSS의 용도를 위해 https://www.w3.org/1999/xhtml 네임스페이스의 HTML에 요소(element)들을 위치시킬 것입니다. "HTML 요소"라는 용어는 이 명세에서 사용될 경우, 그 네임스페이스의 요소를 지칭하고, 따라서 HTML과 XHTML 요소들 모두를 지칭합니다.

달리 명시된 것을 제외하고, 이 명세에 정의되거나 언급된 모든 요소(element)들은 HTML 네임스페이스 ("https://www.w3.org/1999/xhtml")에 있고, 이 명세에 정의되거나 언급된 모든 속성(attribute)들은 네임스페이스를 가지지 않습니다.

요소(element) 유형은 주어진 로컬 이름과 네임스페이스를 가진 요소들의 세트를 지칭하는데 사용됩니다. 예를 들어, button 요소(element)는 로컬 이름 "button"과 (위에 정의된 대로 암묵적으로) HTML 네임스페이스를 가지는 것을 의미하는, 요소 유형을 가진 요소(element)입니다.

속성(attirbute) 이름은 XML에 정의된 Name 생성과 일치하고 U+003A 콜론 문자(:)를 포함하지 않는다면 XML 호환 가능하다 불립니다. [XML]

XML MIME 타입이라는 용어는 MIME 타입 text/xml, application/xml, 서브 타입이 4개 문자 "+xml"로 끝나는 MIME 타입을 지칭하는데 사용됩니다. [RFC7303]

2.1.3. DOM 트리

Document 객체의 루트 요소(element)는 그 Document의 첫 번째 자식이 있다면 그것입니다. 첫 번째 자식이 없다면 Document는 루트 요소(element)가 없습니다.

루트 요소(element)라는 용어는, Document 객체의 루트 요소(element)를 지칭하지 않는 경우, 검토되는 노드의 가장 먼 조상 요소(element) 노드나 조상 노드가 없다면 자기 자신을 의미합니다.노드가 문서의 일부인 경우, 노드의 요소(element)는 확실히 문서의 루트 요소(element)입니다; 하지만, 노드가 현재 문서 트리의 일부가 아니라면, 루트 요소(element)는 부모가 없는 노드일 것입니다.

요소(element)의 루트 요소(element)가 Document 객체의 루트 요소(element)인 경우, 이 요소(element)는 Document 안에 있다고 불립니다. 요소(element)는 그것의 루트 요소(element)가 변경되고 그 요소(element)가 이제 문서의 루트 요소(element)인 경우, 문서에 삽입 되었다고 불립니다. 비슷하게, 요소(element)는 그것의 루트 요소(element)가 문서의 루트 요소(element)에서 다른 요소(element)로 변경되는 경우 문서에서 제거 되었다고 불립니다.

노드의 홈 서브트리가 그 노드의 루트 요소(element)에 루트를 둔 서브트리입니다. 노드가 Document안에 있는 경우, 그것의 홈 서브트리는 그 Document의 트리입니다.

Node(요소(element) 같은)의 Document는 Node의 ownerDocument IDL 속성(attribute)이 반환하는 Document 입니다. Node가 Document 안에 있는 경우 그 Document는 항상 Node의 Document이고, Node의 ownerDocument IDL 속성(attribute)은 따라서 항상 Document를 반환합니다.

콘텐트 속성(attribute)의 Document는 속성(attirbute)의 요소(element)의 Document입니다.

트리 순서라는 용어는 (parentNode/childNodes 관계를 통해) 수반된 DOM 노드의 전위 순회, 깊이 우선 탐색을 의미합니다.

어떤 요소(element)나 속성(attribute)이 무시되거나, 어떤 다른 값으로 취급되거나, 마치 또 다른 것처럼 처리되는 것으로 명시되는 경우, 이것은 노드가 DOM 안에 위치된 이후 처리되는 것을 지칭합니다.

콘텐트 속성(attribute)는 그것의 새로운 값이 이전 값과 다를 경우에 한해 값을 바꾼다라고 불립니다; 이미 가지고 있던 값으로 속성을 설정하는 것은 바꾸는 것이 아닙니다.

Text 노드, 문자열 속성 값이 비어있음으로 기술되는 경우, 그것은 텍스트의 길이가 0임을 의미합니다. (즉, 공백이나 제어 문자조차도 아닙니다).

요소(element)의 자식 텍스트 콘텐트는 트리 순서에서 요소(element)의 자식(주석이나 요소(element)같은 다른 노드는 제외하고)인 모든 Text 노드의 data의 연결입니다.

삽입 단계가 인자로 A를 가지고 작동되고 A의 새로운 부모가 B인 경우 노드 B에 노드 A가 삽입됩니다. 비슷하게, removedNode 인자로 A와 oldParent 인자로 B를 가지고 제거 단계가 작동되는 경우 노드 B로부터 노드 A가 제거 됩니다.

2.1.4. 스크립팅

Foo가 실제로 인터페이스인 경우, 구조 "Foo 객체"는 때때로 좀 더 정확한 "Foo 인터페이스를 구현하는 객체" 대신 사용됩니다.

IDL 속성(attribute)는 그것의 값이 검색 되는(예를 들어, 작성자 스크립트에 의해) 경우 가져온다라고 불리고 새로운 값이 할당되는 경우 설정한다라고 불립니다.

DOM 객체가 존속된다라고 불리는 경우, 그 객체의 속성(attribute)과 메서드(method)는 데이터의 스냅샷이 아닌, 실제 내부 데이터로 운용되어야 합니다.

이벤트의 측면에서, 발생과 발송이라는 용어는 DOM 명세에서 정의된 대로 사용됩니다: 이벤트가 발생한다는 것은 생성하고 발송 한다는 것을 의미하고, 이벤트를 발송한다는 것은 트리를 통해 이벤트를 전파하는 단계를 따른다는 것을 의미합니다. 신뢰할 수 있는 이벤트는 isTrusted 속성(attribute)이 true로 초기화 된 이벤트를 지칭하는데 사용됩니다. [DOM]

2.1.5. Plugin 콘텐트 처리기

plugin이라는 용어는 유저 에이전트에 의해 사용될 수 있는 콘텐츠 처리기의 유저 에이전트 정의 세트를 지칭합니다. 콘텐트 처리기는 유저 에이전트의 Document 객체의 렌더링에 참여할 수 있지만, Document의 자식 브라우징 컨텍스트로 행동하거나 Document의 DOM에 임의의 Node 객체를 도입하지 않습니다.

일반적으로 그러한 콘텐트 처리기들은 서드 파티로 제공되기는 하지만, 유저 에이전트는 내장 콘텐트 처리기도 플러그인으로 지정할 수 있습니다.

유저 에이전트는 text/plain과 application/octet-stream 유형을 등록된 플러그인을 가지는 것으로 간주해서는 안됩니다.

플러그인의 한 가지 예는 사용자가 PDF 파일을 탐색할 때 브라우징 컨텍스트에 인스턴스화 된 PDF 뷰어일 것입니다. 이것은 PDF 뷰어 컴포넌트를 구현한 단체가 유저 에이전트를 구현한 단체와 동일한지 여부와 상관 없이 플러그인으로 인정할 것입니다. 하지만, 유저 에이전트와 분리되어 시작하는 (동일한 인터페이스를 사용하는 것이 아닌) PDF뷰어 어플리케이션은 이 정의에 의해 플러그인이 아닙니다.

이 명세는 플러그인이 유저 에이전트와 플랫폼 종속인 것으로 예상되기 때문에 플러그인과 상호작용에 대한 메커니즘을 정의하지 않습니다. 일부 유저 에이전트들은 넷스케이프 플러그인 API와 같은 플러그인 메커니즘을 지원하는 것을 선택할 수 있습니다; 또 어떤 것들은 원격 콘텐트 변환기를 사용하거나 특정 유형에 대한 내장 지원을 가질 수도 있습니다. 실제로, 이 명세는 플러그인을 지원하는 유저 에이전트들이 전혀 필요하지 않습니다. [NPAPI]

플러그인은 sandbox 속성(attribute)의 의미(semantics)를 만족하면 보호 될 수 있습니다.

예를 들어, 보호된 플러그인은 플러그인이 샌드박스 된 iframe 안에서 인스턴스화 된 경우 콘텐트가 팝업 윈도우를 생성하는 것을 차단할 것입니다.

브라우저는 플러그인을 위해 의도된 외부 콘텐트와 상호작용을 할 경우 극도의 주의를 기울여야(should) 합니다. 서드 파티 소프트웨어가 유저 에이전트처럼 동일한 특권을 가지고 수행되는 경우, 서드 파티 소프트웨어의 취약성은 유저 에이전트의 취약성이 있는 것만큼 위험하게 됩니다.

다른 plugins 세트를 가지는 다른 사용자는 사용자를 유일하게 식별되게 하는 기회를 증가시키는 지문 그림을 제공하기 때문에, 유저 에이전트들은 각 사용자에 대해 정확히 동일한 플러그인 세트를 지원하도록 권장 됩니다.

2.1.6. 문자 인코딩

문자 인코딩, 혹은 애매모호하지 않은 인코딩은 WHATWG 인코딩 표준에 정의된 대로, 바이트 스트림과 유니코드 문자열 사이를 전환하기 위한 정의된 방법입니다. 인코딩은, 인코딩 표준에 인코딩의 이름과 라벨로 지칭된, 인코딩 이름이나 하나 이상의 인코딩 라벨을 가집니다. [ENCODING]

UTF-16 인코딩은 UTF-16BE나 UTF-16LE입니다. [ENCODING]

ASCII 호환 인코딩은 UTF-16 인코딩이 아닌 모든 인코딩입니다. [ENCODING]

WHATWG 인코딩 표준에 정의되지 않은 인코딩에 대한 지원은 금지되어 있기 때문에, UTF-16 인코딩은 이 명세가 ASCII 호환 인코딩이 되지 않는 것으로 처리할 필요가 있는 유일한 인코딩입니다.

코드 단위이라는 용어는웹 IDL 명세에 정의된 대로 사용됩니다: DOMString의 가장 작은 최소 구성 요소인 16비트 무부호 정수입니다. (이것은 유니코드에 사용된 것 보다 좁은 정의이고 code point와 동일하지 않습니다.) [WEBIDL]

유니코드 코드 포인트라는 용어는 그것이 가능한 경우 유니코드 스칼라 값을 의미하고, 불가능한 경우 독자적인 대용 코드 포인트(isolated surrogate code point)를 의미합니다. 적합성 요구사항이 이 문자나 유니코드 코드 포인트 용어로 정의되는 경우, 낮은 대용 코드가 뒤따르는 높은 대용 코드로 구성되는 한 쌍의 코드 단위는 대용 코드쌍으로 나타나는 단일 코드 포인트로 취급되어야 하지만, 독자적인 대용 코드는 각각 대용 코드의 값을 가지고 단일 코드로 취급 되어야 합니다. [UNICODE]

이 명세에서, 문자라는 용어는, 유니코드 문자로서 자격이 없는 경우, 유니코드 코드 포인트 용어와 같은 것을 의미합니다.

유니코드 문자는 유니코드 스칼라 값을 의미하는데 사용됩니다.(즉, 독자적인 코드 포인트가 아닌 모든 유니코드 코드 포인트) [UNICODE]

문자열의 코드 단위 길이는 그 문자열의 코드 단위들의 갯수입니다.

이 복잡성은 유니코드 문자의 용어에서 보다 16비트(UTF-8) 코드 단위(UTF-16)의 용어에서 DOM API를 정의하기 위한 역사적인 결정이 원인입니다.

2.2. 적합성 요구사항

이 명세의 모든 다이어그램, 예제, 주석은 모든 섹션에 비범적이라고 명시적으로 표시된 것 처럼 비규범적입니다. 이 명세에서 다른 모든 것들은 규범적입니다.

이 문서의 규범적 부분에 있는 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "OPTIONAL" 키워드들은 RFC2119에 설명된 대로 해석되어야 합니다. 이 문서의 규범적인 부분에 있는 "OPTIONALLY" 키워드는 "MAY"와 "OPTIONAL"처럼 동일한 규범적 의미로 해석되어야 합니다. 가독성을 위해, 이 단어들은 이 명세에서 모두 대문자 글자로 나타내지는 않습니다. [RFC2119]

본 번역본에서는 가급적 위 표기들을 한글과 함께 영문을 괄호 안에 표기하려 하고 있으나, 깜박하고 놓치고 지나갈 수 있기 때문에 가급적 위 키워드와 관련된 한글 표현에 대해서는 영문으로 된 원문과 비교하여 보시기를 권합니다.

알고리즘의 일부분으로 명령조로 표현된 요구사항들은("선두의 모든 공백 문자를 제거"나 "false를 반환하고 이 단계들을 중단" 같은) 알고리즘 도입에 사용되는 키워드("must", "should", "may", 등등)의 의미(meaning)로 해석되어야 합니다.

To eat an orange, the user must:
1. Peel the orange.
2. Separate each slice of the orange.
3. Eat the orange slices.

To eat an orange:
1. The user must peel the orange.
2. The user must separate each slice of the orange.
3. The user must eat the orange slices.

알고리즘이나 구체적인 단계들로 표현된 적합성 요구사항은 최종 결과가 동등한 것이기만 하면 임의의 방법으로 구현될 수 있습니다. (특히, 이 명세에 정의된 알고리즘은 쉽게 따라할 수 있도록 의도된 것이고, 고성능이 되도록 의도된 것이 아닙니다.)

2.2.1. 적합성 종류

이 명세는 유저 에이전트들과 (구현자에 관련된) 문서에 (작성자와 작성 도구 구현자에 관련된) 대한 적합성 기준을 설명합니다.

적합한 문서는 문서에 대한 모든 적합성 기준을 따르는 문서입니다. 가독성을 위해, 이 적합성 요구사항의 일부는 작성자에 대한 적합성 요구사항으로 표현됩니다; 그 요구사항들은 암묵적으로 문서에 대한 요구사항입니다: 정의에 의해, 모든 문서들은 작성자가 있었다고 가정됩니다. (어떤 경우, 그 작성자는 유저 에이전트 자체가 될 수 있습니다. — 그러한 유저 에이전트들은 아래 설명된 대로, 추가적인 규칙의 적용을 받습니다.)

예를 들어, 요구사항이 "작성자는 foobar 요소(element)를 사용하지 않아야(must not) 합니다" 라고 명시한다면, 이는 문서가 foobar라고 명명된 요소(element)를 포함하는 것을 허용하지 않는다는 것을 암시합니다.

문서 적합성 요구사항과 구현 적합성 요구사항 사이의 암묵적인 관계는 없습니다. 유저 에이전트는 원하는 대로 부적합한 문서를 처리하는데 자유롭지 않습니다; 이 명세에 설명된 처리 모델은 입력 문서의 적합성에 상관없이 구현에 적용됩니다.

유저 에이전트는 서로 다른 적합성 요구사항을 가진 몇 가지 범주에 (중복하여) 속합니다.

웹 브라우저와 다른 인터랙티브 유저 에이전트들

XHTML 구문을 지원하는 웹 브라우저는 이 명세에 설명된 대로 XML 문서에서 찾아지는 HTML 네임스페이스의 요소(element)와 속성(attribute)을 처리 해야(must)하기 때문에, 그 요소들의 의미(semantics)가 다른 명세에 의해 재정의되지 않는 한 사용자는 그것들을 가지고 상호작용 할 수 있습니다.

적합한 HTML 처리기는, XHTML 문서에서 XHTML script 요소(element)를 찾자마자, 그 요소에 포함된 스크립트를 실행합니다. 하지만, 요소가 XSLT에서 표현된 변형 내에서 찾아진다면 (유저 에이전트가 XSLT도 지원한다고 가정하여), 처리기는 대신 변형의 일부를 형성하는 불분명한 요소(element)로서 script 요소(element)를 대신 다룰 것입니다.

HTML 구문을 지원하는 웹 브라우저는 이 명세에 설명된 대로 HTML MIME 타입으로 라벨링 된 문서를 처리해야(must) 하기 때문에, 사용자는 그 문서와 상호작용 할 수 있습니다.

스크립팅을 지원하는 유저 에이전트들은 또한 웹 IDL 명세에 정의된 대로, 이 명세의 IDL 코드 조각의 구현이 준수되어야(must) 합니다. [WEBIDL]

명시적으로 명시되지 않은 한, HTML 요소(element)들의 의미(semantics)를 재정의 하는 명세는 그 요소(element)들을 나타내는 DOM 객체에서의 요구사항을 재정의 하지 않습니다. 예를 들어, 위 예제에서 script 요소(element)는 여전히 HTMLScriptElement 인터페이스를 구현합니다.

비상호작용 프리젠테이션 유저 에이전트들

순수하게 HTML과 XHTML 문서의 비상호작용 버전을 렌더링하기 위해 문서를 처리하는 유저 에이전트는, 사용자 인터랙션에 관하여 요구사항이 면제되는 것을 제외하고, 웹 브라우저 같이 동일한 적합성 기준을 따라야(must) 합니다.

비상호작용 유저 에이전트의 전형적인 예는 프린터(정적 유저 에이전트들)와 오버헤드 디스플레이(동적 유저 에이전트들)입니다. 대부분의 정적 비상호작용 프리젠테이션 유저 에이전트도 스크립팅 지원을 필요로 하기로 선택할 것이 예상됩니다.

비상호작용이지만 동적 프리젠테이션 유저 에이전트는, 동적으로 전송되는 양식을 허용 하는등으로, 여전히 스크립트를 실행합니다. 그러나, 사용자가 문서와 상호작용 할 수 없는 경우 "focus"의 개념이 상관없기 때문에, 유저 에이전트는 포커스 관련 DOM API를 지원할 필요가 없습니다.

제안된 기본 렌더링을 지원하는 시각적 유저 에이전트들

유저 에이전트는, 상호작용이든 아니든, 이 명세에 정의된 제안된 기본 렌더링을 지원하는 것으로 (아마도 사용자 옵션으로) 지정됩니다.

이것은 필요하지 않습니다. 특히, 제안된 기본 렌더링을 구현하는 유저 에이전트도 사용자에 대한 경험을 개선하기 위해, 예를 들어 색상 대비를 바꾸거나, 다른 포커스 스타일을 사용하거나, 그렇지 않으면 사용자에게 더 접근 가능하고 사용 가능한 경험을 만들기 위해, 이 기본 값을 재정의 하는 설정을 제공하도록 권장됩니다.

제안된 기본 렌더링을 지원하는 것으로 지정된 유저 에이전트는, 그렇게 지정된 동안, §10 Rendering 섹션 내 규칙을 구현해야(must) 합니다. 그 섹션은 유저에이전트가 구현할 것으로 기대되는 행동을 정의합니다.

스크립트를 지원하지 않는 유저 에이전트들

스크립팅을 지원하지 않는(혹은 스크립트 기능이 완전히 비활성화 된) 구현은 이벤트와 이 명세에서 언급된 DOM 인터페이스 지원이 면제됩니다. 이벤트 모델의 측면이나 DOM의 측면에서 정의된 이 명세의 일부에 대해, 그런 유저 에이전트는 여전히 이벤트와 DOM이 지원된 것처럼 수행해야 합니다.

스크립팅은 어플리케이션의 필수적인 부분을 형성할 수 있습니다. 스크립팅을 지원하지 않거나 스크립트가 비활성화 된 웹 브라우저는 작성작의 의도를 완전히 전달 할 수 없을 수도 있습니다.

적합성 검사기

적합성 검사기는 이 명세에 정의된 적절한 적합성 기준을 따르는 문서를 검증해야(must) 합니다. 자동화 된 적합성 검사기는 작성자 의도의 해석을 요구하는 오류를 발견하는 것은 적용되지 않습니다. (예를 들어, blockquote 요소(element)의 콘텐트가 따옴표로 묶여있지 않다면 문서는 비적합 함에도 불구하고, 사람의 판단의 입력 없이 수행하는 적합성 검사기는 blockquote 요소(element)가 인용된 문장만을 포함함을 검사할 필요가 없습니다.)

적합성 검사기는 입력 문서가 브라우징 컨텍스트 없이 해석되는 경우 (스크립가 수행되지 않고, 해석기의 스크립팅 플래그가 비활성화 된 것을 의미) 적합한지 검사해야(must) 하고, 또한 입력 문서가 스크립트를 수행하는 브라우징 컨텍스트를 가지고 해석되는 경우 적합한지, 그리고 스크립트는 스크립트가 자신을 수행하는 동안 비적합 상태가 다른 것을 발생시키는 것을 야기하지 않음을 검사해야(should) 합니다. (이것은 불가능한 것으로 증명되었기 때문에 "SHOULD"일 뿐 "MUST" 요구사항이 아닙니다. [COMPUTABLE])

"HTML 유효성 검사기"라는 용어는 이 명세의 적절한 요구사항을 준수하는 적합성 검사기를 지칭하는데 사용될 수 있습니다.

XML DTD는 이 명세의 모든 적합성 요구사항들을 나타낼 수 없습니다. 그러므로, 검증 XML 처리기와 DTD는 적합성 검사기가 될 수 없습니다. 또한, 이 명세에 정의된 두 가지 작성 형식(format) 어느 것도 SGML 어플리케이션이 아니기 때문에 검증 SGML 시스템 역시 적합성 검사기가 될 수 없습니다.

바꿔 말하면, 3가지 유형의 적합성 기준이 있습니다:

1. DTD에 표현될 수 있는 기준.

2. DTD에 표현될 수 없지만, 여전히 기계(machine)에 의해 검사 될 수 있는 기준.

3. 사람에 의해서만 검사 될 수 있는 기준.

적합성 검사기는 처음 두 가지에 대해 검사해야(must) 합니다. 간단한 DTD 기반 유효성 검사기는 첫 번째 등급의 오류에 대해서만 검사하고 그렇기 때문에 이 명세를 따르는 적합한 적합성 검사기가 아닙니다.

데이터 마이닝 도구

문서를 렌더링 하거나 적합성에 대해 검사를 하는 것 외에 다른 이유로 HTML과 XHTML 문서를 처리하는 어플리케이션과 도구들은 그들이 처리하는 문서의 의미(semantics)에 부합하게 수행해야(should) 합니다.

문서 아웃라인을 생성하지만 각 문단에 대한 중첩 레벨을 증가시키고 각 섹션에 대한 중첩 레벨을 증가시키지 않는 도구는 부적합 할 것입니다.

작성 도구와 마크업 생성기

작성 도구와 마크업 생성기는 적합한 문서를 생성해야(must) 합니다. 작성자에게 적용되는 적합성 기준은 또한 작성 도구에 적용합니다.

작성 도구는 오직 작성 도구가 아직 작성자 의도를 결정할 수 없는 정도에만, 명시된 목적에 대한 요소(element) 사용의 요구사항이 적용되지 않습니다. 하지만, 저작 도구는 자동으로 요소(element)를 오용하거나 사용자가 그렇게 하는 것을 권장해서는(must) 안됩니다.

예를 들어, 임의의 연락 정보를 위해 address 요소(element)를 사용하는 것은 비적합합니다; 그 요소(element)는 문서나 섹션의 작성자에 대한 연락 정보를 마크업 하는 용도로만 사용 가능합니다. 하지만, 작성 도구는 차이를 결정하는 것이 불가능 할 것이기 때문에, 작성 도구는 그 요구사항이 적용 되지 않습니다. 그러나 이것은 작성 도구가 임의의 이탤릭체 본문(예를 들어)을 위해 address 요소(element)를 사용할 수 있다는 것을 의미하지 않습니다; 사용자가 섹션이나 다른 무언가에 대한 연락 정보를 삽입한다면, 그것은 단지 작성 도구가 검증할 필요가 없다는 것을 의미합니다.

적합성 검사의 측면에서, 편집기는 접근성 검사기가 검증하는 동일한 범위를 준수하는 문서를 출력해야 합니다.

작성 도구가 비적합한 문서를 편집하는데 사용되는 경우, 편집 세션 동안 편집되지 않은 문서의 섹션 내의 적합성 오류를 보존할 수 있습니다.(즉, 편집 도구는 잘못된 콘텐트 왕복을 허용합니다.) 그러나, 저작 도구는 오류가 그렇게 보존된다면 출력이 준수하다고 주장해서는(must) 안됩니다.

저작 도구는 두 개의 광범위한 종류로 제공 될 것으로 예상됩니다: 구조적 혹은 의미론적 데이터에서 동작하는 도구와, What-You-See-Is-What-You-Get 매체 특정 편집 기준에서 동작하는 도구(WYSIWYG) 입니다.

소스 정보의 구조는 어떤 HTML 요소(element)와 속성(attribute)이 가장 적절한지에 관하여 선택을 하는데 사용될 수 있기 때문에, 전자는 HTML을 작성하는 도구에 대한 선호된 메커니즘입니다.

하지만, WYSIWYG 도구는 타당합니다. WYSIWYG 도구는 그것이 적절하다고 알고 있는 요소(element)들을 사용해야(should) 하고, 그것이 적절하다고 알지 못하는 요소(element)들을 사용해서는(should) 안됩니다. 이것은 어떤 극단적인 경우에 플로우 요소(flow element)의 사용을 div, b, i, span과 같은 단지 몇 가지 요소(element)로 제한하는 것과 style를 자유롭게 사용하는 것을 의미할 수 있습니다.

WYSIWYG 이든 아니든 모든 작성 도구는 사용자들이 잘 구조화 되고, 의미론적으로 풍부하며, 미디어 독립적인 콘텐트를 만드는 것이 가능하도록 최선의 노력을 기울여야(should) 합니다.

유저 에이전트는 그 외 자유로운 입력에 구현 특정(implementation-specific) 제한, 예를 들어 서비스 거부 공격을 막기 위한 제한, 또는 메모리 부족이 생기지 않도록 하기 위한 제한, 또는 플랫폼 특정 한계를 피하기 위한 제한을 부과할 수 있습니다.

기존 콘텐트와 이전 명세와의 호환성을 위해, 이 명세는 두 가지 작성 형식을 설명합니다: 하나는 XML(XHTML 구문으로 언급되는) 기반, 그리고 하나는 SGML (HTML 구문으로 언급되는)에 영감을 받은 사용자 정의 형식입니다. 구현은 이 두가지 형식 중 적어도 하나를 지원해야(must) 하지만, 둘 모두를 지원하는 것이 권장됩니다.

일부 적합성 요구사항은 요소(element), 속성(attribute), 메서드(method), 객체(object)의 요구사항으로 표현됩니다. 그러한 요구사항은 두 가지 범주로 나뉩니다: 콘텐츠 모델 제약사항을 기술하는 것과 구현 동작을 기술하는 것. 전자의 범주의 것은 문서와 작성 도구의 요구사항입니다. 두 번째 범주의 것은 유저 에이전트의 요구사항입니다. 비슷하게, 일부 적합성 요구사항은 저자에 대한 요구사항으로 표현됩니다; 그러한 요구사항은 작성자가 생산한 문서에 대한 적합성 요구사항으로 해석되어야 합니다. (다시 말해, 이 명세는 저자에 대한 적합성 기준과 문서에 대한 적합성 기준을 구분하지 않습니다.)

2.2.2. 의존성

이 명세는 몇 다른 기초적인 명세에 의존합니다.

유니코드와 인코딩

유니코드 문자 집합은 텍스트 데이터를 나타내는데 사용되고, 인코딩 표준은 문자 인코딩 요구사항을 정의합니다. [UNICODE]

이 명세는 앞서 설명된 대로, 그 명세에 정의된 용어에 기초하여 전문용어를 소개합니다.

다음 용어들은 인코딩 표준에 정의된 대로 사용됩니다: [ENCODING]

• 인코딩 가져오기

• 출력 인코딩 가져오기

• 바이트 스트림과 인코딩을 가져오고 문자 스트림을 반환하는 일반 디코드 알고리즘

• 선두의 UTF-8 바이트 순서 표식(BOM)이 있다면 제거하여, 바이트 스트림을 가져오고 문자 스트림을 반환하는 UTF-8 디코드 알고리즘

• 선두의 UTF-8 바이트 순서 표식(BOM)을 제거하지 않는 것을 제외하고 UTF-8 디코드와 동일한 BOM 없는 UTF-8 디코드 알고리즘

• 오류를 만날 때 실패가 반환되는 BOM 없는 UTF-8 디코드와 동일한 BOM 없는 UTF-8 디코드나 실패 알고리즘

• 문자 스트림과 인코딩을 가져오고 바이트 스트림을 반환하는 인코드 알고리즘

• 문자 스트림을 가져오고 바이트 스트림을 반환하는 UTF-8 인코드 알고리즘

XML 그리고 관련된 명세

XHTML 구문을 지원하는 구현은 XML의 여러 버전뿐 아니라, 그 구문이 네임스페이스를 가진 XML 직렬화를 사용하기 때문에, 해당하는 네임스페이스 명세를 지원해야(must) 합니다. [XML] [XML-NAMES]

XML 네임스페이스에서 xml:space 태그 이름을 가진 속성(attribute)은 XML 명세에 의해 정의되어 있습니다. [XML]

이 명세는 또한, 스타일 시트와 XML 문서를 연관짓기 명세에 정의된, <?xml-stylesheet?> 처리 명령을 참조합니다. [XML-STYLESHEET]

이 명세는 또한 비규범적으로 XSLTProcessor 인터페이스와 그것의 transformToFragment()와 transformToDocument() 메서드를 언급합니다.

URLs

다음 용어들은 WHATWG URL 표준에 정의되어 있습니다: [URL]

• host

• domain

• URL

• URL의 Origin

• 절대 URL

• 상대 URL

• 상대 스키마

• URL 해석기와 기본 URL 해석기, 그리고 이 해석기 단계:

  • 스키마 시작 단계

  • host 단계

  • hostname 단계

  • port 단계

  • path 시작 단계

  • query 단계

  • fragment 단계

• URL 레코드, 그리고 그것의 각 구성 요소:

  • 스키마(scheme)

  • 사용자 이름

  • 비밀번호

  • 호스트

  • 포트

  • 경로

  • 쿼리

  • 프래그먼트(fragment)

• 네트워크 스키마

• URL 직렬 변환기

• 호스트 해석기

• 호스트 직렬 변환기

• 호스트 동등성

• 정수 직렬화

• 기본 인코드 세트

• 퍼센트 인코드

• UTF-8 퍼센트 인코드

• 퍼센트 디코드

• 사용자 이름 설정

• 비밀번호 설정

• 도메인을 ASCII로 변환 알고리즘

• 도메인을 유니코드로 변환 알고리즘

• 비관련 플래그

• URL 해석기에서 해석 오류

몇 가지 스키마와 프로토콜들은 또한 이 명세에 의해 참조됩니다:

• about: 스키마 [RFC6694]

• blob: 스키마 [FILEAPI]

• data: 스키마 [RFC2397]

• http: 스키마 [HTTP]

• https: 스키마 [HTTP]

• mailto: 스키마 [RFC6068]

• sms: 스키마 [RFC5724]

• urn: 스키마 [URN]

HTTP 그리고 관련된 명세

다음 용어들은 HTTP 명세에 정의되어 있습니다: [HTTP]

• Accept 헤더

• Accept-Language 헤더

• Cache-Control 헤더

• Content-Disposition 헤더

• Content-Language 헤더

• Content-Length 헤더

• Last-Modified 헤더

• Referer 헤더

다음 용어들은 쿠키(Cookie) 명세에 정의되어 있습니다: [COOKIES]

• 쿠키 문자열

• 쿠키 설정 문자열 수신

• Cookie 헤더

다음 용어들은 웹 링크하기(Web Linking) 명세에 정의되어 있습니다: [RFC5988]

• Link 헤더

가져오기(Fetch)

다음 용어들은 WHATWG Fetch 표준에 정의되어 있습니다: [FETCH]

• about:blank

• HTTPS 상태 값

• 리퍼러(referrer) 정책

• CORS 프로토콜

• 기본 User-Agent 값

• MIME 타입 추출

• 가져오기(fetch)

• ok 상태

• Origin 헤더

• 응답 처리

• 설정

• 종료

• RequestCredentials 열거

• 응답과 그와 연관된:

  • 유형

  • url

  • url 목록

  • 상태

  • 헤더 목록

  • 몸체

  • 내부 응답

  • CSP 목록

  • HTTPS 상태

• 요청과 그와 연관된:

  • url

  • 메서드

  • 헤더 목록

  • 몸체

  • 클라이언트(client)

  • 타겟 브라우징 컨텍스트

  • 개시자

  • 유형

  • 목적지

  • origin

  • Origin 헤더 생략 플래그

  • 동일 출처(origin) data-URL 플래그

  • 리퍼러(referrer)

  • 동기(synchronous) 플래그

  • 모드(mode)

  • 자격 증명 모드

  • URL 자격 증명 사용 플래그

  • 안전하지 않은 요청 플래그

  • 캐시 모드

  • 리다이렉트(redirect) 모드

  • 암호용 넌스 메타데이터

  • 해석기 메타 데이터

웹 IDL

이 명세에서 IDL 코드 조각은 웹 IDL 명세에 정의된 대로, IDL 코드 조각에 적합하도록 요구된 대로 해석되어야(must) 합니다. [WEBIDL]

다음 용어들은 Web IDL 명세에 정의되어 있습니다:

• 배열 인덱스 속성(property) 이름

• 지원되는 속성(property) 인덱스

• 인덱싱 된 속성(property)의 값 측정

• 명명된 속성(property) 지원

• 지원되는 속성(property) 이름

• 명명된 속성(property)의 값 측정

• 보안 검사 수행

• 플랫폼 객체

• 플랫폼 객체와 연관된 전역 환경

• 읽기 전용 (배열에 적용될 경우)

• 이 값을 콜백

• 웹 IDL과 JS 유형 사이 전환하기

• 웹 IDL 콜백 함수 호출

웹 IDL 명세는 또한 이 명세의 웹 IDL 코드 조각에 사용된 다음 유형들을 정의합니다:

• ArrayBufferView

• boolean

• DOMString

• USVString

• double

• Error

• Function

• long

• object

• unrestricted double

• unsigned long

이 명세에서 던지다(throw)라는 용어는 WebIDL 명세에 정의된 대로 사용됩니다. 다음 예외 이름들은 WebIDL에서 정의되고 이 명세에서 사용됩니다:

• IndexSizeError

• HierarchyRequestError

• InvalidCharacterError

• NotFoundError

• NotSupportedError

• InvalidStateError

• SyntaxError

• InvalidAccessError

• SecurityError

• NetworkError

• QuotaExceededError

• TimeoutError

• DataCloneError

이 명세가 유저 에이전트가 특정 시간(특별한 값 Not-a-Number이 될 수 있는)을 나타내는 Date 객체 생성을 요구하는 경우, 그 시간의 밀리초 요소가 있다면 이는 정수로 잘라내져야(must) 하고, 새롭게 생성된 Date 객체의 시간 값은 결과적으로 잘라낸 시간을 나타내야(must) 합니다.

예를 들어, 2000년 1월 1일 01:00 UTC 이후 100만분의 23045초, 즉 2000-01-01T00:00:00.023045Z가 주어진 경우, 100만분의 45초 빠른, 2000-01-01T00:00:00.023Z를 나타내도록 생성된 Date 객체와 동일한 시간을 나타내는 Date 객체가 생성됩니다. 주어진 시간이 NaN이라면, 결과는 시간 값 NaN을 나타내는 (객체가 특정 시간을 나타내지 않는 것을 보여주는) Date 객체입니다.

자바스크립트

이 명세에 의해 설명되는 언어의 일부분은 오직 기본 스크립팅 언어로 자바스크립트를 지원합니다. [ECMA-262]

"자바스크립트"라는 용어는 공식적인 ECMAScript라는 용어보다 자바스크립트라는 용어가 좀 더 널리 알려져있기 때문에 ECMA262를 지칭하는데 사용됩니다. 비슷하게, 이 명세에서 자바스크립트를 지칭하는데 사용된 MIME 타입은 text/javascript이 거의 보통 사용되는 유형이기 때문에, RFC 4329에 따라 공식적으로 폐기된 유형임에도 불구하고 text/javascript입니다. [RFC4329]

다음 용어들은 자바스크립트 명세에 정의 되고 이 명세에서 사용됩니다 [ECMA-262]:

• 자동 세미콜론 삽입

• 조기 오류

• 지시어 프롤로그

• 자바스크립트 실행 컨텍스트

• 자바스크립트 실행 컨텍스트 스택

• 자바스크립트 실행 컨텍스트 수행

• 자바스크립트 범위

• 현재 범위 레코드

• 엄격한 규칙 사용(use strict) 지시어

• 다음을 포함하는 잘 알려진 기호:

  • @@hasInstance

  • @@isConcatSpreadable

  • @@toPrimitive

  • @@toStringTag

• 다음을 포함하는 잘 알려진 고유한 객체들:

  • %ArrayBuffer%

  • %ArrayPrototype%

  • %ObjProto_toString%

  • %ObjProto_valueOf%

• 함수 몸체 산출물

• 패턴 산출물

• 스크립트 산출물

• 형(type) 표기법

• 리스트와 레코드 명세 유형

• 속성(property) 서술자 명세 유형

• ArrayCreate 추상적 연산

• Call 추상적 연산

• CloneArrayBuffer 추상적 연산

• Construct 추상적 연산

• CreateDataProperty 추상적 연산

• DetachArrayBuffer 추상적 연산

• EnqueueJob 추상적 연산

• FunctionCreate 추상적 연산

• Get 추상적 연산

• GetActiveScriptOrModule 추상적 연산

• GetFunctionRealm 추상적 연산

• HasOwnProperty 추상적 연산

• HostEnsureCanCompileStrings 추상적 연산

• HostPromiseRejectionTracker 추상적 연산

• InitializeHostDefinedRealm 추상적 연산

• IsAccessorDescriptor 추상적 연산

• IsCallable 추상적 연산

• IsConstructor 추상적 연산

• IsDataDescriptor 추상적 연산

• IsDetachedBuffer 추상적 연산

• NewObjectEnvironment 추상적 연산

• OrdinaryGetPrototypeOf 추상적 연산

• OrdinarySetPrototypeOf 추상적 연산

• OrdinaryIsExtensible 추상적 연산

• OrdinaryPreventExtensions 추상적 연산

• OrdinaryGetOwnProperty 추상적 연산

• OrdinaryDefineOwnProperty 추상적 연산

• OrdinaryGet 추상적 연산

• OrdinarySet 추상적 연산

• OrdinaryDelete 추상적 연산

• OrdinaryOwnPropertyKeys 추상적 연산

• ParseScript 추상적 연산

• RunJobs 추상적 연산

• SameValue 추상적 연산

• ScriptEvaluation 추상적 연산

• ToBoolean 추상적 연산

• ToString 추상적 연산

• ToUint32 추상적 연산

• TypedArrayCreate 추상적 연산

• 관념적 동일 비교 알고리즘

• 엄격한 동일 비교 알고리즘

• ArrayBuffer 객체

• Date 객체

• SyntaxError 객체

• TypeError 객체

• RangeError 객체

• RegExp 객체

• typeof 연산자

• 형색화 배열 생성자 표

DOM

문서 객체 모델(DOM)은 문서와 그것의 콘텐트의 표현 — 모델 —입니다. DOM은 단지 API가 아닙니다; HTML 구현의 적합성 기준은 DOM에서의 작업의 관점에서 이 명세에 정의되어 있습니다. [DOM]

구현은 이 명세가 DOM과 DOM 인터페이스로의 확장으로 정의되는 몇 가지 기능의 관점에서 정의되기 때문에 DOM과 UI 이벤트에 정의된 이벤트를 지원해야(must) 합니다. [DOM] [UIEVENTS]

특히, 다음 기능들은 DOM 명세에 정의되어 있습니다: [DOM]

• Attr 인터페이스

• Comment 인터페이스

• DOMImplementation 인터페이스

• Document 인터페이스

• XMLDocument 인터페이스

• DocumentFragment 인터페이스

• DocumentType 인터페이스

• DOMException 인터페이스

• ChildNode 인터페이스

• Element 인터페이스

• Node 인터페이스

• NodeList 인터페이스

• ProcessingInstruction 인터페이스

• Text 인터페이스

• HTMLCollection 인터페이스

• item() 메서드

• 컬렉션과 컬렉션에 의해 표현되는이라는 용어

• DOMTokenList 인터페이스

• createDocument() 메서드

• createHTMLDocument() 메서드

• createElement() 메서드

• createElementNS() 메서드

• getElementById() 메서드

• getElementsByClassName() 메서드

• insertBefore() 메서드

• appendChild() 메서드

• cloneNode() 메서드

• importNode() 메서드

• childNodes 속성(attribute)

• localName 속성(attribute)

• parentNode 속성(attribute)

• namespaceURI 속성(attribute)

• tagName 속성(attribute)

• id 속성(attribute)

• textContent 속성(attribute)

• 노드에 대한 insert, append, remove, replace, adopt 알고리즘

• insertion 단계, removing 단계, adopting 단계 훅(hook)

• 속성(attirbute) 목록 개념.

• 텍스트 노드의 data.

• Event 인터페이스

• EventTarget 인터페이스

• EventInit 사전형

• target 속성(attribute)

• currentTarget 속성(attribute)

• isTrusted 속성(attribute)

• initEvent() 메서드

• addEventListener() 메서드

• 이벤트의 type

• 이벤트 리스너의 개념과 EventTarget과 연관된 이벤트 리스너.

• 타겟 재정의의 개념

• 일반 이벤트 부모의 개념과 교차방식의 이벤트 부모

• 인코딩 (여기에서 문자 인코딩)과 Documentdml 콘텐트 유형

• XML 문서와 HTML 문서 사이의 차이

• 쿽크 모드, 제한된 쿼크 모드, 비쿼크 모드라는 용어

• Node를 복제하기 위한 알고리즘과, 그 알고리즘에 의해 사용되는 복제 단계의 개념

• 기본 URL 변경 단계의 개념과 요소(element)가 기본 URL 변경에 의해 영향을 받는 경우 발생하는 것의 정의

• 요소의 고유 식별자 (ID)의 개념

• 지원되는 토큰이라는 용어

• DOM 범위의 개념과, 범위에 적용되는 시작, 끝, 경계점이라는 용어.

• MutationObserver 인터페이스와 일반 변경 관찰자

이 명세에서 던지다라는 용어는 DOM 명세에 정의된 대로 사용됩니다. 다음 DOMException 유형들은 DOM 명세에 정의되어 있습니다: [DOM]

• IndexSizeError

• HierarchyRequestError

• WrongDocumentError

• InvalidCharacterError

• NoModificationAllowedError

• NotFoundError

• NotSupportedError

• InvalidStateError

• SyntaxError

• InvalidModificationError

• NamespaceError

• InvalidAccessError

• SecurityError

• NetworkError

• AbortError

• URLMismatchError

• QuotaExceededError

• TimeoutError

• InvalidNodeTypeError

• DataCloneError

예를 들어, TimeoutError 예외를 던지기 위해, 유저 에이전트는 유형이 문자열 "TimeoutError"이고(그리고 레거시 이유로, 코드가 23번인) 실제로 예외로 그 객체를 던지는 DOMException 객체를 구성할 것입니다.

다음 기능들은 UI 이벤트 명세에 정의되어 있습니다: [UIEVENTS]

• MouseEvent 인터페이스와 다음 인터페이스 멤버:

  • relatedTarget 속성(attribute)

  • button 속성(attribute)

  • ctrlKey 속성(attribute)

  • shiftKey 속성(attribute)

  • altKey 속성(attribute)

  • metaKey 속성(attribute)

  • getModifierState() 메서드

• MouseEventInit 사전형

• FocusEvent 인터페이스와 그것의 relatedTarget 속성(attribute)

• UIEvent 인터페이스의 view와 detail 속성(attribute)

• click 이벤트

• dblclick 이벤트

• mousedown 이벤트

• mouseenter 이벤트

• mouseleave 이벤트

• mousemove 이벤트

• mouseout 이벤트

• mouseover 이벤트

• mouseup 이벤트

• wheel 이벤트

• keydown 이벤트

• keyup 이벤트

• keypress 이벤트

다음 기능들은 터치 이벤트 명세에 정의되어 있습니다: [TOUCH-EVENTS]

• Touch 인터페이스

• 터치 포인트 개념

이 명세는 때때로 이벤트의 type을 지칭하기 위해, "click이라고 명명된 이벤트"나 "이벤트 이름이 keypress라면"의 경우와 같이, 이름이라는 용어를 사용합니다. 이벤트에 대한 "이름"과 "타입"이라는 용어는 동의어입니다.

다음 기능들은 DOM 해석과 직렬화 명세에 정의되어 있습니다: [DOM-Parsing]

• innerHTML

• outerHTML

Selection 인터페이스는 선택 API 명세에 정의되어 있습니다. [SELECTION-API]

유저 에이전트는 또한 HTML 편집 API들과 UndoManager와 DOM 처리 명세에 설명된 기능들을 구현하도록 권장됩니다. [EDITING] [UNDO]

풀스크린 명세의 다음 부분들은, 풀스크린 API가 HTML에서 샌드박싱 기능과 상호작용하는 방법을 정의하기 위한 부분에서, 이 명세에서 참조됩니다: [FULLSCREEN]

• 최상위 레이어 개념

• requestFullscreen()

• 풀스크린 가능 플래그

• 풀스크린을 완전히 나가는 알고리즘

고분해능 시간 명세는 DOMHighResTimeStamp 형식 정의와 Performance 객체의 now() 메서드를 제공합니다. [HR-TIME-2]

파일 API

이 명세는 파일 API 명세에 정의된 다음 기능들을 사용합니다: [FILEAPI]

• Blob 인터페이스

• File 인터페이스

• FileList 인터페이스

• closed의 개념 Blob

• Blob.type

• 읽기 오류의 개념

미디어 소스 확장

다음 용어들은 미디어 소스 확장 명세에 정의되어 있습니다: [MEDIA-SOURCE]

• 미디어 요소(element)로부터 분리

• MediaSource [MEDIA-SOURCE]

미디어 캡쳐와 스트림

다음 용어는 미디어 캡쳐와 스트림 명세에 정의되어 있습니다: [MEDIACAPTURE-STREAMS]

• MediaStream [MEDIACAPTURE-STREAMS]

XMLHttpRequest

이 명세는 두 명세가 상호 작용하는 방법을 설명하기 위해 XMLHttpRequest 명세를 참조합니다. 다음 기능들과 용어들은 XMLHttpRequest 명세에 정의되어 있습니다: [XHR]

• XMLHttpRequest 인터페이스

• XMLHttpRequest.responseXML 속성(attribute)

ProgressEvent

이 명세는 두 명세가 상호작용하는 방법과 그것의 ProgressEvent 기능을 사용하는 방법을 설명하기 위해 프로그레스 이벤트(Progress Events) 명세를 참조합니다. 다음 기능은 프로그레스 이벤트 명세에 정의되어 있습니다: [PROGRESS-EVENTS]

• ProgressEvent 인터페이스

• ProgressEvent.lengthComputable 속성(attribute)

• ProgressEvent.loaded 속성(attribute)

• ProgressEvent.total 속성(attribute)

• e로 명명된 프로그레스 이벤트를 발생

서버 발송 이벤트(Server-Sent Events)

이 명세는 서버 발송 이벤트 명세에 명시된 EventSource를 참조합니다. [EVENTSOURCE]

미디어 쿼리(Media Queries)

구현은 미디어 쿼리 언어를 지원해야(must) 합니다. [MEDIAQ]

CSS 모듈(modules)

CSS를 전체적으로 지원하는 것은 이 명세의 구현에 필요하지 않지만(권장되기는 하지만, 웹 브라우저에 대해 최소한), 일부 기능들은 CSS 특정 요구사항의 관점에서 정의되어 있습니다.

특히, 일부 기능은 문자열이 CSS <color> 값으로 해석 되는 것을 요구합니다. CSS 값을 해석하는 경우, 유저 에이전트는 CSS 명세에 의해 일부 오류 처리 규칙이 적용되도록 요구됩니다. 이것들은 이 명세에도 적용됩니다. [CSS3COLOR] [CSS-2015]

예를 들어, 유저 에이전트는 스타일 시트의 끝을 찾자마자 모든 열려진 구성을 닫도록 요구됩니다. 따라서, 색상 값에 대한 문자열 "rgb(0,0,0" (닫는 괄호가 누락된)을 해석하는 경우, 이 오류 처리 규칙에 의해 닫는 괄호가 암묵적이 되고, 값이 얻어집니다 (색상 검정). 하지만, 비슷한 구성 "rgb(0,0,"는 (괄호와 "blue" 값이 모두 누락된) 열려진 구성을 닫는 것이 실행 가능한 값이 되지 않기 때문에 해석될 수 없습니다.

다음 용어들과 기능들은 CSS 명세에 정의되어 있습니다: [CSS-2015]

• 뷰포트(viewport)

• 대체 요소(element)

• 고유 치수

명명된 색상이라는 용어는 CSS 색상 명세에 정의되어 있습니다. [CSS3COLOR]

고유 너비와 고유 높이라는 용어는 각각 고유 치수의 너비 치수와 높이 치수를 지칭합니다.

페인트 소스를 제공한다는 용어는 CSS 'element()' 함수와 특정 HTML 요소(element)의 상호작용을 정의하기 위해 CSS 이미지 값과 대체 콘텐트 명세에 정의된 대로 사용됩니다. [CSS3-IMAGES]

기본 객체 사이즈라는 용어 역시 CSS 이미지 값과 대체 콘텐트 명세에 정의되어 있습니다. [CSS3-IMAGES]

스크립팅을 지원하는 구현은 CSS 객체 모델을 지원해야 합니다. 다음 기능들과 용어들은 CSSOM 명세에 정의되어 있습니다: [CSSOM] [CSSOM-VIEW]

• Screen

• LinkStyle

• CSSStyleDeclaration

• CSSStyleDeclaration의 cssText 속성(attribute)

• StyleSheet

• CSS 스타일 시트 생성

• CSS 스타일 시트 제거

• 연관된 CSS 스타일 시트

• CSS 스타일 시트와 프로퍼티(propetry)들: type, location, 부모 CSS 스타일 시트, 소유자 노드, 소유자 CSS 규칙, media, title, alternate 플래그, disabled 플래그, CSS 규칙, origin-clean 플래그

• 대체 스타일 시트 세트와 우선되는 스타일 시트 세트

• CSS 값 직렬화

• 크기 조정 단계 수행

• 스크롤 단계 수행

• 미디어쿼리 평가와 변경 보고

• 뷰(view) 안으로 요소(element)를 스크롤

• 문서의 시작 부분으로 스크롤

• resize 이벤트

• scroll 이벤트

• window.open의 특징 인자(argument)

다음 기능들과 용어들은 CSS 구문 명세에 정의되어 있습니다: [CSS-SYNTAX-3]

• 구성 값들의 콤마로 구분된 목록 해석

• 구성 값

• 환경 인코딩

• <whitespace-token>

<length> 특성은 CSS 값과 단위 명세에 정의되어 있습니다. [CSS-VALUES]

CSS 스타일링 속성(attribute)라는 용어는 CSS Style 속성(attribute) 명세에 정의되어 있습니다. [CSS-STYLE-ATTR]

CanvasRenderingContext2D 객체의 폰트 사용은 CSS 폰트와 폰트 로딩 명세에 설명된 기능에 따라, 특히 FontFace 객체와 폰트 소스 개념을 포함하여, 달라집니다. [CSS-FONTS-3] [CSS-FONT-LOADING-3]

다음 인터페이스는 외형 인터페이스 모듈(Geometry Interfaces Module) 명세에 정의되어 있습니다: [GEOMETRY-1]

• DOMMatrix 인터페이스

SVG

CanvasRenderingContext2D 객체의 폰트 사용은 CSS 폰트와 폰트 로딩 명세에 설명된 기능에 따라, 특히 FontFace 객체와 폰트 소스 개념을 포함하여, 달라집니다. [CSS-FONTS-3] [CSS-FONT-LOADING-3]

다음 인터페이스는 SVG 명세에 정의되어 있습니다: [SVG11]

• SVGMatrix

WebGL

다음 인터페이스는 WebGL 명세에 정의되어 있습니다: [WEBGL]

• WebGLRenderingContext

WebVTT

구현은 미디어 리소스에 대한 자막(subtitle), 캡션(caption), 챕터 제목, 메타데이터 등으로서 WebVTT를 지원할 수 있습니다. [WEBVTT]

이 명세에 사용된 다음 용어들은 WebVTT 명세에 정의되어 있습니다:

• WebVTT 파일

• 큐 텍스트를 사용하는 WebVTT 파일

• 챕터 제목 텍스트를 사용하는 WebVTT 파일

• 중첩된 큐만을 사용하는 WebVTT 파일

• WebVTT 해석기

• WebVTT 텍스트 트랙의 표시 갱신을 위한 규칙

• WebVTT 큐 텍스트 해석을 위한 규칙

• WebVTT 텍스트 트랙 큐 쓰기 방향

웹소켓 프로토콜

다음 용어들은 웹소켓 프로토콜 명세에 정의되어 있습니다: [RFC6455]

• 웹 소켓 연결 수립

• 웹 소켓 연결 수립됨

• 서버 응답 검증

• 쓰이고 있는 확장

• 쓰이고 있는 서브프로토콜

• 적절한 쿠키를 보내기 위한 헤더

• 서버의 여는 핸드쉐이크(opening handshake) 동안 쿠키 설정

• 웹소켓 메세지가 수신되었습니다

• 웹소켓 메시지 전송

• 웹소켓 연결 실패

• 웹소켓 연결 종료

• 웹소켓 닫는 핸드쉐이크(closing handshake) 시작

• 웹소켓 닫는 핸드쉐이크(closing handshake)가 시작되었습니다

• 웹소켓 연결이 종료되었습니다 (아마도 완전히)

• 웹소켓 연결 종료 코드

• 웹소켓 연결 종료 사유

• Sec-WebSocket-Protocol 필드

ARIA

role 속성(attirbute)는 다음 역할(role)들과 같이 ARIA 명세에 정의되어 있습니다: [WAI-ARIA]

• alert

• alertdialog

• application

• article

• banner

• button

• checkbox

• columnheader

• combobox

• complementary

• contentinfo

• dialog

• directory

• document

• grid

• gridcell

• group

• heading

• img

• link

• list

• listbox

• listitem

• log

• main

• marquee

• menu

• menubar

• menuitem

• menuitemcheckbox

• menuitemradio

• navigation

• note

• option

• presentation

• progressbar

• radio

• region

• row

• rowgroup

• rowheader

• search

• separator

• slider

• spinbutton

• status

• tab

• tablist

• textbox

• toolbar

• tree

• treeitem

게다가, 다음 aria-* 콘텐트 속성(attribute)는 ARIA 명세에 정의되어 있습니다: [WAI-ARIA]

• aria-checked

• aria-describedby

• aria-disabled

• aria-expanded

• aria-hidden

• aria-invalid

• aria-label

• aria-level

• aria-multiline

• aria-multiselectable

• aria-owns

• aria-readonly

• aria-required

• aria-selected

• aria-sort

• aria-valuemax

• aria-valuemin

• aria-valuenow

콘텐트 보안 정책

다음 용어들은 콘텐트 보안 정책에 정의되어 있습니다: [CSP3]

• 콘텐트 보안 정책

• 콘텐트 보안 정책 지시어

• 콘텐트 보안 정책 구문

• 정책 시행

• 직렬화된 콘텐트 보안 정책 해석 알고리즘

• 전역 객체의 CSP 목록 초기화 알고리즘

• 문서의 CSP 목록 초기화 알고리즘

• 요소(element)의 인라인 동작은 콘텐트 보안 정책에 의해 차단되어야(should) 하는가? 알고리즘

• report-uri, frame-ancestors, sandbox 지시어

• EnsureCSPDoesNotBlockStringCompilation 추상화 알고리즘

• 문서에 대해 허용된 base인가? 알고리즘

다음 용어들은 콘텐트 보안 정책: 문서 특징에 정의되어 있습니다.

• frame-ancestors 지시어

• sandbox 지시어

서비스 워커

다음 용어들은 서비스 워커에 정의되어 있습니다: [SERVICE-WORKERS]

• 서비스 워커 등록 매칭

이 명세는 임의의 특정 네트워크 프로토콜, 스타일 시트 언어, 스크립팅 언어, 위 목록에 요구된 것들을 넘어선 임의의 DOM 명세의 지원을 요구하지 않습니다. 하지만, 이 명세에 설명된 언어는 스타일 언어로 CSS에, 스크립트 언어로 자바스크립트에, 네트워크 프로토콜에 HTTP에 관심을 두고 있고, 몇가지 기능들은 그 언어와 프로토콜들이 사용되고 있는 것으로 추정됩니다.

HTTP 프로토콜을 구현하는 유저 에이전트는 웹 출처 개념(Web Origin Concept) 명세와 HTTP 상태 관리 메커니즘 명세(쿠키) 역시 구현해야(must) 합니다. [HTTP] [ORIGIN] [COOKIES]

이 명세는 각각의 섹션에서 문자 인코딩, 이미지 형식, 오디오 형식, 비디오 형식에 대한 추가적인 요구사항을 가질 수 있습니다.

2.2.3. 확장성

벤더 특정 소유 유저 에이전트가 이 명세를 확장하는 것은 강력하게 지양됩니다. 문서는 사용자의 특정 유저 에이전트만이 문제의 콘텐트를 접근하는 것을 허용하여 상호 운용성을 줄이고 사용자 기반을 파편화하기 때문에 그러한 확장을 사용해서는(must) 안됩니다.

그러한 확장이 그렇더라도 필요하다면, 예를 들어 실험적인 목적으로, 벤더들은 다음 확장 메커니즘의 사용이 강력히 권장됩니다:

• XML 직렬화에 제한될 수 없고 HTML 직렬화에 지원될 필요가 없는 마크업 레벨 기능에 대해, 벤더들은 비표준 요소(element)와 속성(attribute)이 지원되는 사용자 정의 네임스페이스를 정의하기 위한 네임스페이스 메커니즘을 사용해야(should) 합니다.

• HTML 구문을 사용하도록 의도된 마크업 레벨 기능에 대해, 확장은 vendor가 확장에 대한 벤더 책임을 확인하는 짧은 문자열이고 feature가 기능의 이름인"x-vendor-feature" 형식의 새로운 속성(attirbute)로 제한되어야(should) 합니다. 새로운 요소(element) 이름은 생성되어서는(should) 안됩니다. 그러한 확장을 위한 속성(attribute) 사용은 독점적으로 여러 벤더로부터의 확장이 동일한 요소(element)에 공존하는 것을 허용하고, 이 요소는 요소로 가능하지 않습니다. "x-vendor-feature" 형식을 사용하는 것은 확장이 향후 명세에 추가 사항과 충돌하는 위험성 없이 되는 허용합니다.

  예를 들어, "FerretBrowser"라는 브라우저는 벤더 프리픽스(prefix)로 "ferret"를 사용할 수 있고, 반면 "Mellblom Browser"라는 브라우저는 "mb"를 사용할 수 있습니다. 이 브라우저들 모두 요소(element)를 scratch-and-sniff 영역으로 설정하는 확장을 고안한다면, 이 기능을 실험하는 작성자는 다음과 같이 작성할 수 있습니다:

  <p>이것은 레몬 냄새가 납니다!
  <span x-ferret-smellovision x-ferret-smellcode="LEM01"
  x-mb-outputsmell x-mb-smell="lemon juice"></span></p>
  

두 문자 x-"로 시작하는 속성(attribute)이름은 유저 에이전트가 사용하기 위해 예약 되었고 HTML 언에어 결코 공식적으로 추가되지 않을 것이 확실합니다. 유연성을 위해, 밑줄(U+005F LOW LINE 문자)을 포함하는 속성(attribute)이름 역시 실험적인 목적을 위해 예약 되었고 HTML 언어에 결코 공식적으로 추가되지 않을 것이 확실합니다.

그러한 속성(attribute)을 사용하는 페이지는 비 규범적 정의에 의합니다.

DOM 확장을 위해, 예를 들어 새로운 메서드와 IDL 속성(attribute), 새로운 멤버들은 이 명세의 미래 버전과 충돌하는 것을 방지하기 위해 벤더 특정 문자열이 앞에 붙어야(should) 합니다.

이벤트를 위해, 실험적인 이벤트 유형은 벤더 특정 문자열이 앞에 붙어야(should) 합니다.

모든 확장들은 확장의 사용이 모순되거나 명세에 정의된 기능성의 비적합이 야기되지 않도록 정의되어야 합니다

"x-vendor-feature" 형식의 콘텐트 속성에 상응하는 새로운 반영하는 IDL 속성(attribute)을 추가하는 경우, IDL 속성(attribute)은 "vendorFeature"라고 명명되어야(should) 합니다(즉, "x"는 IDL 속성(attribute)의 이름에서 빠집니다).

벤더 중립적인 확장이 이 명세에 필요한 경우, 이 명세가 그에 맞춰 업데이트 되거나, 확장 명세가 이 명세의 요구사항을 재정의하는 것이 기록될 수 있습니다. 이 명세를 그들의 액티비티에 적용하는 사람이 그러한 확장 명세의 요구사항을 인식할 것을 결정할 경우, 이 명세의 적합성 요구사항의 목적에 대해 적절한 명세가 됩니다.

누군가 임의의 적합한 바이트 스트림을 정의하는 명세를 작성하고, 이후 그들의 무작위 쓰레기가 적합하다고 주장할 수 있습니다. 하지만, 그것이 그들의 무작위 쓰레기가 실제로 모두의 목적에 대해 적합하다는 것을 의미하지 않습니다: 다른 누군가 명세가 그들의 작업에 적용하지 않는다고 결정한다면, 그들은 앞서 언급한 임의의 쓰레기가 단지 쓰레기이고 전혀 적합하지 않다고 꽤 정당하게 말할 수 있습니다. 적합성에 관한 한, 특정 커뮤니티에서 중요한 것은 그 커뮤니티가 동의하는 것이 적용된다는 것이다.

적용 가능한 명세.

문서에 대한 적합성 용어는 그러한 적용 가능한 명세에 의해 도입된 변경 사항과 문서의 콘텐트와 의도된 해석에 따라 달라집니다. 적용 가능한 명세는 새로운 문서 콘텐트(예를 들어 foobar 요소)를 정의하거나, 다른 특정 적합한 콘텐트를 금지하거나(예를 들어, <table>s의 사용을 금지), 의미(semantics), DOM 매핑, 이 명세에 정의된 콘텐트에 대한 처리 규칙을 변경할 수도 있습니다. 문서가 적합한 HTML 문서인지 아닌지는 적용 가능한 명세의 사용에 따르지 않습니다: 주어진 적합한 HTML 문서의 구문과 의미(semantics)가 적용 가능한 명세(들)의 사용에 의해 변경되지 않는다면, 그 문서는 여전히 적합한 HTML 문서 입니다. 주어진 (다른 적합한) 문서의 의미(semantics)나 처리가 적용 가능한 명세(들)의 사용에 의해 변경된다면, 그것은 적합한 HTML 문서가 아닙니다. 그러한 경우에 대해, 적용 가능한 명세는 적합성 용어를 정의해야(SHOULD) 합니다.

제안되었지만 요구된 규정이 아니기 때문에, 그러한 명세는 XXX가 적용 가능한 명세에 대한 짧은 이름 인 "적합한 HTML+XXX 문서"와 같은 적합성 용어를 정의 할 수 있습니다. (예: "적합한 HTML+AutomotiveExtensions 문서")

위에 주어진 규칙의 결과는 특정한 구문상으로 옳은 HTML 문서가 적용 가능한 명세가 있는 곳에서 적합한 HTML 문서가 아닐 수 있다는 것입니다. (예: 적용 가능한 명세는 <table>을 하나의 내용으로 정의합니다 — 그 명세에 작성되고 <table> 요소(element)를 포함하는 문서는 요소(element)가 구문적으로 옳은 HTML으로 되어 있더라도 적합한 HTML 문서가 아닙니다.)

유저 에이전트는 구문적으로 중립적인 것으로 이해할 수 없는 요소(element)와 속성(attribute)를 처리해야(must) 합니다; DOM에 그것들을 두고(DOM 처리기에 대해), CSS를 따라 스타일링 하지만 (CSS 처리기에 대해), 그것들로부터 어떠한 의미(meaning)도 끌어내지 않습니다.

기능에 대한 지원이 비활성 된 경우 (예를 들어, 보안 문제를 완화시키기 위해, 혹은 개발 지원을 위해, 혹은 성능 이유로 긴급한 조치로서), 유저 에이전트는 어떤 기능에 대해서도 지원이 없었던 것 처럼, 그리고 기능이 이 명세에 언급지 않은 것 처럼 수행해야(must) 합니다. 예를 들어, 특정 기능이 웹 IDL 인터페이스에서 속성(attribute)를 통해 접근된다면, 속성(attribute) 자체는 그 인터페이스를 구현하는 — 객체에 속성(attribute)를 두지만 null을 반환하거나 예외를 던지는(throw) 것을 불충분하게 하여 , 객체로부터 생략될 것입니다.

2.2.4. XPath와 XSLT와의 상호작용

이 명세에 설명된 방법으로(예를 들어, document.evaluate() API의 일부로) 해석되거나 생성된 HTML 문서에서 운용되는 XPath 1.0의 구현은 마치 다음 편집이 XPath 1.0 명세에 적용된 것처럼 수행해야(must) 합니다.

먼저, 이 문단을 제거합니다:

노드 테스트의 QName이 표현 맥락에서 네임스페이스 선언을 사용하여 확장된 이름으로 확장됩니다. 이것은 xmlns로 선언된 기본 네임스페이스가 사용되지 않는 것을 제외하고 시작 태그와 종료 태그의 요소 유형 이름에 대해 확장이 수행된 것과 같은 방식입니다: QName이 접두어를 가지지 않는다면, 네임스페이스 URI는 null입니다(이것은 속성 이름이 확장되는 것과 같은 방식 입니다). QName이 표현 맥락에 네임스페이스 선언이 없는 접두어를 가진다면 이것은 오류입니다.

그 후, 다음을 그 자리에 삽입합니다:

노드 테스트의 QName이 표현 맥락에서 네임스페이스 선언을 사용하여 확장된 이름으로 확장됩니다. QName이 접두어를 가진다면, 표현 맥락에 이 접두어에 대한 네임스페이스 선언이 존해해야(must) 하고, 해당하는 네임스페이스 URI는 이 접두어와 연관된 것이어야(must) 합니다. QName이 표현 맥락에 네임스페이스 선언이 없는 접두어를 가진다면 이것은 오류입니다.

QName이 접두어를 가지지 않고 주축의 주요 노드 타입이 요소(element)라면, 기본 요소(element) 네임스페이스가 사용됩니다. 그렇지 않고 QName이 접두어를 가지지 않는다면, 네임스페이스 URI는 null 입니다. 기본 요소(element) 네임스페이스는 XPath 표현에 대한 맥락의 멤버입니다. XPath 표현을 DOM3 XPath API를 통해 실행할 때 기본 요소(element) 네임스페이스의 값은 다음 방법으로 결정됩니다:

1. 컨텍스트 노드가 HTML DOM으로부터라면, 기본 요소(element) 네임스페이스는 "https://www.w3.org/1999/xhtml" 입니다.

2. 그렇지 않으면, 기본 요소(element) 네임스페이스 URI는 null입니다.

이것은 XPath 2.0의 기본 요소(element) 네임스페이스 기능을 XPath 1.0에 추가하는 것과, HTML 문서에 대한 기본 요소(element) 네임스페이스로서 HTML 네임스페이스를 사용하는 것과 동일합니다. 그것은 이 명세가 HTML 요소(element)에 대해 사용된 네임스페이스에 대하여 HTML에 도입하는 변경사항을 여전히 지원하는 동안 구현이 레거시 HTML 콘텐트와 호환되도록 하고자 하는 바람과, XPath 2.0보다 XPath 1.0을 사용하고자 하는 바람에 기인합니다.

이 변경은 Xpath 1.0 명세의 고의적 위반으로, 구현이 HTML 요소(element)에 대해 사용되는 네임스페이스에 대해 이 명세가 HTML에 도입하는 변경 사항을 여전히 지원하면서 레거시 콘텐트와 호환되도록 하고자 하는 바람에 기인합니다. [XPATH]

출력 메서드가 "html"인 경우 DOM으로 출력하는 XSLT 1.0 처리기는 (명시적으로 혹은 XSLT 1.0 기본 규칙을 통해) 다음과 같이 영향을 받습니다:

변환 프로그램이 네임스페이스 없이 요소(element)를 출력한다면, 처리기는, 해당 DOM 요소(element) 노드를 구성하기에 앞서, 요소(element)의 네임스페이스를 HTML 네임스페이스, 요소(element)의 ASCII-소문자 로컬 이름, 요소(element)에 네임스페이스 없는 속성(attribute)들의 ASCII-소문자 이름으로 변경해야(must) 합니다.

이; 요구사항은 XSLT 1.0 명세의 고의적 위반으로, 이 명세가 DOM 기반 XML 변경과 호환되지 않는 방법으로 네임스페이스와 대소문자를 구별하는 HTML의 규칙을 변경하기 때문입니다.(출력을 직렬화하는 처리기는 영향을 받지 않습니다.) [XSLT]

이 명세는 XSLT 처리가가 HTML 해석기 인프라와 상호작용 하는 방법을 정확하게 명시하지 않습니다(예를 들어, XSLT 처리기가 열린 요소(element) 스택에 임의의 요소(element)를 밀어 넣는 것처럼 수행하는지 여부). 하지만, XSLT 처리기는 그것이 성공적으로 완료되면 해석을 중지해야(must)하고, 현재 문서 준비상태를 먼저 "interactive"로 설정해야(must)하고 그 후 그것이 취소되면 "complete"로 설정해야(must)합니다.

이 명세는 XSLT가 탐색 알고리즘과 상호작용하는 방법, 이벤트 반복과 맞추는 방법, 오류 페이지가 처리되는 방법(예를 들어, XSLT 오류가 누적된 XSLT 출력을 대체하는 것인지 또는 인라인으로 렌더링 되는지 등)을 지정하지 않습니다.

script 요소(element) 섹션에 XSLT와 HTML의 상호작용, 그리고 template 요소(element) 섹션에 XSLT, XPath, HTML의 상호작용에 관한 추가적인 비규범적인 사족이 있습니다.

2.3. 대소문자 구별과 문자열 비교

대소문자 구분 방법으로 두 문자열을 비교하는 것은 코드 지점에 대해 코드 지점을 정확하게 비교한다는 것을 의미합니다.

ASCII 대소문자 비구분 방법으로 두 문자열을 비교하는 것은 U+0041에서 U+005A까지 범위의 문자(즉, 라틴 대문자 A부터 라틴 대문자 Z까지)와 U+0061에서 U+007A까지 범위에 해당하는 문자(즉, 라틴 소문자 A부터 라틴 소문자 Z까지)들이 모두 일치하는 것으로 간주되는 것을 제외하고, 코드 지점에 대해 코드 지점을 정확하게 비교한다는 것을 의미합니다.

호환되는 대소문자 무(無)구분 방법으로 두 문자열을 비교하는 것은 언어별 맞춤없이 두 문자열을 비교하기 위해 유니코드 호환되는 대소문자 무(無)구분 일치 연산을 사용하는 것을 의미합니다. [UNICODE]

달리 명시되지 않는 한, 문자열 비교는 대소문자 구분방법으로 수행되어야(must) 합니다.

문자열을 ASCII 대문자로 변환하는 것은 U+0061에서 U+007A 범위 (즉, 라틴 소문자 A부터 라틴 소문자 Z) 내 모든 문자를 U+0041에서 U+005A 범위 (즉, 라틴 대문자 A부터 라틴 대문자 Z) 내 해당하는 문자로 바꾸는 것을 의미합니다.

문자열을 ASCII 소문자로 변환하는 것은 U+0041에서 U+005A 범위 (즉, 라틴 대문자 A부터 라틴 대문자 Z) 내 모든 문자를 U+0061에서 U+007A 범위 (즉, 라틴 소문자 A부터 라틴 소문자 Z) 내 해당하는 문자로 바꾸는 것을 의미합니다.

문자열 pattern이 s보다 길지 않고 s를 pattern의 길이로 잘라내는 것이 두 문자열을 서로 일치하게 하는 경우 문자열 pattern은 문자열 s에 대한 접두어 일치입니다.

2.4. 공통 마이크로문법

HTML에는 날짜나 숫자 같은, 특정한 데이터 유형을 허용하는 다양한 위치가 있습니다. 이 섹션은 그러한 형식의 콘텐트에 대한 적합성 기준과 그것들을 해석하는 방법을 기술합니다.

구현자는 아래에 설명된 문법의 해석을 구현하기 위해 사용하는 것으로 간주될 수 있는 서드파티 라이브러리들을 주의 깊게 검토하도록 강력하게 권장됩니다. 예를 들어, 날짜 라이브러리는, 오류 처리 동작이 종종 이 명세에 사용된 것과 유사항 날짜 구문을 기술하는 명세에 정의 되어 있지 않기 때문에, 이 명세에 요구된 것과 다른 오류 처리 동작을 구현할 수 있고, 따라서 구현자는 오류를 처리하는 방법에서 크게 달라지는 경향이 있습니다.

2.4.1. 공통 해석기 표현

공백 문자는 이 명세의 목적에 따라, U+0020 공백(space), U+0009 탭 문자(tab), U+000A 라인피드 (LF), U+000C 서식 문자 (FF), and U+000D 캐리지 리턴 (CR)입니다.

여백 문자는 유니코드 PropList.txt 데이터 파일에 있는 유니코드 속성(property) "White_Space"을 가지는 문자 입니다. [UNICODE]

이 문자는 Unicode.txt 데이터 파일에 "Bidi_Class" 속성(property)의 "White_Space" 값 (약칭 "WS")과 혼동되지 않아야(should) 합니다.

제어 문자는 유니코드 "General_Category" 속성(property)이 유니코드 유니코드 UnicodeData.txt 데이터 파일의 "Cc" 값을 가지는 문자입니다. [UNICODE]

대문자 ASCII 글자는 U+0041 라틴 대문자 A부터 U+005A 라틴 대문자 Z까지 범위 내 문자입니다.

소문자 ASCII 글자는 U+0061 라틴 소문자 A부터 U+007A 라틴 소문자 Z까지 범위 내 문자입니다.

ASCII 숫자는 U+0030 숫자 0에서 U+0039 숫자 9까지 범위 내 문자입니다.

영숫자 ASCII 문자는 대문자 ASCII 글자, 또는 소문자 ASCII 글자, 또는 ASCII 숫자입니다.

ASCII 16진수는 U+0030 숫자 0부터 U+0039 숫자9, U+0041 라틴 대문자 A부터 U+0046 라틴 대문자 F, U+0061 라틴 소문자 A부터 U+0066 라틴 소문자 F 범위 내 문자입니다.

대문자 ASCII 16 진수는 U+0030 숫자 0부터 U+0039 숫자 9 그리고 U+0041 라틴 대문자 A부터 U+0046 라틴 대문자 F까지 범위 내 문자입니다.

소문자 ASCII 16 진수는 U+0030 숫자 0부터 U+0039 숫자 9 그리고 U+0061 라틴 소문자 A부터 U+0066 라틴 소문자 F까지 범위 내 문자입니다.

아래 설명된 일부 마이크로 해석기는 문자열이 해석되고 있도록 유지하고 있는 input 변수와 input에서 해석하기 위한 다음 문자를 가리키는 position 변수를 가지는 패턴을 따릅니다.

이 패턴을 기반으로하는 해석기의 경우, 유저 에이전트가 일련의 문자를 수집하도록 요구하는 단계는, 수집될 수 있는 문자의 집합이 되는 characters를 가지고, 다음 알고리즘을 수행해야(must) 함을 의미합니다:

1. input과 position를 이 단계들을 호출하는 알고리즘에 동일한 이름의 것들로서 같은 변수가 되도록 합니다.

2. result를 빈 문자열이 되게 합니다.

3. position이 input의 끝을 지나치지 않고 position에 위치한 문자가 characters의 하나인 경우, result의 끝에 문자를 추가하고 input 내 다음 문자로 position을 전진시킵니다.

4. result를 반환합니다.

여백 문자 건너뛰기 단계는 유저 에이전트가 공백 문자인 일련의 문자를 수집해야(must) 한다는 것을 의미합니다. 수집 된 문자는 사용되지 않습니다.

유저 에이전트가 문자열에서 줄 바꿈을 비워낼 경우, 유저 에이전트는 그 문자열에서 U+000A 라인피드 (LF)와 U+000D 캐리지 리턴 (CR)을 제거해야(must) 합니다.

유저 에이전트가 문자열에서 앞뒤 여백 문자를 비워낼 경우, 유저 에이전트는 문자의 시작과 끝에 있는 모든 공백 문자를 제거해야(must) 합니다.

유저 에이전트가 문자열 내 여백 문자를 들어내고 병합하는 경우, 그 문자열 내 일련의 하나 이상의 연속적인 공백 문자를 단일 U+0020 공백 문자로 바꾸고, 그 후 그 문자열에서 앞뒤 여백 문자를 비워내야(must) 합니다.

유저 에이전트가 특정 구분 문자 delimiter로 문자열을 엄격하게 분할해야 하는 경우, 다음 알고리즘을 사용해야(must)합니다:

1. input을 해석되는 문자열로 둡니다.

2. position을 초기에 문자열의 시작을 가리키는, input에 대한 포인터로 둡니다.

3. tokens를 초기에 비어있는, 정렬된 토큰의 목록으로 둡니다.

4. position가 input의 끝을 지나치지 않은 동안:

   1. delimiter 문자가 아닌 일련의 문자들을 수집합니다.

   2. 이전 단계에서 수집된 문자를 tokens에 추가합니다.

   3. input 내 다음 문자로 position을 전진시킵니다.

5. tokens을 반환합니다.

공백과 쉼표 문자로 분할하는 특수한 경우에 대해, 이 알고리즘은 적용되지 않습니다(그러한 알고리즘은 여백 트리밍 역시 수행합니다).

2.4.2. 불리언 속성(attribute)

여러 속성(attribute)들이 불리언 속성(attribute)입니다. 요소(element)에 불리언 속성(attribute)의 존재는 true 값을 나타내고, 속성(attribute)의 부재는 false 값을 나타냅니다.

속성(attribute)이 존재한다면, 그 값은 빈 문자열 혹은 속성(attribute)의 정식 이름에 대해, 앞 뒤 여백 없이 ASCII 대소문자 구분 없이 일치하는 값이어야(must) 합니다.

"true"와 "false" 값은 불리언 속성(attribute)에 허용되지 않습니다. false 값을 나타내려면 속성을 모두 생략해야(has to) 합니다.

<label><input type=checkbox checked name=cheese disabled> Cheese</label>

<label><input type=checkbox checked=checked name=cheese disabled=disabled> Cheese</label>

<label><input type='checkbox' checked name=cheese disabled=""> Cheese</label>

2.4.3. 키워드와 열거 속성(attribute)

일부 속성(attribute)은 키워드의 집합에서 하나를 취하는 것으로 정의됩니다. 그러한 속성(attribute)을 열거 속성이라고 부릅니다. 키워드는 각각 특정 상태에 매핑시키기 위해 정의됩니다 (몇몇 키워드는 동일한 상태로 매핑될 수 있고, 이 경우 일부 키워드는 서로의 유의어 입니다; 추가적으로, 일부 키워드는 부적합하다 불릴 수 있고, 전통적인 이유로 이 명세에만 존재합니다.) 게다가, 두 기본 상태가 주어질 수 있습니다. 첫 번째는 유효하지 않은 기본 값, 두 번째는 누락 기본 값입니다.

열거 속성이 명시된다면, 속성의 값은 앞뒤 여백 없이, 부적합하다 불리지 않는 주어진 키워드 중 하나에 ASCII 대소문자 구분 없이 일치 되어야(must) 합니다.

속성이 명시되는 경우, 그 값이 주어진 키워드 중 하나에 ASCII 대소문자 구분 없이 일치한다면 그 키워드의 상태는 속성(attribute)이 나타내는 상태입니다. 속성(attribute) 값이 주어진 키워드 중 일치하는 것이 없고 속성이 유효하지 않은 기본 값을 가진다면, 속성(attribute)은 그 상태를 나타냅니다. 그렇지 않고, 속성(attribute) 값이 키워드에 일치하는 것이 없고 정의된 누락 기본 값 상태가 있다면, 그것은 속성(attribute)에 의해 나타내어지는 상태 입니다. 그렇지 않으면, 기본 값은 없고, 유효하지 않은 값은 어떤 상태도 나타내지 않음을 의미합니다.

속성(attribute)이 명시되지 않은 경우, 정의된 누락 기본 값 상태가 있다면, 그것은 (누락된) 속성(attribute)에 의해 나타내어지는 상태입니다. 그렇지 않으면, 속성(attribute)의 부재는 나타내어지는 상태가 없음을 의미합니다.

빈 문자열은 유효한 키워드가 될 수 있습니다.

2.4.4. 숫자

2.4.4.1. 부호있는 정수

문자열이 하나 이상의 ASCII 숫자로 구성되고, 선택적으로 U+002D HYPHEN-MINUS 문자 (-)가 접두어로 붙는다면, 유효한 정수입니다.

U+002D HYPHEN-MINUS (-) 접두어가 없는 유효한 정수는 그 숫자의 문자열에 의한 10진수 숫자를 나타냅니다. U+002D HYPHEN-MINUS (-) 접두어가 있는 유효한 정수는 0에서 뺀, U+002D HYPHEN-MINUS 다음에 있는 숫자의 문자열에 의한 10진수 숫자를 나타냅니다.

정수 해석에 대한 규칙은 다음 알고리즘에 주어진 것과 같습니다. 이 알고리즘이 호출 될 때, 단계는 값을 반환하는 첫 번째 단계에서 중단하여, 주어진 순서에 따라야(must) 합니다. 이 알고리즘은 정수나 오류를 반환할 것입니다.

1. input을 해석되는 문자열로 둡니다.

2. position을 초기에 문자열의 시작을 가리키게 하여, input을 가리키게 합니다.

3. sign이 "양" 값을 가지게 합니다.

4. 여백을 건너뜁니다.

5. position이 input의 끝을 지났다면, 오류를 반환합니다.

6. position에 의해 가리켜진 문자(첫번째 문자)가 U+002D HYPHEN-MINUS 문자 (-)라면:

   1. sign을 "음"으로 둡니다.

   2. position을 다음 문자로 전진시킵니다.

   3. position이 input의 끝을 지났다면, 오류를 반환합니다.

   그렇지 않고, position에 의해 가리켜진 문자(첫번째 문자)가 U+002B PLUS 부호 문자 (+) 라면:

   1. position을 다음 문자로 전진시킵니다. ("+"는 무시되지만, 이는 부적합 합니다.)

   2. position이 input의 끝을 지났다면, 오류를 반환합니다.

7. position에 의해 가리켜진 문자가 ASCII 숫자가 아니라면, 오류를 반환합니다.

8. ASCII 숫자인 일련의 문자를 수집하고, 10진수 정수로 결과로 나온 시퀀스를 해석합니다. value를 그 정수로 둡니다.

9. sign이 "양"이라면, value를 반환하고, 그렇지 않으면 0에서 value를 뺀 결과를 반환합니다.

2.4.4.2. 음이 아닌 정수

문자열이 하나 이상의 ASCII 숫자로 구성된다면 유효한 음이 아닌 정수입니다.

유효한 음이 아닌 정수는 그 숫자의 문자열에 의해 10 진수로 나타내어지는 숫자를 나타냅니다.

음이 아닌 정수 해석에 대한 규칙은 다음 알고리즘에 주어진 것과 같습니다. 이 알고리즘이 호출될 때, 단계는 값을 반환하는 첫 번째 단계에서 중단하여, 주어진 순서에 따라야(must) 합니다. 이 알고리즘은 0이나 양의 정수, 혹은 오류를 반환할 것입니다.

1. input을 해석된 문자열로 둡니다.

2. value를 정수 해석에 대한 규칙을 사용하여 input을 해석한 결과로 둡니다.

3. value가 오류라면, 오류를 반환합니다.

4. value가 0보다 작다면, 오류를 반환합니다.

5. value를 반환합니다.

2.4.4.3. 부동 소수점 수

문자열이 다음으로 구성된다면 유효한 부동소수점 수입니다:

1. 선택적으로, U+002D HYPHEN-MINUS 문자 (-).

2. 주어진 순서에 따라, 다음 중 하나 혹은 모두:

   1. 일련의 하나 이상의 ASCII 숫자.

   2. 주어진 순서에 따라 다음 둘 모두:

      1. 단일 U+002E 마침표 문자 (.).

      2. 일련의 하나 이상의 ASCII 숫자.

3. 선택적으로:

   1. U+0065 라틴 소문자 E (e) 또는 U+0045 라틴 대문자 E (E).

   2. 선택적으로, U+002D HYPHEN-MINUS 문자 (-) 또는 U+002B PLUS 부호 문자 (+).

   3. 일련의 하나 이상의 ASCII 숫자.

유효한 부동소수점 수는 유효숫자에 10의 지수의 거듭 제곱과 곱하여 얻어진 숫자를 나타내고, 여기서 유효숫자는 10진수로 해석되는 (소수점과 소수점 이후 숫자가 있다면 이를 포함하여, 그리고 전체 숫자가 U+002D HYPHEN-MINUS 문자 (-)로 시작하고 숫자가 0이 아니라면 음수로서 유효숫자를 해석하여) 첫번째 숫자이고, 지수는 E 이후 숫자가 있다면 그 숫자 (E와 숫자 사이에 U+002D HYPHEN-MINUS (-) 문자가 있고 숫자가 0이 아니라면 음수로 해석되거나, E와 숫자 사이에 U+002B PLUS 부호 문자가 있다면 이를 무시하여)입니다. E가 없다면 지수는 0으로 간주됩니다.

Infinity와 Not-a-Number (NaN) 값은 유효한 부동소수점 수가 아닙니다.

부동 소수점 수로서 숫자 n의 가장 잘 표현된 표현은 ToString(n)을 수행하여 얻어진 문자열입니다. 추상 연산 ToString은 고유하게 결정되지 않습니다. 특정 값에 대해 ToString에서 얻어질 수 있는 가능한 여러 문자열이 있는 경우, 유저 에이전트는 항상 그 값에 대한 동일한 문자열을(다른 유저 에이전트에 의해 사용될 수 있는 값과 다를 수 있지만) 반환해야(must) 합니다.

부동 소수점 수 값 해석에 대한 규칙은 다음 알고리즘에 주어진 것과 같습니다. 이 알고리즘은 무언가를 반환하는 첫 번째 단계에서 중단되어야(must) 합니다. 이 알고리즘은 숫자나 오류를 반환할 것입니다.

1. input을 해석되는 문자열로 둡니다.

2. position을 초기에 문자열의 시작을 가리키는, input에 대한 포인터로 둡니다.

3. value가 값 1을 가지게 합니다.

4. divisor가 값 1을 가지게 합니다.

5. exponent가 값 1을 가지게 합니다.

6. 여백을 건너뜁니다.

7. position이 input의 끝을 지났다면, 오류를 반환합니다.

8. position에 의해 가리켜진 문자가 U+002D HYPHEN-MINUS 문자 (-) 라면:

   1. value와 divisor를 -1로 변경합니다.

   2. position을 다음 문자로 전진시킵니다.

   3. position이 input의 끝을 지났다면, 오류를 반환합니다.

   그렇지 않고, position에 의해 가리켜진 문자(첫 번째 문자)가 U+002B PLUS 부호 문자 (+) 라면:

   1. position을 다음 문자로 전진시킵니다. ("+"는 무시되지만, 이는 부적합 한 것입니다.)

   2. position이 input의 끝을 지났다면, 오류를 반환합니다.

9. position에 의해 가리켜진 문자가 U+002E 마침표 문자 (.)이고, 그 문자가 input의 마지막 문자가 아니며, position에 의해 가리켜진 문자 이후 문자가 ASCII 숫자라면, value를 0으로 설정하고 분수로 라벨링 된 단계로 건너뜁니다.

10. position에 의해 가리켜진 문자가 ASCII 숫자가 아니라면, 오류를 반환합니다.

11. ASCII 숫자인 일련의 문자를 수집하고, 10 진수 정수로 결과로 나온 시퀀스를 해석합니다. 그 정수에 value를 곱합니다.

12. position이 input의 끝을 지났다면, 변환으로 라벨링 된 단계로 건너뜁니다.

13. 분수 : position에 의해 가리켜진 문자가 U+002E 마침표 문자 (.) 라면, 이 하위 단계들을 수행합니다:

    1. position을 다음 문자로 전진시킵니다.

    2. position이 input의 끝을 지났거나, position에 의해 가리켜진 문자가 ASCII 숫자, 혹은 U+0065 라틴 소문자 E (e), 혹은 U+0045 라틴 대문자 E (E)가 아니라면, 변환으로 라벨링 된 단계로 건너뜁니다.

    3. position에 의해 가리켜진 문자가 U+0065 라틴 소문자 E (e) 또는 U+0045 라틴 대문자 E (E)라면, 이 하위 단계들의 나머지를 건너뜁니다.

    4. 분수 반복: divisor에 10을 곱합니다.

    5. position에 의해 가리켜진 문자의 값을 10진수 숫자 (0..9)로 해석하고 divisor로 나누어진 값을 value에 추가합니다.

    6. position을 다음 문자로 전진시킵니다.

    7. position이 input의 끝을 지났다면, 변환으로 라벨링 된 단계로 건너뜁니다.

    8. position에 의해 가리켜진 문자가 ASCII 숫자라면, 이 하위 단계 내의 분수 반복으로 라벨링 된 단계로 건너뜁니다.

14. position에 의해 가리켜진 문자가 U+0065 라틴 소문자 E (e) 혹은 U+0045 라틴 대문자 E (E)라면, 이 하위 단계들을 수행합니다:

    1. position을 다음 문자로 전진시킵니다.

    2. position이 input의 끝을 지났다면, 변환으로 라벨링 된 단계로 건너뜁니다.

    3. position에 의해 가리켜진 문자가 U+002D HYPHEN-MINUS 문자 (-)라면:

       1. exponent를 -1로 바꿉니다.

       2. position을 다음 문자로 전진시킵니다.

       3. position이 input의 끝을 지났다면, 변환으로 라벨링 된 단계로 건너뜁니다.

       그렇지 않고, position에 의해 가리켜진 문자가 U+002B PLUS 부호 문자(+) 라면:

       1. position을 다음 문자로 전진시킵니다.

       2. position이 input의 끝을 지났다면, 변환으로 라벨링 된 단계로 건너뜁니다.

    4. position에 의해 가리켜진 문자가 ASCII 숫자가 아니라면, 변환으로 라벨링 된 단계로 건너뜁니다.

    5. ASCII 숫자인 일련의 문자를 수집하고, and interpret the 10 진수 정수로 결과로 나온 시퀀스를 해석합니다. 그 정수에 exponent를 곱합니다.

    6. 10의 exponent제곱에 value를 곱합니다.

15. 변환: S를 0을 제외한 64 비트 배정도 부동 소수점 값이고, 두 특별한 값 2¹⁰²⁴과 -2¹⁰²⁴를 포함한 IEEE 754의 집합으로 둡니다.

16. rounded-value를, 두 개의 동일하게 가까운 값이 있다면 짝수 유효숫자를 선택하여, value에 가장 가까운 S 내의 숫자로 둡니다. (이 목적에 대해 두 개의 특별한 값 2¹⁰²⁴과 -2¹⁰²⁴는 짝수 값을 가지는 것으로 간주됩니다.)

17. rounded-value가 2¹⁰²⁴나 -2¹⁰²⁴라면, 오류를 반환합니다.

18. rounded-value를 반환합니다.

2.4.4.4. 백분율과 길이

치수 값 해석에 대한 규칙은 다음 알고리즘에 주어진 것과 같습니다. 이 알고리즘이 호출 될 때, 단계는 값을 반환하는 첫 번째 단계에서 중단하여, 주어진 순서에 따라야(must) 합니다. 이 알고리즘은 0.0 이상의 숫자나 오류를 반환할 것입니다. 수가 반환된다면, 백분율이나 길이와 같이 좀 더 세분화 됩니다.

1. input을 해석되는 문자열로 둡니다.

2. position을 초기에 문자열의 시작을 가리키는, input에 대한 포인터로 둡니다.

3. 여백을 건너뜁니다.

4. position이 input의 끝을 지났다면, 오류를 반환합니다.

5. position에 의해 가리켜진 문자가 U+002B PLUS 부호 문자 (+)라면, position을 다음 문자로 전진시킵니다.

6. position이 input의 끝을 지났다면, 오류를 반환합니다.

7. position에 의해 가리켜진 문자가 ASCII 숫자가 아니라면, 오류를 반환합니다.

8. ASCII 숫자인 일련의 문자를 수집하고, 10 진수 정수로 결과로 나온 시퀀스를 해석합니다. value를 그 수로 둡니다.

9. position이 input의 끝을 지났다면, 길이로서 value를 반환합니다.

10. position에 의해 가리켜진 문자가 U+002E 마침표 문자 (.)라면:

    1. position를 다음 문자로 전진시킵니다.

    2. position이 input의 끝을 지났거나, position에 의해 가리켜진 문자가 ASCII 숫자가 아니라면, 길이로서 value를 반환합니다.

    3. divisor가 값 1을 가지게 합니다.

    4. 분수 반복: divisor에 10을 곱합니다.

    5. position에 의해 가리켜진 문자의 값을 10진수 숫자 (0..9)로 해석하고 divisor로 나누어진 값을 value에 추가합니다.

    6. position을 다음 문자로 전진시킵니다.

    7. position이 input의 끝을 지났다면, 길이로서 value를 반환합니다.

    8. position에 의해 가리켜진 문자가 ASCII 숫자라면, 이 하위 단계 내의 분수 반복으로 라벨링 된 단계로 건너뜁니다.

11. position이 input의 끝을 지났다면, 길이로서 value를 반환합니다.

12. position에 의해 가리켜진 문자가 U+0025 PERCENT 부호 문자 (%)라면, 백분율로서 value를 반환합니다.

13. 길이로서 value를 반환합니다.

2.4.4.5. 0이 아닌 백분율과 길이

0이 아닌 치수 값 해석에 대한 규칙은 다음 알고리즘에 주어진 것과 같습니다. 이 알고리즘이 호출 될 때, 단계는 값을 반환하는 첫 번째 단계에서 중단하여, 주어진 순서에 따라야(must) 합니다. 이 알고리즘은 0.0 이상의 숫자나 오류를 반환할 것입니다. 수가 반환된다면, 백분율이나 길이와 같이 좀 더 세분화 됩니다.

1. input을 해석되는 문자열로 둡니다.

2. value를 치수 값 해석에 대한 규칙을 사용하여 input을 해석한 결과로 둡니다.

3. value가 오류라면, 오류를 반환합니다.

4. value가 0이라면, 오류를 반환합니다.

5. value가 백분율이라면, value를 백분율로서 반환합니다.

6. value를 길이로서 반환합니다.

2.4.4.6. 부동 소수점 수 목록

부동 소수점 수의 유효한 목록은 다른 문자(예를 들어 공백 문자없이), U+002C 콤마 문자로 분리된 약간의 유효한 부동 소수점 수입니다. 또한, 주어질 수 있는 부동 소수점 수의 개수 혹은 허용된 값의 범위에 제한이 있을 수 있습니다.

부동 소수점 수 목록 해석에 대한 규칙은 다음과 같습니다:

1. input을 해석되는 문자열로 둡니다

2. position을 초기에 문자열의 시작을 가리키는, input에 대한 포인터로 둡니다.

3. numbers를 초기에 빈 부동 소수점 수 목록으로 둡니다. 이 목록은 이 알고리즘의 결과가 될 것입니다.

4. 공백 문자, U+002C 콤마, U+003B 세미콜론 문자 인 일련의 문자를 수집합니다. 이것은 앞선 선행 구분자를 건너뜁니다.

5. position이 input의 끝을 지나지 않은 경우:

   1. 공백 문자, U+002C 콤마, U+003B 세미콜론, ASCII 숫자, U+002E 마침표, U+002D HYPHEN-MINUS 문자가 아닌 일련의 문자를 수집합니다. 이것은 앞선 선행 선행 가비지를 건너뜁니다.

   2. 공백 문자, U+002C 콤마, U+003B 세미콜론 문자가 아닌 일련의 문자를 수집하고, unparsed number를 결과로 둡니다.

   3. number를 부동 소수점 수 값 해석에 대한 규칙을 사용하여 unparsed number를 해석한 결과로 둡니다.

   4. number가 오류라면, number을 0으로 설정합니다.

   5. number을 numbers에 추가합니다.

   6. 공백 문자, U+002C 콤마, U+003B 세미콜론 문자 인 일련의 문자를 수집합니다. 이것은 앞선 선행 구분자를 건너뜁니다.

6. numbers를 반환합니다.

2.4.4.7. 치수 목록

치수 목록 해석에 대한 규칙은 다음과 같습니다. 이 규칙들은 숫자와 단위로 구성된 0개 이상의 목록을 반환하고, 단위는 percentage, relative, absolute입니다.

1. raw input을 해석될 문자열로 둡니다.

2. raw input 내 마지막 문자가 U+002C 콤마 문자 (,) 라면, raw input에서 그 문자를 제거합니다.

3. 콤마로 문자열 raw input를 분할합니다. raw tokens를 결과 토큰 목록으로 둡니다.

4. result을 숫자/단위 쌍의 빈 목록으로 둡니다.

5. raw tokens 내 각 토큰에 대해, 다음 하위 단계들을 수행합니다:

   1. input을 토큰으로 둡니다.

   2. position을 초기에 문자열의 시작을 가리키는, input에 대한 포인터로 둡니다.

   3. value를 숫자 0으로 둡니다.

   4. unit을 absolute로 둡니다.

   5. position이 input의 끝을 지났다면, 단위를 relative로 설정하고 마지막 하위단계로 건너뜁니다.

   6. position에 있는 문자가 ASCII 숫자라면, ASCII 숫자인 일련의 문자를 수집하고, 10진수 정수로서 결과로 나온 시퀀스를 해석하고, value를 그 정수만큼 증가시킵니다.

   7. position에 있는 문자가 U+002E 마침표 문자 (.) 라면, 이 하위 단계들을 수행합니다:

      1. 공백 문자와 ASCII 숫자로 구성된 일련의 문자를 수집합니다. s를 결과 시퀀스로 둡니다.

      2. s 내 모든 공백 문자를 제거합니다.

      3. s가 빈 문자열이 아니라면, 이 하위 단계들을 수행합니다:

         1. length를 s 내 문자(공백이 제거된 이후)의 수로 둡니다.

         2. fraction을 10 진수 정수로 s를 해석하고, 그 수를 10^length로 나눈 결과로 둡니다.

         3. value를 fraction 만큼 증가시킵니다.

   8. 여백을 건너뜁니다.

   9. position에 있는 문자가 U+0025 PERCENT 부호 문자 (%)라면, unit을 percentage로 설정합니다.

      그렇지 않고, position에 있는 문자가 U+002A ASTERISK 문자 (*)라면, unit을 relative로 설정합니다.

   10. value에 의해 주어진 수와 unit에 의해 주어진 단위로 구성된 result에 항목을 추가합니다.

6. result 목록을 반환합니다.

2.4.5. 날짜와 시간

다음 알고리즘에서, year년의 month월 내 날짜는: month가 1, 3, 5, 7, 8, 10, 12라면 31; month가 4, 6, 9, 11이라면 30; month가 2이고 year가 400으로 나누어지는 수이거나 혹은 year가 4로 나누어지지만 100으로는 나누어지지 않는 수라면 29; 그렇지 않으면 28 입니다. 이것은 그레고리력에서 윤년을 고려합니다. [GREGORIAN]

ASCII 숫자가 이 섹션에서 정의된 날짜와 시간 구문에 사용되는 경우, 그것들은 10진수 숫자로 표현됩니다.

여기에 설명된 형식은 해당하는 ISO8601의 하위 집합이 되도록 의도된 것이지만, 이 명세는 ISO8601보다 훨씬 더 자세히 해석 규칙을 정의합니다. 따라서 구현자는 아래 설명된 해석 규칙을 구현하기 위해 날짜 해석 라이브러리들을 사용하기 전에 신중하게 검토할 것이 권장됩니다; ISO8601 라이브러리는 정확히 동일한 방식으로 날짜와 시간을 해석하지 않을 수 있습니다. [ISO8601]

이 명세가 역산 그레고리력을 언급하는 경우, 그것은 거꾸로 1년까지 추론한, 현대 그레고리력을 의미합니다. 역산 그레고리력에서 날짜는, 때때로 명시적으로 역산 그레고리 날짜로 언급되는, 그 달력이 해당 시간(혹은 장소)에서 사용 중이지 않은 경우에도, 그 달력을 사용하여 설명되는 것입니다. [GREGORIAN]

2.4.5.1. 월

월은 표준시간대 정보가 없고 연, 월을 초과하는 날짜 정보가 없는 특정한 역산 그레고리 날짜로 구성됩니다. [GREGORIAN]

문자열은 주어진 순서에 따라 다음 구성요소로 구성된다면 year년과 month월을 나타내는 유효한 월 문자열입니다.:

1. year > 0 인 경우, year를 나타내는, 4개 이상의 ASCII 숫자

2. U+002D HYPHEN-MINUS 문자 (-)

3. 1 ≤ month ≤ 12 범위에서, month월을 나타내는 2개의 ASCII 숫자.

예를 들어, 2005년 2월은 2005-02로 인코드 되고, 33AD년 3월은(역산 그레고리 날짜로) 0033-03로 인코드 됩니다. 325-03 표현은 325년 3월을 의미하지 않고, 그것은 연도에 대해 4자리 숫자를 가지지 않기 때문에 오류입니다.

월 문자열을 해석하기 위한 규칙은 다음과 같습니다. 이것은 연도와 월을 반환하거나 혹은 아무 것도 반환하지 않을 것입니다. 어느 시점에 알고리즘이 "실패"라고 말한다면, 이것은 그 시점에 중단되고 아무 것도 반환하지 않음을 의미합니다.

1. input을 해석되는 문자열로 둡니다.

2. position을 초기에 문자열의 시작을 가리키는, input에 대한 포인터로 둡니다.

3. year와 month를 얻기 위해 월 컴포넌트를 해석합니다. 이것이 아무 것도 반환하지 않는다면, 실패입니다.

4. position이 input의 끝을 지나지 않으면, 실패입니다.

5. year와 month를 반환합니다.

input 문자열, position이 주어진 월 컴포넌트를 해석하기 위한 규칙은 다음과 같습니다. 이것은 연도와 월을 반환하거나 아무 것도 반환하지 않을 것입니다. 어느 시점에 알고리즘이 "실패"라고 말한다면, 이것은 그 시점에 중단되고 아무 것도 반환하지 않음을 의미합니다.

1. ASCII 숫자인 일련의 문자를 수집합니다. 수집된 시퀀스가 최소 4 글자가 아니라면 실패입니다. 그렇지 않으면, 10 진수 정수로 결과 시퀀스를 해석합니다. 그 숫자를 year로 둡니다.

2. year가 0보다 큰 수가 아니면, 실패입니다.

3. position이 input의 끝을 지났거나 position에 있는 문자가 U+002D HYPHEN-MINUS 문자가 아니라면, 실패입니다. 그렇지 않으면, position를 한 글자 앞으로 이동합니다.

4. ASCII 숫자인 일련의 문자를 수집합니다. 수집된 시퀀스가 정확히 2글자가 아니라면 실패입니다. 그렇지 않으면, 10 진수 정수로 결과 시퀀스를 해석합니다. 그 숫자를 month로 둡니다.

5. month가 1 ≤ month ≤ 12 범위의 숫자가 아니라면, 실패입니다.

6. year과 month를 반환합니다.

2.4.5.2. 날짜

날짜는 연, 월, 일로 구성되는 표준시간대가 없는 특정한 역산 그레고리 날짜로 구성됩니다. [GREGORIAN]

문자열은 나타내는 주어진 순서에 따라 다음 구성요소로 구성된다면, year년, month월, day일을 나타내는 유효한 날짜 문자열입니다:

1. year과 month를 나타내는 유효한 월 문자열

2. U+002D HYPHEN-MINUS 문자 (-)

3. 1 ≤ day ≤ maxday범위 내의 day를 나타내는 두 개의 ASCII 숫자로, maxday는 year년 month월의 날짜의 수.

예를 들어, 2016 2월 29일은 2016-02-29로 인코드 되고, 33AD년 3월 3일(역산 그레고리 날짜 같은)은 0033-03-03로 인코드 됩니다. 325-03-03 표현은 325년 3월 3일을 의미하지 않고, 이는 연도가 4자리 숫자를 가지지 않기 때문에 오류입니다.

날짜 문자열을 해석하기 위한 규칙은 다음과 같습니다. 이것은 날짜를 반환하거나, 아무 것도 반환하지 않을 것입니다. 어느 시점에 알고리즘이 "실패"라고 말한다면, 이것은 그 시점에 중단되고 아무 것도 반환하지 않음을 의미합니다.

1. input을 해석되는 문자열로 둡니다.

2. position을 초기에 문자열의 시작을 가리키는, input에 대한 포인터로 둡니다.

3. year, month, day를 얻기 위해 날짜 컴포넌트를 해석합니다. 이것이 아무 것도 반환하지 않는다면, 실패입니다.

4. position이 input의 끝을 지나지 않으면, 실패입니다.

5. date를 year년, month월, day일을 가지고 날짜로 둡니다.

6. date를 반환합니다.

input 문자열과 position가 주어진 날짜 컴포넌트를 해석하기 위한 규칙은 다음과 같습니다. 이것은 연도, 월, 일을 반환하거나 아무 것도 반환하지 않을 것입니다. 어느 시점에 알고리즘이 "실패"라고 말한다면, 이것은 그 시점에 중단되고 아무 것도 반환하지 않음을 의미합니다.

1. year와 month를 얻기 위해 월 컴포넌트를 해석합니다. 이것이 아무 것도 반환하지 않는다면, 실패입니다.

2. maxday를 year년 month월의 날짜의 수로 둡니다.

3. position이 input의 끝을 지나거나 position에 있는 문자가 U+002D HYPHEN-MINUS 문자가 아니라면, 실패입니다. 그렇지 않으면, position를 한 글자 앞으로 옮깁니다.

4. ASCII 숫자인 일련의 문자를 수집합니다. 수집된 시퀀스가 정확히 두 글자가 아니라면, 실패입니다. 그렇지 않으면, 10 진수 정수로 결과 시퀀스를 해석합니다. 그 숫자를 day로 둡니다.

5. day가 1 ≤ day ≤ maxday 내 범위의 숫자가 아니라면, 실패입니다.

6. year, month, day를 반환합니다.

2.4.5.3. 연도 없는 날짜

연도 없는 날짜는 그레고리 월과 그 월 내의 날짜로 구성되지만, 연관된 연도는 없습니다. [GREGORIAN]

문자열이 주어진 순서에 따라 다음 컴포넌트로 구성된다면, month월과 day일을 나타내는 유효한 연도 없는 날짜 문자열입니다:

1. 선택적으로, 두 U+002D HYPHEN-MINUS 문자 (-)

2. 1 ≤ month ≤ 12 범위에서 month월을 나타내는 두 ASCII 숫자

3. U+002D HYPHEN-MINUS 문자 (-)

4. maxday가 month월과 임의의 윤년(예를 들어, 4나 2000)의 날짜의 수인, 1 ≤ day ≤ maxday 범위에서 day를 나타내는 두 ASCII 숫자

바꿔 말하면, month이 2월을 의미하는 "02"라면, 날짜는 해가 윤년이었던 것처럼, 29가 될 수 있습니다.

예를 들어, 2월 29일은 02-29로 인코드 되고, 3월 3일은 03-03로 인코드 됩니다.

연도 없는 날짜 문자열을 해석하기 위한 규칙은 다음과 같습니다. 이것은 월과 날짜를 반환하거나 아무 것도 반환하지 않을 것입니다. 어느 시점에 알고리즘이 "실패"라고 말한다면, 이것은 그 시점에 중단되고 아무 것도 반환하지 않음을 의미합니다.

1. input을 해석되는 문자열로 둡니다.

2. position을 초기에 문자열의 시작을 가리키는, input에 대한 포인터로 둡니다.

3. month와 day를 얻기 위해 연도 없는 날짜 컴포넌트를 해석합니다. 이것이 아무 것도 반환하지 않는다면 실패입니다.

4. position이 input의 끝을 지나지 않으면, 실패입니다.

5. month와 day를 반환합니다.

input 문자열과 position이 주어진 연도 없는 날짜 컴포넌트를 해석하기 위한 규칙은 다음과 같습니다. 이것은 월과 날짜를 반환하거나 아무 것도 반환하지 않을 것입니다. 어느 시점에 알고리즘이 "실패"라고 말한다면, 이것은 그 시점에 중단되고 아무 것도 반환하지 않음을 의미합니다.

1. U+002D HYPHEN-MINUS 문자 (-)인 일련의 문자를 수집합니다. 수집된 시퀀스가 정확히 0개 혹은 두 개 글자가 아니라면, 실패입니다.

2. ASCII 숫자인 일련의 문자를 수집합니다. 수집된 시퀀스가 정확히 두 글자가 아니라면, 실패입니다. 그렇지 않으면, 10 진수 정수로 결과 시퀀스를 해석합니다. 그 숫자를 month로 둡니다.

3. month가 1 ≤ month ≤ 12 범위 내 숫자가 아니라면 실패입니다.

4. maxday를 임의의 윤년(예를 들어, 4 또는 2000)의 month월의 날짜의 수로 둡니다.

5. position이 input의 끝을 지나거나 position에 있는 문자가 U+002D U+002D HYPHEN-MINUS 문자가 아니라면 실패입니다. 그렇지 않으면, position를 한 글자 앞으로 이동합니다.

6. ASCII 숫자인 일련의 문자를 수집합니다. 수집된 시퀀스가 정확히 두 글자가 아니라면, 실패입니다. 그렇지 않으면 10 진수 정수로 결과 시퀀스를 해석합니다. 그 숫자를 day로 둡니다.

7. day가 1 ≤ day ≤ maxday 범위 내 숫자가 아니라면 실패입니다.

8. month와 day를 반환합니다.

2.4.5.4. 시간

time은 시, 분, 초, 소수점 초로 구성되는, 표준 시간대 정보가 없는 특정한 시간으로 구성됩니다.

문자열이 주어진 순서에 따라 다음 컴포넌트로 구성된다면, hour시 minute분 second를 나타내는 유효한 시간 문자열입니다:

1. 0 ≤ hour ≤ 23 범위의 hour을 나타내는 두 ASCII 숫자

2. U+003A 콜론 문자 (:)

3. 0 ≤ minute ≤ 59 범위의 minute을 나타내는 두 ASCII 숫자

4. second가 0가 아니거나, 선택적으로 second가 0이라면:

   1. U+003A 콜론 문자 (:)

   2. 0 ≤ s ≤ 59 범위의 second의 정수부를 나타내는 두 ASCII 숫자

   3. second가 정수가 아니거나, 선택적으로 second가 정수라면:

      1. 002E 마침표 문자 (.)

      2. 소수점 초 second를 나타내는 하나, 둘, 혹은 세 개의 ASCII 숫자

second 컴포넌트는 60이나 61이 될 수 없습니다; 윤초는 표현될 수 없습니다.

시간은, 선택적으로 초, 그리고 선택적으로 십진수 소수점 초를 가지고, 24시간제를 사용하여 인코드 됩니다. 따라서 7.45pm은 19:45로 인코드 됩니다. 그 시간 해석이 19:45:00 또는 7.45pm 0초를 반환 할 것이라는 것을 주목하세요. 19:45:45.456는 7.45pm 45초 이후 456 천분의 1초 입니다.

시간 문자열을 해석하기 위한 규칙은 다음과 같습니다. 이것은 시간을 반환하거나 아무 것도 반환하지 않을 것입니다. 어느 시점에 알고리즘이 "실패"라고 말한다면, 이것은 그 시점에 중단되고 아무 것도 반환하지 않음을 의미합니다.

1. input을 해석되는 문자열로 둡니다.

2. position을 초기에 문자열의 시작을 가리키는, input에 대한 포인터로 둡니다.

3. hour, minute, second를 얻기 위해 시간 컴포넌트를 해석합니다. 이것이 아무 것도 반환하지 않는다면 실패입니다.

4. position이 input의 끝을 지나지 않으면, 실패입니다.

5. time을 hour 시, minute 분, second 초를 가진 시간으로 둡니다

6. time을 반환합니다.

input과 position이 주어진 시간 컴포넌트를 해석를 해석하기 위한 규칙은 다음고 같습니다. 이것은 시, 분, 초를 반환하거나 아무 것도 반환하지 않을 것입니다. 어느 시점에 알고리즘이 "실패"라고 말한다면, 이것은 그 시점에 중단되고 아무 것도 반환하지 않음을 의미합니다.

1. ASCII 숫자인 일련의 문자를 수집합니다. 수집된 시퀀스가 정확히 두 글자가 아니라면 실패입니다. 그렇지 않으면, 10진 수 정수로 결과 시퀀스를 해석합니다. 그 숫자를 hour로 둡니다.

2. hour가 0 ≤ hour ≤ 23 범위의 숫자가 아니라면 실패입니다.

3. position이 input의 끝을 지나거나 position에 있는 문자가 U+003A 콜론 문자가 아니라면 실패입니다. 그렇지 않으면, position를 한 글자 앞으로 이동합니다.

4. ASCII 숫자인 일련의 문자를 수집합니다. 수집된 시퀀스가 정확히 두 글자가 아니라면 실패입니다. 그렇지 않으면, 10진수 정수로 결과 시퀀스를 해석합니다. 그 숫자를 minute으로 둡니다.

5. minute이 0 ≤ minute ≤ 59 범위의 숫자가 아니라면 실패입니다.

6. second를 "0" 값을 가진 문자열로 둡니다.

7. position이 input의 끝을 지나지 않았고 position에 있는 문자가 U+003A 콜론 이라면, 이 하위 단계들을 수행합니다:

   1. position을 input 내 다음 문자로 전진시킵니다.

   2. position이 input의 끝 혹은 input 내 마지막 문자를 지나거나, position에서 시작하는 input 내 다음 두 문자가 모두 ASCII 숫자가 아니라면, 실패입니다.

   3. ASCII 숫자 혹은 U+002E 마침표 문자인 일련의 문자를 수집합니다. 수집된 시퀀스가 3개 문자거나, 3개 문자보다 길고 3번째 문자가 U+002E 마침표 문자가 아니거나, 하나보다 많은 U+002E 마침표 문자를 가진다면, 실패입니다. 그렇지 않으면, second를 수집된 문자열로 둡니다.

8. second를 10진수(아마도 소수부를 가진) 수로 해석합니다. second를 문자열 버전 대신에 그 숫자로 둡니다.

9. second가 0 ≤ second < 60 범위의 숫자가 아니라면, 실패입니다.

10. hour, minute, second를 반환합니다.

2.4.5.5. 변동 날짜와 시간

변동 날짜와 시간은 연, 월, 일 그리고 시, 분, 초, 소수점 초로 , 구성되는 시간으로 구성되는 특정한 역산 그레고리 날짜로 구성되지만 표준시간대 없이 표현됩니다. [GREGORIAN]

문자열이 주어진 순서에 따라 다음 컴포넌트들로 구성된다면 날짜와 시간을 나타내는 유효한 변동 날짜와 시간 문자열입니다:

1. 날짜를 나타내는 유효한 날짜 문자열

2. U+0054 라틴 대문자 T (T) 혹은 U+0020 공백 문자

3. 시간을 나타내는 유효한 시간 문자열

문자열이 주어진 순서에 따라 다음 컴포넌트로 구성된다면 날짜와 시간을 나타내는 유효한 정규화된 변동 날짜와 시간 문자열입니다:

1. 날짜를 나타내는 유효한 날짜 문자열

2. U+0054 라틴 대문자 T (T)

3. 주어진 시간에 대해 가능한 가장 짧은 문자열로(예를 들어, 주어진 시간이 분 이후 0초라면 초 컴포넌트를 완전히 생략하여) 표현된 시간을 나타내는 유효한 시간 문자열

변동 날짜와 시간 문자열을 해석하기 위한 규칙은 다음과 같습니다. 이것은 날짜와 시간을 반환하거나 아무 것도 반환하지 않을 것입니다. 어느 시점에 알고리즘이 "실패"라고 말한다면, 이것은 그 시점에 중단되고 아무 것도 반환하지 않음을 의미합니다.

1. input을 해석되는 문자열로 둡니다.

2. position을 초기에 문자열의 시작을 가리키는, input에 대한 포인터로 둡니다.

3. year, month, day를 얻기 위해 날짜 컴포넌트를 해석합니다. 이것이 아무 것도 반환하지 않는다면, 실패입니다.

4. position이 input의 끝을 지났거나 position에 있는 문자가 U+0054 라틴 대문자 T (T)나 U+0020 공백 문자가 아니라면, 실패입니다. 그렇지 않으면, position를 한 글자 앞으로 이동합니다.

5. hour, minute, second를 얻기 위해 시간 컴포넌트를 해석합니다. 이것이 아무 것도 반환하지 않는다면, 실패입니다.

6. position이 input의 끝을 지나지 않으면, 실패입니다.

7. date를 year년, month월, day일을 가진 날짜로 둡니다.

8. time를 hour시, minute분, second초를 가진 시간으로 둡니다.

9. date와 time을 반환합니다.

2.4.5.6. 표준 시간대

표준 시간대 편차는 시간과 분의 부호 달린 숫자로 구성됩니다.

문자열이 다음으로 구성된다면, 표준 시간대 편차를 나타내는 유효한 표준 시간대 편차 문자열입니다:

• 시간대가 UTC인 경우에함 허용되는, U+005A 라틴 대문자 Z (Z)

• 혹은, 주어진 순서에 따라 다음 컴포넌트로 구성:

  1. 표준 시간대 편차의 부호를 나타내는, U+002B PLUS 부호 문자 (+), 혹은 표준 시간대 편차가 0이 아닌 경우 U+002D HYPHEN-MINUS 문자 (-)

  2. 0 ≤ hour ≤ 23 범위의 표준 시간대 편차의 시간 컴포넌트 hour를 나타내는 두 ASCII 숫자

  3. 선택적으로, U+003A 콜론 문자 (:)

  4. 0 ≤ minute ≤ 59 범위의 표준 시간대 편차의 분 컴포넌트 minute 나타내는 두 ASCII 숫자

이 형식은 표준 시간대 편차에 대해 -23:59에서부터 +23:59까지 허용합니다. 하지만, 실제로는, 현재 실제 표준 시간대의 편차의 범위는 -12:00에서 +14:00, 그리고 실제 표준 시간대의 편차의 분 컴포넌트는 항상 00, 또는 30, 또는 45입니다. 하지만, 이것이 영원히 지속될 것이라는 보장은 없습니다; 표준 시간대는 국가에 의해 변경되고 표준을 따르지 않습니다.

공식적인 표준 시간대의 형성에 앞선 역사적인 시간을 가진 표준 시간대 편차를 사용하는 데에 대한 자세한 내용은 아래 세계 날짜와 시간섹션의 사용법과 예제 또한 참고하세요.

표준 시간대 편차 문자열을 해석하기 위한 규칙은 다음과 같습니다. 이것은 표준 시간대 편차를 반환하거나, 아무 것도 반환하지 않을 것입니다. 어느 시점에 알고리즘이 "실패"라고 말한다면, 이것은 그 시점에 중단되고 아무 것도 반환하지 않음을 의미합니다.

1. input을 해석되는 문자열로 둡니다.

2. position을 초기에 문자열의 시작을 가리키는, input에 대한 포인터로 둡니다.

3. timezone_hours와 timezone_minutes를 얻기 위해 표준 시간대 편차 컴포넌트를 해석합니다. 이것이 아무 것도 반환하지 않는다면, 실패입니다.

4. position이 input의 끝을 지나지 않으면, 실패입니다.

5. UTC로부터 timezone_hours 시간 timezone_minutes 분인 표준 시간대 편차를 반환합니다.

input 문자열과 position이 주어진 표준 시간대 편차 컴포넌트를 해석하기 위한 규칙은 다음과 같습니다. 이것은 표진 시간대 시간과 표준 시간대 분을 반환하거나, 아무 것도 반환하지 않을 것입니다. 어느 시점에 알고리즘이 "실패"라고 말한다면, 이것은 그 시점에 중단되고 아무 것도 반환하지 않음을 의미합니다.

1. position에 있는 문자가 U+005A 라틴 대문자 Z (Z)라면:

   1. timezone_hours를 0으로 둡니다.

   2. timezone_minutes를 0으로 둡니다.

   3. position을 input 내 다음 문자로 전진시킵니다.

   그렇지 않고, position에 있는 문자가 U+002B PLUS 부호 (+)나 U+002D HYPHEN-MINUS (-)라면:

   1. position에 있는 문자가 U+002B PLUS 부호 (+)라면, sign를 "양"으로 둡니다. 그렇지 않고, 그것이 U+002D HYPHEN-MINUS (-)라면; sign을 "음"으로 둡니다.

   2. position을 input 내 다음 문자로 전진시킵니다.

   3. ASCII 숫자인 일련의 문자를 수집합니다. s를 수집된 시퀀스로 둡니다.

   4. s가 정확히 두 글자라면, 이 하위 단계들을 수행합니다:

      1. s를 10진수 정수로 해석합니다. 그 숫자를 timezone_hours로 둡니다.

      2. position이 input의 끝을 지났거나, position에 있는 문자가 U+003A 콜론 문자가 아니라면 실패입니다. 그렇지 않으면, position를 한 글자 앞으로 이동합니다.

      3. ASCII 숫자인 일련의 문자를 수집합니다. 수집된 시퀀스가 정확히 두 글자가 아니라면 실패입니다. 그렇지 않으면, 10진 정수로 결과 시퀀스를 해석합니다. 그 수를 timezone_minutes로 둡니다.

      s가 정확히 4 글자가 아니라면, 이 하위 단계들을 수행합니다:

      1. s의 첫 번째 두 글자를 10진 정수로 해석합니다. 그 수를 timezone_hours로 둡니다.

      2. s의 마지막 두 글자를 10진 정수로 해석합니다. 그 수를 timezone_minutes로 둡니다.

      그렇지 않으면 실패입니다.

   5. timezone_hours가 0 ≤ timezone_hours ≤ 23 범위의 숫자가 아니라면 실패입니다.

   6. sign가 "음"이라면, timezone_hours를 무효화합니다.

   7. timezone_minutes가 0 ≤ timezone_minutes ≤ 59 범위의 숫자가 아니라면 실패입니다.

   8. sign이 "음"이라면, timezone_minutes를 무효화합니다.

   그렇지 않으면 실패입니다.

2. timezone_hours과 timezone_minutes를 반환합니다.

2.4.5.7. 세계 날짜와 시간

세계 날짜와 시간은 시간과 분의 부호 달린 숫자로 구성되는, 표준 시간대 편차로 표현된, 연, 월, 일, 그리고 시, 분, 초, 소수점 초로 구성되는 시간으로 구성되는 특정한 역산 그레고리 날짜로 구성됩니다. [GREGORIAN]

문자열이 주어진 순서에 따라 다음 컴포넌트로 구성된다면 날짜, 시간, 표준 시간대 편차를 나타내는 유효한 세계 날짜와 시간 문자열입니다:

1. 날짜를 나타내는 유효한 날짜 문자열

2. U+0054 라틴 대문자 T (T) 혹은 U+0020 공백 문자

3. 시간을 나타내는 유효한 시간 문자열

4. 표준 시간대 편차를 나타내는 유효한 표준 시간대 편차 문자열

20 세기 중반의 UTC 형성 이전 날짜의 시간은 UTC(SI초 단위로 측정한 UT1의 근사치)가 아니라, UT1 (경도 0°에서의 현대 지구 평균 태양시)으로 표현되고 해석되어야(must)합니다. 표준 시간대의 형성 이전 시간은 적절한 현지 시간과 런던 그리니치 지역에서 관찰된 시간 사이의 차이에 가까운 명시적인 표준 시간대를 가진 UT1 시간으로 표현되고 해석되어야(must)합니다.

지역 편차는 완전한 표준 시간대 명세가 아닙니다. 실제 날짜와 시간 값으로 작업하는 경우, 아마도 INA 시간대 ID를 사용하여, 표준 시간대에 대한 별도의 필드를 사용하는 것을 고려하세요. [TIMEZONE]

문자열이 주어진 순서에 따라 다음 컴포넌트로 구성된다면, 날짜, 시간, 표준 시간대를 나타내는 유효한 정규화 된 세계 날짜와 시간 문자열입니다:

1. UTC 표준 시간대로 변환된 날짜를 나타내는 유효한 날짜 문자열

2. U+0054 라틴 대문자 T (T)

3. UTC 표준 시간대로 변환되고 주어진 시간에 대해 가능한 가장 짧은 문자열로(예를 들어, 주어진 시간이 분 이후 0초라면 초 컴포넌트를 완전히 생략하여) 표현된 시간을 나타내는 유효한 시간 문자열

4. U+005A 라틴 대문자 Z (Z)

세계 날짜와 시간 문자열을 해석하기 위한 규칙은 다음과 같습니다. 이것은 라운드 트립 혹은 표시 목적을 위해 연관된 표준 시간대 정보를 가진 UTC 시간을 반환하거나 아무 것도 반환하지 않을 것입니다. 어느 시점에 알고리즘이 "실패"라고 말한다면, 이것은 그 시점에 중단되고 아무 것도 반환하지 않음을 의미합니다.

1. input을 해석되는 문자열로 둡니다.

2. position을 초기에 문자열의 시작을 가리키는, input에 대한 포인터로 둡니다.

3. year, month, day을 얻기 위해 날짜 컴포넌트를 해석합니다. 이것이 아무 것도 반환하지 않는다면, 실패입니다.

4. position이 input의 끝을 지나거나 position에 위치한 문자가 U+0054 라틴 대문자 T 나 U+0020 공백문자가 아니라면, 실패입니다. 그렇지 않으면, position을 한 글자 앞으로 이동합니다.

5. hour, minute, second를 얻기 위해 시간 컴포넌트를 해석합니다. 이것이 아무 것도 반환하지 않는다면, 실패입니다.

6. position이 input의 끝을 지났다면 실패입니다.

7. timezone_hours와 timezone_minutes를 얻기 위해 표준 시간대 컴포넌트를 해석합니다. 이것이 아무 것도 반환하지 않는다면, 실패입니다.

8. position이 input의 끝을 지나지 않으면, 실패입니다.

9. time을 timezone_hours시간 timezone_minutes분을 뺀, year년 month월 day일 hour시 minute분 second초 시간의 시점으로 둡니다. 그 시간의 시점은 UTC 표준 시간대의 시점입니다.

10. timezone을 UTC로부터 timezone_hours 시간 timezone_minutes분 입니다.

11. time과 timezone를 반환합니다.

2.4.5.8. 주(weeks)

주는 주-해(week-year) 수와 월요일에서 시작하여 7일 주기를 나타내는 주차 수로 구성됩니다. 아래 정의된 바와 같이, 이 달력 시스템에서의 각 주차-연도는 52 혹은 53개의 7일 주기를 가집니다. 그레고리 날짜 1969년 12월 29일 월요일((1969-12-29))에서 시작하는 7일 주기는 1970 주-해(week-year)에서의 1 주차로 정의됩니다. 연속 주차는 순차적으로 숫자가 매겨집니다. 주-해(week-year)에서의 1 주차의 이전 주는 이전 주-해(week-year)에서의 마지막 주이고, 반대도 같습니다. [GREGORIAN]

year 수를 가진 주-해(week-year)는 첫 날(1월 1일)로 목요일을 가지는 역산 그레고리력의 year년에 해당하거나 첫 날(1월 1일)로 수요일을 가지고 year가 400으로 나눌 수 있는 수이거나 4로 나눌 수 있지만 100으로 나눌 수 없는 수를 가지는 역산 그레고리력의 year년에 해당한다면 53주를 가집니다. 모든 다른 주-해(week-year)들은 52 주를 가집니다.

53주를 가진 주-해(week-year)의 마지막 날의 주차 수는 53입니다; 52주를 가진 주-해(week-year)의 마지막 날의 주차 수는 52입니다.

특정 일의 주-해(week-year) 수는 역산 그레고리력으로 그 날짜를 포함하는 해의 수와 다를 수 있습니다. y 주-해(week-year)의 첫 주는 그레고리 y년의 첫 번째 목요일을 포함하는 주입니다.

현대적인 목적을 위해, 여기 정의된 week는 ISO 8601에 정의된 대로 ISO 주와 동등합니다. [ISO8601]

문자열이 주어진 순서에 따라 다음 컴포넌트로 구성된다면 주-해(week-year) year와 week 주를 나타내는 유효한 주 문자열입니다:

1. year > 0인, year를 나타내는 4개 이상의 ASCII 숫자

2. U+002D HYPHEN-MINUS 문자 (-)

3. U+0057 라틴 대문자 W (W)

4. maxweek가 주-해(week-year) year의 마지막 주의 주차 수인 1 ≤ week ≤ maxweek 내 범위의 week 주를 나타내는 두 ASCII 숫자

주 문자열을 해석하기 위한 규칙은 다음과 같습니다. 이것은 주-해(week-year) 수나 주차 수를 반환하거나, 아무 것도 반환하지 않을 것 입니다. 어느 시점에 알고리즘이 "실패"라고 말한다면, 이것은 그 시점에 중단되고 아무 것도 반환하지 않음을 의미합니다.

1. input를 해석되는 문자열로 둡니다.

2. position을 초기에 문자열의 시작을 가리키는, input에 대한 포인터로 둡니다.

3. ASCII 숫자인 일련의 문자를 수집합니다. 수집된 시퀀스가 적어도 4 글자가 아니라면 실패입니다. 그렇지 않으면, 10진수 정수로 결과 시퀀스를 해석합니다. 그 숫자를 year로 둡니다.

4. year가 0보다 큰 수가 아니라면, 실패입니다.

5. position이 input의 끝을 지나거나 position에 위치한 문자가 U+002D HYPHEN-MINUS 문자가 아니라면 실패입니다. 그렇지 않으면, position을 한 글자 앞으로 이동합니다.

6. position이 input의 끝을 지나거나 position에 위치한 문자가 U+0057 라틴 대문자 W (W)라면, 실패입니다. 그렇지 않으면 position을 한 글자 앞으로 이동합니다.

7. ASCII 숫자인 일련의 문자를 수집합니다. 수집된 시퀀스가 적어도 2 글자가 아니라면 실패입니다. 그렇지 않으면, 10진수 정수로 결과 시퀀스를 해석합니다. 그 숫자를 week로 둡니다.

8. maxweek를 year년의 마지막 날의 주차 수로 둡니다.

9. week가 1 ≤ week ≤ maxweek 범위의 숫자가 아니라면, 실패입니다.

10. position이 input의 끝을 지나지 않으면, 실패입니다.

11. 주-해(week-year) 수 year와 주차 수week를 반환합니다.

2.4.5.9. 기간

기간은 약간의 초로 구성됩니다.

월과 초는 비교할 수 없기 때문에 (1 개월은 정확한 수의 초가 아니고, 대신 측정된 정확한 날짜에 따른 정확한 길이가 정해지는 주기입니다) 이 명세에 정의된 기간은 월(혹은 12월과 동일한 년) 을 포함할 수 없습니다. 특정한 수의 초를 기술하는 기간만이 기술 될 수 있습니다.

문자열이 다음 중 하나로 구성된다면 기간 t를 나타내는 유효한 기간 문자열입니다:

• 일, 시, 분, 초의 수가 t에서와 같은 초의 동일한 수에 해당하는, 주어진 순서에 따라 다음 하위 컴포넌트가 하나 이상 따르는 리터럴 U+0050 라틴 대문자 P :

  1. 일 숫자를 나타내는, U+0044 라틴 대문자 D가 뒤따르는 하나 이상의 ASCII 숫자.

  2. 주어진 순서에 따라 다음 하위 컴포넌트들이 하나 이상 뒤따르는 U+0054 라틴 대문자 T:

     1. 시 숫자를 나타내는, U+0048 라틴 대문자 H가 뒤따르는 하나 이상의 ASCII 숫자.

     2. 분 숫자를 나타내는, U+004D 라틴 대문자 M이 뒤따르는 하나 이상의 ASCII 숫자.

     3. 다음 컴포넌트:

        1. 초 숫자를 나타내는 하나 이상의 ASCII 숫자.

        2. 선택적으로, 소수점 초를 나타내는 하나 혹은 둘, 혹은 세 개의 ASCII 숫자가 뒤따르는 U+002E 마침표 문자 (.).

        3. U+0053 라틴 대문자 S.

  이것은, 이 명세에 정의된 날짜와 시간과 연관된 약간의 마이크로문법과 같이, ISO 8601에 정의된 형식의 하나에 기반 합니다. [ISO8601]

• 순서에 상관 없이, 각각 다른 기간 시간 컴포넌트 크기를 가지는 하나 이상의 기간 시간 컴포넌트; t에서 초의 숫자와 동일하게 표현된 초의 합계.

  A 기간 시간 컴포넌트는 다음 컴포넌트로 구성되는 문자열입니다:

  1. 0개 이상의 공백 문자.

  2. 약간의 초를 나타내기 위해 명시된 (아래 참고) 기간 시간 컴포넌트 크기에 의해 크기가 조정된 약간의 시간 단위를 나타내는 하나 이상의 ASCII 숫자.

  3. 기간 시간 컴포넌트 크기가 1로 명시되었다면(즉, 단위가 초), 선택적으로 소수점 초를 나타내는 하나 혹은 둘, 혹은 세 개의 ASCII 숫자가 뒤따르는 U+002E 마침표 문자 (.).

  4. 0개 이상의 공백 문자.

  5. 기간 시간 컴포넌트의 숫자 부분에 사용된 시간 단위의 기간 시간 컴포넌트 크기를 나타내는 다음 문자 중 하나:

     U+0057 라틴 대문자 W

     U+0077 라틴 소문자 W

     주. 크기는 604800 입니다.

     U+0044 라틴 대문자 D

     U+0064 라틴 소문자 D

     일. 크기는 86400 입니다.

     U+0048 라틴 대문자 H

     U+0068 라틴 소문자 H

     시. 크기는 3600 입니다.

     U+004D 라틴 대문자 M

     U+006D 라틴 소문자 M

     분. 크기는 60 입니다.

     U+0053 라틴 대문자 S

     U+0073 라틴 소문자 S

     초. 크기는 1 입니다.

  6. 0개 이상의 공백 문자.

  이것은 ISO 8601에 있는 형식에 기반되지 않습니다. 이것은 ISO 기간 형식에 대해 사람이 읽을 수 있는 대안으로 의도되었습니다.

기간 문자열을 해석하기 위한 규칙은 다음과 같습니다. 이것은 기간을 반환하거나 아무 것도 반환하지 않을 것입니다. 어느 시점에 알고리즘이 "실패"라고 말한다면, 이것은 그 시점에 중단되고 아무 것도 반환하지 않음을 의미합니다.

1. input을 해석되는 문자열로 둡니다.

2. position을 초기에 문자열의 시작을 가리키는, input에 대한 포인터로 둡니다.

3. months, seconds, component count을 모두 0으로 둡니다.

4. M-disambiguator을 minutes로 둡니다.

   이 플래그의 다른 값은 months입니다. 이것은 ISO8601 기간에서 월과 분에 대해 동일한 단위로 사용되는 "M" 단위를 명확하게 하기 위해 사용됩니다. 월은 허용되지 않지만, 향후 호환성을 위해 해석되고 다른 컨텍스트에서 유효할 수 있는 ISO8601 기간을 잘못 해석하는 것을 방지합니다.

5. 여백을 건너뜁니다.

6. position이 input의 끝을 지났다면, 실패입니다.

7. position에 의해 가리켜진 input 내의 문자가 U+0050 라틴 대문자 P라면, position을 다음 문자로 전진시키고, M-disambiguator를 months로 설정하고, 여백을 건너뜁니다.

8. 요구되는 반복이 끊어지거나 전체 알고리즘이 실패에 이를 때까지, 반복에서 다음 하위 단계들을 수행합니다:

   1. units를 undefined로 둡니다. 그것은 다음 값들 중 하나가 할당 될 것입니다: years, months, weeks, days, hours, minutes, seconds.

   2. next character를 undefined로 둡니다. 그것은 input로부터 문자를 가공하는데 사용됩니다.

   3. position이 input의 끝을 지났다면, 반복을 중단합니다.

   4. position에 의해 가리켜진 input 내의 문자가 U+0054 라틴 대문자 T라면, position을 다음 문자로 전진시키고, M-disambiguator를 minutes으로 설정하고, 여백을 건너뛰고, 반복의 처음으로 돌아갑니다.

   5. next character를 position에 의해 가리켜진 input 내의 문자로 둡니다.

   6. next character가 U+002E 마침표 문자 (.)라면, N를 0으로 둡니다. (position를 전진시키지 않습니다. 그것은 아래에서 다루어집니다.)

      그렇지 않고, next character가 ASCII 숫자라면, ASCII 숫자인 일련의 문자를 수집하고 10진수 정수로 결과 시퀀스를 해석하고, N을 그 숫자로 둡니다.

      그렇지 않으면 next character가 숫자 부분이 아닙니다; 실패입니다.

   7. position이 input의 끝을 지났다면, 실패입니다.

   8. next character를 position에 의해 가리켜진 input 내의 문자로 설정하고, 이번에는 position을 다음 문자로 전진시킵니다. (next character가 이전에 U+002E 마침표 문자가 아니었다면, 이번에는 여전히 그 문자가 될 것입니다.)

   9. next character가 U+002E 마침표 문자 (.)라면, 이 하위 단계들을 수행합니다:

      1. ASCII 숫자인 일련의 문자를 수집합니다. s를 결과 시퀀스로 둡니다.

      2. s가 빈 문자열이라면 실패입니다.

      3. length를 s내 문자의 개수로 둡니다.

      4. fraction을 10진수 정수로 s를 해석한 후, 그 숫자를 10^length로 나눈 결과로 둡니다.

      5. N을 fraction만큼 증가시킵니다.

      6. 여백을 건너뜁니다.

      7. position이 input의 끝을 지났다면, 실패입니다.

      8. next character를 position에 의해 가리켜진 input 내의 문자로 설정하고, position을 다음 문자로 전진시킵니다.

      9. next character가 U+0053 라틴 대문자 S나 U+0073 라틴 소문자 S 모두 아니라면, 실패입니다.

      10. units를 seconds로 설정합니다.

      그렇지 않으면, 이 하위 단계들을 수행합니다:

      1. next character가 공백 문자라면, 여백을 건너뛰고, next character를 position에 의해 가리켜진 input 내의 문자로 설정하고, position을 다음 문자로 전진시킵니다.

      2. next character가 U+0059 라틴 대문자 Y나 U+0079 라틴 소문자 Y라면, units을 years로 설정하고 M-disambiguator를 months로 설정합니다.

         next character가 U+004D 라틴 대문자 M이거나 U+006D 라틴 소문자 M이라면, M-disambiguator는 months이고, units를 months로 설정합니다.

         next character가 U+0057 라틴 대문자 W이거나 U+0077 라틴 소문자 W라면, units를 weeks로 설정하고 M-disambiguator를 minutes로 설정합니다.

         next character가 U+0044 라틴 대문자 D이거나 U+0064 라틴 소문자 D라면, units를 days로 설정하고 M-disambiguator를 minutes로 설정합니다.

         next character가 U+0048 라틴 대문자 H이거나 U+0068 라틴 소문자 H라면, units를 hours로 설정하고 M-disambiguator를 minutes로 설정합니다.

         next character가 U+004D 라틴 대문자 M이거나 U+006D 라틴 소문자 M이라면, M-disambiguator를 minutes로 설정하고 units를 minutes로 설정합니다.

         next character가 U+0053 라틴 대문자 S이거나 U+0073 라틴 소문자 S라면, units를 seconds로 설정하고 M-disambiguator를 minutes로 설정합니다.

         그렇지 않고 next character가 위 문자 중 어떠한 것도 아니라면, 실패입니다.

   10. component count를 증가시킵니다.

   11. multiplier를 1로 둡니다.

   12. units가 years라면, multiplier에 12를 곱하고 units를 months로 설정합니다.

   13. units가 months라면, N과 multiplier의 곱을 months에 더합니다.

       그렇지 않으면, 이 하위 단계들을 수행합니다:

       1. units가 weeks라면, multiplier에 7을 곱하고 units를 days로 설정합니다.

       2. units가 days라면, multiplier에 24를 곱하고 units를 hours로 설정합니다.

       3. units가 hours라면, multiplier에 60을 곱하고 units를 minutes로 설정합니다.

       4. units가 minutes라면, multiplier에 60을 곱하고 units를 seconds로 설정합니다.

       5. 강제적으로, units는 이제 seconds입니다. N과 multiplier의 곱을 seconds에 더합니다.

   14. 여백을 건너뜁니다.

9. component count가 0이라면, 실패입니다.

10. months가 0이라면, 실패입니다.

11. seconds 초로 구성된 기간을 반환합니다.

2.4.5.10. 시간의 모호한 때

문자열이 다음 중 하나라면 선택적인 시간을 가진 유효한 날짜 문자열입니다:

• 유효한 날짜 문자열

• 유효한 세계 날짜와 시간 문자열

날짜나 시간 문자열을 해석하기 위한 규칙은 다음과 같습니다. 이 알고리즘은 날짜, 시간, 세계 날짜와 시간을 반환하거나, 아무 것도 반환하지 않을 것입니다. 어느 시점에 알고리즘이 "실패"라고 말한다면, 이것은 그 시점에 중단되고 아무 것도 반환하지 않음을 의미합니다.

1. input를 해석되는 문자열로 둡니다.

2. position을 초기에 문자열의 시작을 가리키는, input에 대한 포인터로 둡니다.

3. start position를 position과 동일한 위치로 둡니다.

4. date present와 time present 플래그를 true로 둡니다.

5. year, month, day를 얻기 위해 날짜 컴포넌트를 해석합니다. 이것이 실패한다면, date present 플래그를 false로 설정합니다.

6. date present이 true이고, position이 input의 끝을 지나지 않았고, position에 있는 문자가 U+0054 라틴 대문자 T나 U+0020 공백 문자라면, position을 input내 다음 문자로 전진시킵니다.

   그렇지 않고, date present가 true이고, position이 input의 끝을 지났거나 position에 있는 문자가 U+0054 라틴 대문자 T나 U+0020 공백 문자가 모두 아니라면, time present를 false로 둡니다.

   그렇지 않고, date present가 false라면, position를 start position과 동일한 위치로 돌립니다.

7. time present 플래그가 true라면, hour, minute, second를 얻기 위해 시간 컴포넌트를 해석합니다. 이것이 아무 것도 반환하지 않는다면, 실패입니다.

8. date present과 time present 플래그가 모두 true이지만, position이 input의 끝을 지났다면, 실패입니다.

9. date present와 time present플래그가 모두 true라면, timezone_hours과 timezone_minutes를 얻기 위해 표준 시간대 편차 컴포넌트를 해석합니다. 이것이 아무 것도 반환하지 않는다면, 실패입니다.

10. position이 input의 끝을 지나지 않으면, 실패입니다.

11. date present 플래그가 true이고 time present 플래그가 false라면, date를 year년, month월, day일을 가진 날짜로 두고, date를 반환합니다.

    그렇지 않고, time present 플래그가 true이고 date present 플래그가 false라면, time을 hour시, minute분, second초를 가진 시간으로 두고 time을 반환합니다.

    그렇지 않으면, time을 UTC 표준 시간대 순간이 되는 시간의 순간인 timezone_hours시간 timezone_minutes분을 뺀 year년, month월, day일, hour시, minute분, second초의 순간으로 둡니다; timezone을 UTC로부터 timezone_hours 시 timezone_minutes 분으로 두고; time과 timezone를 반환합니다.

2.4.6. 색상

간단한 색상은 sRGB 색상 공간에서, 각각 색상의 빨강, 초록, 파랑 컴포넌트를 나타내는 0..255 범위의 3개의 8비트 숫자로 구성됩니다. [SRGB]

문자열이 정확히 7 글자이고, 첫번째 문자가 U+0023 숫자 부호 문자 (#)이고, 나머지 여섯 글자가 모두 16진수로 첫 두 글자가 빨강 컴포넌트를 나타내고, 중간 두 글자가 초록 컴포넌트를 나타내고, 마지막 두 글자가 파랑 컴포넌트를 나타내는 ASCII 16진수라면 유효한 간단한 색상입니다.

문자열이 유효한 간단한 색상이고, U+0041 라틴 대문자 A부터 U+0046 라틴 대문자 F 범위의 문자를 사용하지 않는다면 유효한 소문자 간단한 색상입니다.

간단한 색상 값을 해석하기 위한 규칙은 다음 알고리즘에 주어진 것과 같습니다. 이 알고리즘이 호출 될 때, 값을 반환하는 첫 번째 단계에서 중단하여, 주어진 순서에 따라 단계를 따라야(must) 합니다. 이 알고리즘은 간단한 색상이나 오류를 반환할 것입니다.

1. input을 해석되는 문자열로 둡니다.

2. input이 정확히 7 글자가 아니라면, 오류를 반환합니다.

3. input 내 첫 번째 문자가 U+0023 숫자 부호 문자 (#)가 아니라면, 오류를 반환합니다.

4. input의 마지막 여섯 문자가 모두 ASCII 16진수라면, 오류를 반환합니다.

5. result를 간단한 색상입니다.

6. 두 번째와 세 번째 문자를 16진수로 해석하고 그 결과를 result의 빨강 컴포넌트로 둡니다.

7. 네 번째와 다섯 번째 문자를 16진수로 해석하고 그 결과를 result의 초록 컴포넌트로 둡니다.

8. 여섯 번째와 일곱 번째 문자를 16진수로 해석하고 그 결과를 result의 파랑 컴포넌트로 둡니다.

9. result를 반환합니다.

간단한 색상이 주어지는 간단한 색상 값 직렬화를 위한 규칙은 다음 알고리즘에 주어진 것과 같습니다:

1. result를 단일 U+0023 숫자 부호 문자 (#)로 구성되는 문자열로 둡니다.

2. 필요하다면 0으로 채워, 소문자 ASCII 16진수를 사용하여, 빨강, 초록, 파랑 컴포넌트를 2자리 16진수 숫자로 변경하고 이 숫자들을 빨강, 초록, 파랑 순서로 result에 추가합니다.

3. 유효한 소문자 간단한 색상이 되는 result를 반환합니다.

일부 오래된 레거시 속성은 다음 알고리즘에 주어지는 레거시 색상 값 해석을 위한 규칙을 사용하여 좀 더 복잡한 방법으로 색상을 해석합니다. 이 알고리즘이 호출 될 때, 값을 반환하는 첫 번째 단계에서 중단하여, 주어진 순서에 따라야(must) 합니다. 이 알고리즘은 간단한 색상이나 오류를 반환할 것입니다.

1. input을 해석되는 문자열로 둡니다.

2. input이 빈 문자열이라면, 오류를 반환합니다.

3. input으로부터 앞뒤 여백 문자를 비워냅니다.

4. input이 문자열 "transparent"에 ASCII 대소문자 구분 없이 일치한다면 오류를 반환합니다.

5. input이 명명된 색상 중 하나에 ASCII 대소문자 구분 없이 일치한다면 그 키워드에 해당하는 간단한 색상을 반환합니다. [CSS3COLOR]

   CSS2 시스템 색상은 인정되지 않습니다.

6. input이 4 글자이고, input의 첫 번째 문자가 U+0023 숫자 부호 문자 (#)이고, input의 마지막 세 글자가 모두 ASCII 16진수라면, 이 하위 단계들을 수행합니다:

   1. result를 간단한 색상으로 둡니다.

   2. input의 두 번째 문자를 16진수 숫자로 해석합니다; result의 빨강 컴포넌트를 17이 곱해진 결과로 둡니다.

   3. input의 세 번째 문자를 16진수 숫자로 해석합니다; result의 초록 컴포넌트를 17이 곱해진 결과로 둡니다.

   4. input의 네 번째 문자를 16진수 숫자로 해석합니다; result의 파랑 컴포넌트를 17이 곱해진 결과로 둡니다.

   5. result를 반환합니다.

7. U+FFFF보다 큰 유니코드 포인트를 가지는 input의 모든 문자(즉, 기본 다국어에 없는 모든 문자)를 두 글자 문자열 "00"로 바꿉니다.

8. input이 128개 문자보다 길다면, 처음 128개 문자만을 남겨두고, input을 잘라냅니다.

9. input의 첫 번째 문자가 U+0023 숫자 부호 문자 (#)라면, 그것을 제거합니다.

10. ASCII 16진수가 아닌 input의 모든 문자들을 U+0030 숫자 0 (0) 문자로 교체합니다.

11. input의 길이가 0이나 3배수가 아닌 경우, input에 U+0030 숫자 0 (0)문자를 추가합니다.

12. 3개의 컴포넌트를 얻기 위해 input을 동일한 길이의 세 문자열로 분할합니다. length를 그 컴포넌트들의 길이(input의 길이의 3분의 1)로 둡니다.

13. length가 8보가 크다면, 각 컴포넌트의 앞선 length-8 문자를 제거하고 length를 8로 둡니다.

14. length가 2보다 크고 각 컴포넌트의 첫 번째 문자가 U+0030 숫자 0 (0)문자인 경우, 그 문자를 제거하고, length를 하나 줄입니다.

15. length가 여전히 2보다 크다면, 각 컴포넌트를 첫 번째 2개 문자만을 남겨 잘라냅니다.

16. result를 간단한 색상으로 둡니다.

17. 첫 번째 컴포넌트를 16진수 숫자로 해석합니다; result의 빨강 컴포넌트를 결과 숫자로 둡니다.

18. 두 번째 컴포넌트를 16진수 숫자로 해석합니다; result의 초록 컴포넌트를 결과 숫자로 둡니다.

19. 세 번째 컴포넌트를 16진수 숫자로 해석합니다; result의 파랑 컴포넌트를 결과 숫자로 둡니다.

20. result를 반환합니다.

2.4.7. 공백으로 분리된 토큰

공백으로 분리된 토큰 집합은 1개 이상의 공백 문자으로 분리된 0개 이상의 단어(토큰으로 알려짐)로 구성되는 문자열이고, 단어는 어떤 것도 공백 문자가 아닌, 1개 이상의 문자의 문자열로 구성됩니다.

공백으로 분리된 토큰 집합을 포함하는 문자열은 앞 뒤 공백 문자를 가질 수도 있습니다.

공백으로 분리된 고유한 토큰의 비순차적 집합은 어떤 토큰도 중복되지 않는 공백으로 분리된 토큰 집합입니다.

공백으로 분리된 고유한 토큰의 순차적 집합은 어떤 토큰도 중복되지 않고 토큰의 순서가 의미가 있는 공백으로 분리된 토큰 집합입니다.

공백으로 분리된 토큰 집합은 때때로 정의된 허용된 값의 집합을 가집니다. 허용된 값의 집합이 정의되는 경우, 토큰은 모두 허용된 값의 목록에 있어야(must)합니다; 다른 값들은 부적합합니다. 그러한 허용된 값의 집합이 제공되지 않으면, 모든 값들이 적합합니다.

공백으로 분리된 토큰 집합의 토큰이 비교되는 방법(예를 들어, 대소문자를 구별하는지 아닌지)은 각 집합 기준으로 정의되어 있습니다.

유저 에이전트가 공백으로 문자열을 분리해야하는(has to)경우, 다음 알고리즘을 사용해야(must)합니다:

1. input을 해석되는 문자열로 둡니다.

2. position을 초기에 문자열의 시작을 가리키는, input에 대한 포인터로 둡니다.

3. tokens을 초기에 비어있는, 토큰의 순차적인 목록으로 둡니다.

4. 여백을 건너뜁니다.

5. position이 input의 끝을 지나지 않은 경우:

   1. 공백 문자가 아닌 일련의 문자를 수집합니다.

   2. 이전 단계에서 수집된 문자열을 tokens에 추가합니다.

   3. 여백을 건너뜁니다.

6. tokens을 반환합니다.

2.4.8. 콤마로 분리된 토큰

콤마로 분리된 토큰의 집합은 각 단일 U+002C 콤마 문자 (,)로 다음 토큰과 분리된 0개 이상의 토큰을 포함하는 문자열이고, 토큰은 공백 문자로 시작하거나 끝나지 않고, U+002C 콤마 문자(,)를 포함하지 않으며, 선택적으로 공백 문자로 둘러 싸이는, 0개 이상의 문자의 문자열로 구성됩니다.

예를 들어, 문자열 " a ,b,d d "는 4개의 토큰으로 구성됩니다: "a", "b", 빈 문자열, "d d". 각 토큰 주변의 앞 뒤 여백은 토큰의 부분으로 간주되지 않고, 빈 문자열은 토큰이 될 수 있습니다.

콤마로 분리된 토큰의 집합은 때때로 유효한 토큰으로 구성되는 것에 추가적인 제한 사항을 가집니다. 그러한 제한 사항이 정의되는 경우, 토큰은 모두 그 제한 사항에 적합해야 합니다; 다른 값들은 부적합합니다. 그러한 제한 사항이 명시되지 않는다면, 모든 값들은 적합합니다.

유저 에이전트가 콤마로 문자열을 분리해야(has to) 하는 경우, 다음 알고리즘을 수행해야(must) 합니다:

1. input을 해석되는 문자열로 둡니다.

2. position을 초기에 문자열의 시작을 가리키는, input에 대한 포인터로 둡니다.

3. tokens을 초기에 비어 있는, 토큰의 순차적인 목록으로 둡니다.

4. Token: position이 input의 끝을 지났다면, 마지막 단계로 건너뜁니다.

5. U+002C COMMA 문자 (,)가 아닌 일련의 문자를 수집합니다. s를 결과 시퀀스(빈 문자열일 수 있습니다)로 둡니다.

6. s에서 앞뒤 여백 문자를 비워냅니다.

7. s를 tokens에 추가합니다.

8. position이 input의 끝을 지나지 않았따면, position에 있는 문자는 U+002C 콤마 문자 (,)입니다; position를 그 문자를 지나 전진시킵니다.

9. token로 라벨링 된 단계로 돌아갑니다.

10. tokens을 반환합니다.

2.4.9. 참조

type 유형의 요소(element)로의 유효한 해시 이름 참조는 문서에서 type 유형을 가진 요소(element)의 name 속성(attribute)의 값과 정확히 일치하는 문자열이 뒤따르는 U+0023 숫자 부호 문자 (#)로 구성되는 문자열입니다.

컨텍스트 노드 scope로 주어지는, type 유형의 요소(element)로의 해시 이름 참조 해석을 위한 규칙은 다음과 같습니다:

1. 해석되는 문자열이 U+0023 숫자 부호 문자를 포함하지 않거나, 문자열의 첫 번째 그 문자가 문자열의 마지막 문자라면, null을 반환하고 이 단계들을 중단합니다.

2. s를 해석되는 문자열의 첫 번째 U+0023 숫자 부호 문자 바로 뒤의 문자에서부터 그 문자열의 끝까지 문자열로 둡니다.

3. 값이 s와 대소문자를 구별하여 일치하는 id 속성(attirbute)이나 값이 s와 호환되는 대소문자 구분이 없이 일치하는 name 속성(attirbute)을 가진 scope에 뿌리를 둔 하위 트리의 트리 순서에 따라 type유형의 첫 번째 요소(element)를 반환합니다.

2.4.10. 미디어 쿼리

문자열이 미디어 쿼리 명세의 <media-query-list> 결과물과 일치한다면 유효한 미디어 쿼리 목록입니다. [MEDIAQ]

문자열이 빈 문자열, 혹은 공백 문자로만 구성되는 문자열, 혹은 미디어 쿼리 명세에 주어진 정의에 따라 사용자의 환경에 일치하는 미디어 쿼리 목록이라면, 문자열은 사용자의 환경과 일치합니다. [MEDIAQ]

2.5. URLs

2.5.1. 용어

URL이 WHATWG URL 표준의 저작 적합성 요구사항에 준하다면 유효한 URL입니다. [URL]

문자열이 유효한 URL이고 빈 문자열이 아니라면 유효한 비어있지 않은 URL입니다.

문자열은, 문자열로부터 앞뒤 여백 문자를 비워낸 이후, 유효한 문자열이라면, 잠정적으로 공백으로 둘러싸일 수 있는 유효한 URL 입니다.

문자열은, 문자열로부터 앞뒤 여백 문자를 비워낸 이후, 유효한 비어있지 않은 URL이라면, 유효한 잠정적으로 공백으로 둘러 싸일 수 있는 비어있지 않은 URL입니다.

이 명세는 XML 도구와 호환성이 필요할 경우 HTML 문서의 DOCTYPE에서 사용을 위해 예약된, 비록 해결할 수 없지만, about: URL과 같이 URL about:legacy-compat를 정의합니다. [RFC6694]

이 명세는 확인 할 수 없음에도 불구하고, 예약된 URL about:과 같이 iframe srcdoc 문서의 문서의 주소로 사용되는 about:srcdoc를 정의합니다. [RFC6694]

객체의 폴백 기본 URL은 이 하위 단계들을 수행하여 얻어지는 절대 URL입니다:

1. document가 iframe srcdoc 문서라면, Document의 브라우징 컨텍스트의 브라우징 컨텍스트 컨테이너의 노드 문서의 문서 기본 URL을 반환합니다.

2. document의 URL이 about:blank이고, document의 브라우징 컨텍스트가 생성자 브라우징 컨텍스트를 가진다면, 생성자 기본 URL을 반환합니다.

3. document의 URL을 반환합니다.

Document 객체의 문서 기본 URL은 이 하위 단계들을 수행하여 얻어지는 절대 URL입니다:

1. Document에 href 속성(attribute)를 가진 base 요소(element)가 없다면, 문서 절대 URL은 Document의 폴백 기본 URL입니다; 이 단계들을 중단합니다.

2. 그렇지 않으면, 문서 기본 URL은 트리 순서에 따라 Document 내의 href 속성(attribute)을 가진 첫 번째 base 요소(element)의 고정(frozen) 기본 URL입니다.

2.5.2. URL 해석

URL 해석은 URL 문자열을 가져오고 그것이 의미하는 URL 레코드를 획득하는 과정입니다. 이 과정이 WAHTWG URL 표준에 정의되어 있지만, 이 명세는 편의상 래퍼를 정의합니다. [URL]

이 래퍼는 레거시 이유로 URL 해석기에 대한 문자 인코딩이 문서나 환경 설정 객체의 문자 인코딩과 일치해야(has to) 하는 경우에만 유용합니다. 문자 인코딩이 그 경우가 아닌 경우 URL 해석기가 직접적으로 사용될 수 있습니다.

document나 environment settings object과 관련된, url URL을 해석하기 위해, 유저 에이전트는 다음 단계들을 사용해야(must) 합니다. URL 해석은 실패되거나 결과 URL 문자열과 결과 URL 레코드가 됩니다.

1. document가 주어졌고, environment settings object의 API URL 문자 인코딩은 주어지지 않았다면, encoding을 document의 문자 인코딩으로 둡니다.

2. document가 주어졌고, environment settings object의 baseURL을 API 기본 URL은 주어지지 않았다면, document의 기본 URL로 둡니다.

3. urlRecord을 baseURL과 encoding과 함께, URL 해석기를 url에 적용한 결과로 둡니다.

4. urlRecord가 실패라면, 오류와 함께 이 단계를 중단합니다.

5. urlString을 URL 시리얼라이저를 urlRecord에 적용한 결과로 둡니다.

6. 결과 URL 문자열로 urlString을 반환하고 결과 URL 레코드로 urlRecord를 반환합니다.

2.5.3. 기본 URL로 동적 변경

문서의 문서 기본 URL이 변경되는 경우, 그 문서 내의 모든 요소(element)들은 습니다.

다음은 요소(element)가 기본 URL 변경에 의해 영향을 받는 경우 (DOM 명세에 정의된 대로), 수행되는 기본 URL 변경 단계입니다:

요소(element)가 하이퍼링크를 생성한다면

하이퍼링크에 의해 확인된 URL이 사용자에게 보여지거나, 그 URL로부터 파생된 임의의 데이터가 표현(display)에 영향을 미치고 있다면, href 속성(attribute)은 요소(element)의 노드 문서와 알맞게 갱신된 UI와 관련하여 재해석 되어야(should) 합니다.

예를 들어, CSS :link/:visited 가상 클래스는 영향을 받았을 수 있습니다.

요소(element)가 cite 속성(attribute)을 가진 q, blockquote, ins, del요소라면

cite 속성(attribute)에 의해 확인 된 URL이 사용자에게 보여지고 있거나, 그 URL로부터 파생된 임의의 데이터가 표시에 영향을 미치고 있다면, URL은 요소(element)의 노드 문서와 알맞게 갱신된 UI와 관련하여 재해석 되어야(should) 합니다.

그렇지 않으면

요소(element)는 직접적으로 영향을 받지 않습니다.

예를 들어, 기본 URL을 변경하는 것은, 스크립트에서 src IDL 속성(attribute)의 다음 접근이 보여지고 있는 이미지와 더 이상 일치하지 않을 새로운 절대 URL을 반환할 것이기는 하지만, img 요소(element)에 의해 표시된 이미지에 영향을 주지 않습니다.

2.6. 리소스 가져오기

2.6.1. 용어

유저 에이전트는 다양한 전송 프로토콜을 구현할 수 있지만, 이 명세는 주로 HTTP 관점에서 동작을 정의합니다. [HTTP]

HTTP GET 메서드는 프로토콜의 기본 검색 동작과 동일합니다. 예를 들어, FTP에서의 RETR. 그러한 동작은 HTTP 관점에서, 멱등하고 안전합니다.

HTTP 응답 코드는 동일한 기본 의미(meanings)를 갖는 다른 프로토콜에서의 상태와 동일합니다. 예를 들어, "file not found" 오류는 404 코드와 동일하고, 서버 오류는 5xx 코드와 동일합니다.

HTTP 헤더는 동일한 기본 의미(meanings)를 갖는 다른 프로토콜에서의 필드와 동일합니다. 예를 들어, HTTP 인증 헤더는 FTP 프로토콜의 인증 측면과 동일합니다.

리퍼러 소스는 Document나 URL입니다.

url, corsAttributeState, 선택적으로 동일 출처(origin) 폴백 플래그가 주어진 잠정적 CORS 요청을 생성하기 위해 이 단계들을 수행합니다:

1. corsAttributeState가 No CORS이라면 mode를 "no-cors"로 두고, 그렇지 않으면 "cors"로 둡니다.

2. 동일 출처(origin) 폴백 플래그가 설정되고 mode가 "no-cors"라면, mode를 "same-origin"로 설정합니다.

3. credentialsMode를 "include"로 둡니다.

4. corsAttributeState가 익명(Anonymous)이라면, credentialsMode를 "same-origin"로 설정합니다.

5. request를 URL이 url이고, 목적지가 "subresource"이고, 모드가 mode이며 자격 증명 모드가 credentialsMode이고, URL 자격 증명 사용 플래그가 설정된 새로운 요청으로 둡니다.

2.6.2. 처리 모델

유저 에이전트가, 선택적으로 출처 origin으로부터, 선택적으로 오버라이드 리퍼러 소스로서 특정한 리퍼러 소스를 사용하여, 선택적으로 동기(synchronous) 플래그, 수동 리다이렉트 플래그, 강제 동일 출처(origin) 플래그, 쿠키 차단 플래그 중 어느 것을 가진 리소스나 URL을 가져오는 경우, 다음 단계들이 수행 되어야(must) 합니다. (URL을 가져올 때, URL은 얻어지는 리소스를 식별합니다.)

1. 특정 오버라이드 리퍼러 리소스가 있고, 그것이 URL이라면, referrer를 오버라이드 리퍼러 리소스로 두고, clean referrer로 라벨링 된 단계로 건너 뜁니다.

2. document를 다음 목록에 의해 주어진 대로 적절한 Document로 둡니다:

   특정한 오버라이드 리퍼러 리소스가 있다면

   오버라이드 리퍼러 리소스.

   이동 중(navigating)인 경우

   소스 브라우징 컨텍스트의 활성 문서.

   요소(element)에 대한 리소스를 가져오는 중인 경우

   요소(element)의 Document.

3. document가 iframe srcdoc 문서임에도 불구하고, document를 대신 document의 브라우징 컨텍스트의 브라우징 컨텍스트 컨테이너의 Document로 둡니다.

4. Document의 출처(origin)가 scheme/host/port 튜플이 아니라면, referrer를 빈 문자열로 설정하고 Clean referrer로 라벨링 된 단계로 건너뜁니다.

5. referrer를 document의 문서 주소로 둡니다.

6. Clean referrer: URL 해석기를 referrer에 적용하고 parsed referrer를 결과 URL 레코드로 둡니다.

7. referrer를 제외 프래그먼트 플래그 세트를 가지고 URL 시리얼라이저를 parsed referrer에 적용한 결과로 둡니다.

8. referrer가 빈 문자열, data: URL, URL "about:blank"가 아니라면, referrer로부터 Referer (sic) 헤더에 대한 HTTP에 의해 요구된 대로 요청 UIR가 얻어지는 리소스의 주소를 생성합니다. [HTTP]

   그렇지 않으면, Referer (sic) 헤더는 그것의 값에 관계 없이 생략 되어야(must)합니다.

9. 알고리즘이 동기(synchronous) 플래그를 가지고 작동되지 않았다면, 병렬로 나머지 단계들을 수행합니다.

10. 이 알고리즘에 의해 대기 된 연관될 수 있는 작업들을 가진 Document가 연관된 브라우징 컨텍스트를 가지지 않는다면, 이 단계들을 중단합니다.

11. 이것은 main step입니다.

    리소스가 어플리케이션 캐시로부터 얻어지는 것이라면, 마치 URL을 주어진 적절한 방법으로 얻어진 것처럼, 그 어플리케이션 캐시의 데이터를 사용합니다.

    리소스가 절대 URL에 의해 식별되고, 리소스가 멱등 동작 (HTTP GET이나 그와 동등한 것과 같은)을 사용하여 얻어진 것이고, 이미 다른 이유로 다운로드 되고 있고(예를 들어, 이 알고리즘의 다른 발동), 이 요청이 이전의 요청과 동일하고 (예를 들어, 동일한 Accept와 Origin헤더), 유저 에이전트가 새로운 다운로드를 개시하는 대신 기존 다운로드로부터 데이터를 다시 사용하도록 구성되어 있다면, 새로운 다운로드를 시작하는 대신 기존 다운로드의 결과를 사용합니다.

    그렇지 않고, 리소스가 리소스를 획득하기 위한 메커니즘을 정의하지 않는 스킴 (예를 들어, mailto: URL)이나 유저 에이전트가 지원하지 않는 스킴을 가진 절대 URL에 의해 식별된다면, 리소스가 다른 메타데이터가 없는 HTTP 204 콘텐트 없음 이었던 것 처럼 동작합니다.

    그렇지 않고, 리소스가 URL about:blank에 의해 식별된다면, 리소스는 메타데이터 없이 즉시 사용가능하고 빈 문자열로 구성됩니다.

    그렇지 않으면, 사용자와 유저 에이전트에게 알맞은 시간에 관련된 명세의 의미(semantics)를 적용하여 (예를 들어, HTTP GET이나 POST 연산을 수행하여, 혹은 디스크로부터 파일을 읽어, 혹은 data: URL을 확장하여, 등등) 리소스를 다운로드 (혹은 그렇지 않으면 획득)합니다.

    Referer (sic) 헤더의 목적을 위해, 이전 단계에서 생성된 요청 URI가 얻어지는 리소스의 주소 from which Request-URIs are obtained를 사용합니다.

    Origin 헤더의 목적을 위해, 페칭(fetching) 알고리즘이 origin에서 명시적으로 초기화 되었다면, HTTP 요청을 초기화 한 출처(origin)는 origin입니다. 그렇지 않으면, 이것은 "민감한 개인정보" 컨텍스트로부터의 요청입니다. [ORIGIN]

12. 알고리즘이 쿠키 차단 플래그를 가지고 동작되지 않았고 쿠키가 설정되지 않았다면, 쿠키를 업데이트 합니다. [COOKIES]

13. 가져와진 리소스가 HTTP 리다이렉트 혹은 그와 동등한 것이라면:

    강제 동일 출처(origin) 플래그가 설정되어 있고 리다이렉트 대상의 URL이 페치(fetch) 알고리즘이 동작되는 URL과 같은 동일 출처(origin)를 가지지 않는다면

    원격 호스트가 연결할 수 없는 것 처럼, 이 단계들을 중단하고 이 알고리즘으로부터 실패를 반환합니다.

    수동 리다이렉트 플래그가 설정되어 있다면

    알고리즘의 결과로서 가져와진 리소스(리다이렉트)를 사용하여 계속합니다. 호출 알고리즘이 이후에 유저 에이전트가 투명하게 리다이렉트를 따르도록 요구한다면, 유저 에이전트는 main step으로부터, 원래 리소스 대신에 가져오기 위한 리소스로서 리다이렉트의 대상을 사용하여 이 알고리즘을 재개해야(must)합니다.

    그렇지 않으면

    먼저, 리다이렉트 관련 요구 사항(적절한 프롬프트를 표시하는 것 같은)을 적용합니다. 이후, main step을 원래 리소스 대신에 가져오기 위한 리소스로서 리다이렉트 대상을 사용하여 다시합니다. HTTP 요청의 경우, 새로운 요청은 다른 요구사항이 명시된 헤더(Host 헤더 같은)를 제외하고 본래 요청과 같은 동일한 헤더를 포함해야(must) 합니다. [HTTP]

    HTTP 명세는 301, 302, 307 리다이렉션이 안전한 방법 이외의 방법에 적용 될 때 사용자 확인 없이 따르지 않을 것이 요구됩니다. 그것은 위 문단에서 요구사항의 목적을 위한 적절한 프롬프트가 될 것 입니다. [HTTP]

14. 알고리즘이 동기(synchronous) 플래그를 가지고 호출되지 않았다면: 리소스가 사용가능하거나, 어떤 설명의 오류가 있는 경우, 적절한 리소스를 사용하는 작업을 대기열에 넣습니다. 예를 들어, 순차적으로 JPEG나 HTML 파일이 섞인 것 같은 리소스가 즉시 처리될 수 있다면, 그것이 다운로드 될 때 추가적인 작업이 데이터를 처리하기 위해 대기열에 넣어질 수 있습니다. 이 작업들에 대한 작업 소스는 네트워킹 작업 소스입니다.

    그렇지 않으면, 리소스나 오류 정보를 호출 알고리즘에 반환합니다.

유저 에이전트가 이 알고리즘의 인스턴스에 대해 가져오는 리소스의 실제 길이를 결정할 수 있고, 그 길이가 유한하다면, 그 길이는 파일의 크기입니다. 그렇지 않으면, 알고리즘의 주제(즉, 가져오는 리소스)는 알려진 크기를 가지지 않습니다. (예를 들어, HTTP Content-Length 헤더가 이 정보를 제공할 수 있습니다.)

유저 에이전트는 이 알고리즘의 각 인스턴스에 대해 다운로드 된 바이트 수의 트랙 역시 유지해야(must) 합니다. 이 수는 HTTP 헤더와 같은, 대역 외 메타 데이터를 제외해야(must) 합니다.

이동 처리 모델은 페칭(fetching) 알고리즘에 의해 수행되는 리다이렉션 처리를 재정의 하여, 리다이렉트 자체를 처리합니다.

유형 스니핑 규칙이 가져와진 리소스에 적용되는지 여부는 규칙을 호출하는 알고리즘에 따라 달라집니다 — 그것들이 항상 적절한 것은 아닙니다.

2.6.3. 암호화 된 HTTP와 관련된 보안 문제

HTTP를 참조하는 이 명세의 모든 내용은 https 스킴을 나타내는 URL로 표현되는 TLS상의 HTTP에도 적용됩니다. [HTTP]

유저 에이전트는 사용자에게 인증서 오류를 보고 해야(should)하고, 잘못된 인증서로 전송된 리소스를 다운로드하는 것을 거부해야(must)하거나 그러한 리소스가 실제로 암호화 없이 제공되는 것처럼 수행해야(must)합니다.

유저 에이전트는 페이미가 두 번째 방문 시 보안 수준이 낮은 암호화를 사용한다면 사용자가 이전에 방문했던 페이지를 방문 할 때마다 사용자에게 잠재적인 문제가 있음을 경고해야(should) 합니다.

그렇게 하지 않는 것은 사용자가 중간자(man-in-the-middle) 공격을 알아채지 못하게 할 수 있습니다.

2.6.4. 리소스 유형 결정

리소스의 Content-Type 메타데이터는 MIME 스니핑 명세의 요구사항과 일치하는 방법으로 획득되고 해석되어야(must)합니다. [MIMESNIFF]

리소스의 계산된 유형은 객체의 관련 시퀀스의 계산된 미디어 타입을 찾기 위한 주어진 요구사항과 일치하는 방법으로 찾아져야(must) 합니다. [MIMESNIFF]

명확하게 이미지를 스니핑하기 위한 규칙과 리소스가 텍스트인지 바이너리인지 구분하기 위한 규칙도 마임 스니핑 명세에 정의됩니다. 두 규칙의 집합 모두 그것들의 결과로 MIME 타입을 반환합니다. [MIMESNIFF]

MIME 스니핑 명세의 규칙은 정확하게 반드시 준수되어야 합니다. 유저 에이전트가 When a 유저 에이전트가 서버가 예상하는 것보다 다른 유형 감지를 위한 다른 휴리스틱을 사용하는 경우, 보안 문제가 발생할 수 있습니다. 자세한 내용은 MIME 스니핑 명세를 참고하세요. [MIMESNIFF]

2.6.5. meta 요소(element)로부터 문자 인코딩 추출하기

주어진 문자열 s인, meta 요소(element)로부터 문자 인코딩 추출하기 위한 알고리즘은, 다음과 같습니다. 이것은 문자 인코딩을 반환하거나 아무 것도 반환하지 않을 것입니다.

1. position을 초기에 문자열의 시작을 가리키는, s에 대한 포인터로 둡니다.

2. Loop: 단어 "charset"에 ASCII 대소문자 구분 없이 일치하는 position 이후의 s 내 처음 7개 문자를 찾습니다. 그러한 일치 항목이 발견되지 않으면, 아무 것도 반환하지 않고 이 단계들을 중단합니다.

3. 단어 "charset"에 바로 뒤따르는 모든 공백 문자들을 건너 뜁니다.(아무 것도 없을 수도 있습니다).

4. 다음 문자가 U+003D 등호 기호 (=)가 아니라면, position을 그 다음 문자 바로 이전 지점으로 이동시키고, loop로 라벨링 된 단계로 돌아갑니다.

5. 등호 기호에 바로 뒤따르는 모든 공백 문자들을 건너뜁니다. (아무 것도 없을 수도 있습니다).

6. 다음과 같이 다음 문자를 처리합니다:

   U+0022 따옴표 문자 (")이고 이후에 s에 U+0022 따옴표 문자 (")가 있다면

   U+0027 어포스트로피 문자 (')이고 이후에 s에 U+0027 어포스트로피 문자 (')가 있다면

   이 문자와 다음으로 가장 먼저 나타나는 이 문자 사이의 부분 문자열로부터 인코딩을 얻은 결과를 반환합니다.

   매치되지 않는(unmatched) U+0022 따옴표 문자 (")라면

   즉, <meta charset="""> 과 같이 pair가 없는 U+0022 따옴표 문자(")를 의미.

   매치되지 않는(unmatched) U+0027 어포스트로피 문자 (')라면

   다음 문자가 없다면

   아무 것도 반환하지 않습니다.

   그렇지 않으면

   이 문자부터 첫 공백 문자나 U+003B 세미콜론 문자 (;)을 포함하지 않고, 또는 s의 끝, 어느 쪽이든 처음 오는 문자까지 이들을 구성되는 부분 문자열로부터 인코딩을 얻은 결과를 반환합니다.

   원문이 제법 복잡하게(?) 설명이 되어 있는데 의역해 보자면,

   • 공백 문자나 세미콜론 문자가 있다면 이 공백문자나 세미콜론 문자 전까지
   • s 끝까지

   의 부분 문자열을 인코딩을 얻은 결과로 사용한다는 의미일 것으로 보입니다.

이 알고리즘은 HTTP 명세의 그것과는 다릅니다 (예를 들어, HTTP는 싱글 따옴표를 사용하는 것을 허용하지 않고 이 알고리즘에 의해 지원되지 않는 백슬래쉬 이스케이프(backslash-escape) 메커니즘을 지원하도록 요구합니다). 이 알고리즘이 역사적으로 HTTP에 연관된 컨텍스트에서 사용되는 반면, 구현에 의해 지원되는 구문은 얼마 전에 분기되었습니다. [HTTP]

2.6.6. CORS 설정 속성(attribute)

CORS 설정 속성(attribute)은 열거 속성입니다. 다음 표는 속성(attribute)에 대한 키워드와 상태를 나열합니다 — 왼쪽 열의 키워드는 키워드와 동일한 행의 두 번째 열의 셀에 있는 상태에 매핑됩니다.

빈 문자열은 유효한 키워드이고 익명 상태에 매핑됩니다. 속성(attribute)의 유효하지 않은 기본 값 익명 상태입니다. 반영의 목적을 위해, Anonymous 상태에 대한 정식 사례는 anonymous 키워드입니다. 속성이 생략되었을 경우 사용되는 누락 기본 값은 No CORS 상태 입니다.

2.7. 공통 DOM 인터페이스

2.7.1. IDL 속성(attribute)에 콘텐트 속성(attribute) 반영하기

일부 IDL 속성(attribute)들은 특정 콘텐트 속성(attribute)을 반영하도록 정의됩니다. 이것은 가져올 때 IDL 속성(attribute)은 콘텐트 속성(attribute)의 현재 값을 반환하고, 설정할 때 IDL 속성(attribute)은 콘텐트 속성(attribute)의 값을 주어진 값으로 변경하는 것을 의미합니다.

일반적으로, 가져올 때, 콘텐트 속성(attribute)이 존재하지 않는다면, IDL 속성은 콘텐트 속성(attribute)의 값이 빈 문자열인 것 처럼 동작해야(must) 합니다; 그리고 설정할 때, 콘텐트 속성(attribute)이 존재하지 않는다면, 먼저 추가 되어야(must) 합니다.

반영하는 IDL 속성(attribute)이 콘텐트 속성이 한 개 URL을 포함하도록 정의된 DOMString 속성(attribute)이라면, 가져올 때, IDL 속성(attribute)은 콘텐트 속성(attribute)의 값을 요소(element)에 관련하여 해석해야(must)하고 그것이 성공했다면 결과로 얻어지는 절대 URL을 반환하며, 그렇지 않으면 빈 문자열을 반환해야(must) 합니다; 그리고 설정할 때, 콘텐트 속성(attribute)을 명시된 리터럴 값으로 설정해야(must) 합니다. 콘텐트 속성(attribute)이 존재하지 않는다면, IDL 속성(attribute)은 콘텐트 속성이 기본 값을 가진다면 그 기본 값을, 그렇지 않으면 빈 문자열을 반환해야(must) 합니다.

반영하는 IDL 속성(attribute)이 콘텐트 속성이 하나 이상의 URLs을 포함하도록 정의된 DOMString 속성(attribute)이라면, 가져올 때, IDL 속성(attribute)은 공백으로 콘텐트 속성(attribute)을 분할해야(must)하고 각 토큰 URL을 해석한 것의 연결을 요소에 관련하여, 각 URL 사이에 단일 U+0020 공백 문자를 가지고, 성공적으로 분해(resolve)되지 않은 토큰들은 무시하여, 절대 URL에 반환합니다. 콘텐트 속성(attribute)이 존재하지 않는다면, IDL 속성(attribute)은 콘텐트 속성이 기본 값을 가진다면 그 기본 값을, 그렇지 않으면 빈 문자열을 반환해야(must) 합니다. 설정할 때, IDL 속성(attribute)은 콘텐트 속성(attribute)을 명시된 리터럴 값으로 설정해야(must) 합니다.

반영하는 IDL 속성(attirbute)는 콘텐트 속성(attribute)이 열거 속성인 DOMString 속성(attribute)이고, IDL 속성이 오직 알려진 값에 제한된다면, 가져올 때, IDL 속성(attirbute)은 속성이 속한(그것의 정식 사례에 속한) 상태와 연관된 준수 값이 있다면 그 값이나 속성(attribute)이 연관된 키워드 값을 가지지 않는 상태에 있거나 속성(attribute)이 정의된 상태(예를 들어, 속성(attribute)이 누락되었고 누락 기본 값이 없는)에 속하지 않는다면 빈 문자열을 반환해야(must) 하고; 설정할 때, 콘텐트 속성은 명시된 새로운 값으로 설정 되어야(must) 합니다.

반영하는 IDL 속성(attribute)이 콘텐트 속성(attribute)이 열거 속성인 null이 될 수 있는 DOMString 속성(attribute)이라면, 가져올 때, 해당하는 콘텐트 속성(attirbute)이 누락 기본 값이라면 IDL 속성은 null을 반환해야(must)하고, 그렇지 않으면, IDL 속성(attirbute)은 속성(attribute)이 속하는 상태(그것의 정식 사례에 속한)에 연관된 준수한 값을 반환해야(must) 하며; 설정할 때, 새로운 값이 null이라면, 콘텐트 속성(attribute)은 제거되어야(must)하고, 그렇지 않으면 콘텐트 속성(attribute)은 명시된 새로운 값으로 설정되어야(must) 합니다.

반영하는 IDL 속성(attribute)이 DOMString 속성(attribute)이고 위 카테고리의 어느 범주에도 들어가지 않는다면, 가져오고 설정하는 것은 투명한, 대소문자 보존 방식으로 수행되어야(must) 합니다.

반영하는 IDL 속성(attribute)이 boolean 속성(attribute)이라면, 가져올 때 IDL 속성(attribute)은 콘텐트 속성(attribute)이 설정되었다면 true를 반환하고, 없다면 false를 반환합니다. 설정할 때, 콘텐트 속성(attribute)은 IDL 속성(attribute)이 false로 설정되어 있다면 제거되어야(must) 하고, IDL 속성이 true로 설정되어 있다면 빈 문자열로 설정되어야(must) 합니다. (이것은 불리언 콘텐트 속성(attribute)에 대한 규칙에 해당합니다.)

반영하는 IDL 속성(attribute)이 부호있는 정수 유형(long)을 가진다면, 가져올 때, 콘텐트 속성(attribute)은 부호있는 정수 해석에 대한 규칙을 따라 해석되어야(must)하고, 그것이 성공하고 값이 IDL 속성(attribute)의 유형의 범위에 있다면, 결과 값은 반환되어야(must) 합니다. 반면에, 그것이 실패 혹은 범위 밖의 값을 반환하거나, 속성(attribute)이 존재하지 않는다면, 기본 값이 대신 반환되어야(must)하고, 기본 값이 없다면 0이 반환되어야(must)합니다. 설정할 때, 주어진 값은 유효한 정수로 나타나는 가능한 가장 짧은 문자열로 변환되어야(must)하고 이후 그 문자열은 새로운 콘텐트 속성(attribute) 값으로 사용되어야(must)합니다.

반영하는 IDL 속성(attribute)이 음이 아닌 정수로만 제한된 부호있는 정수 유형 (long)을 가진다면, 가져올 때, 콘텐트 속성(attribute)은 음이 아닌 정수 해석에 대한 규칙을 따라 해석되어야(must) 하고, 그것이 성공했고 값이 IDL 속성(attribute)의 유형의 범위 내에 있다면, 결과 값이 반환되어야(must) 합니다. 반면에, 그것이 실패 혹은 범위 밖의 값을 반환하거나, 속성(attribute)이 존재하지 않는다면, 기본 값이 대신 반환되어야(must)하고, 기본 값이 없다면 -1이 반환되어야(must) 합니다. 설정할 때, 값이 음수라면, 유저 에이전트는 IndexSizeError 예외 오류를 던져야(must) 합니다. 그렇지 않으면, 주어진 값은 유효한 음이 아닌 정수로 나타내는 가능한 가장 짧은 문자열로 변환되어야(must)하고 이후 그 문자열은 새로운 콘텐트 속성(attribute) 값으로 사용되어야(must)합니다.

반영하는 IDL 속성(attribute)이 부호 없는 정수 유형 (unsigned long)을 가진다면, 가져올 때, 콘텐트 속성(attribute)은 음이 아닌 정수 해석에 대한 규칙을 따라 해석되어여(must)하고, 그것이 성공하고, 값이 0에서 2147483647까지 범위에 있다면, 결과 값이 반환되어야(must) 합니다. 반면에, 그것이 실패 혹은 범위 밖의 값을 반환하거나, 속성(attribute)이 존재하지 않는다면, 기본 값이 대신 반환되거나, 기본 값이 없다면 0이 반환되어야(must) 합니다. 설정할 때, 먼저, 새로운 값이 0에서 2147483647까지의 범위에 있다면 n를 새로운 값으로 두고, 그렇지 않으면 n를 기본 값으로 두거나 기본 값이 없다면 0으로 둡니다; 이후 n는 유효한 음이 아닌 정수로 나타나는 가능한 가장 짧은 문자열로 변환되어야(must)하고 그 문자열은 새로운 콘텐트 속성(attribute) 값으로 사용되어야(must) 합니다.

반영하는 IDL 속성(attribute)이 0보다 큰 음이 아닌 정수로만 제한된 부호 없는 정수 유형 (unsigned long)을 가진다면, 동작은 이전 경우와 비슷하게 동작하되 0은 허용되지 않습니다. 가져올 때, 콘텐트 속성(attribute)은 먼저 음이 아닌 정수 해석에 대한 규칙에 따라 해석되어야(must)하고, 그것이 성공하고 값이 1에서 2147483647까지 범위 내에 있다면, 결과 값이 반환되어야(must) 합니다. 반면에, 그것이 실패 혹은 범위 밖의 값을 반환하거나 속성(attribute)이 존재하지 않는다면, 기본 값이 대신 반환되어야(must) 하거나, 기본 값이 없다면 1을 반환해야(must) 합니다. 설정할 때, 값이 0이라면, 유저 에이전트는 IndexSizeError 예외를 던져야(must) 합니다. 그렇지 않으면, 먼저, 새로운 값이 1에서 2147483647 범위 내에 있다면, n을 새로운 값으로 두고, 그렇지 않으면 n을 기본 값으로, 혹은 기본 값이 없으면 1로 둡니다; 그 후, n은 유효한 음이 아닌 정수로 나타나는 가능한 가장 짧은 문자열로 변환되어야(must) 하고 그 문자열은 새로운 콘텐트 속성(attribute) 값으로 사용되어야(must) 합니다.

가져오는 IDL 속성(attribute)이 부동 소수점 수 유형(double나 unrestricted double)을 가진다면, 가져올 때, 콘텐트 속성(attribute)은 부동소수점 수 값 해석에 대한 규칙에 따라 해석되어야 하고 그것이 성공한다면, 결과 값이 반환되어야(must) 합니다. 반면에, 그것이 실패 혹은 속성(attribute)이 존재하지 않는다면, 기본 값이 대신 반환되어야(must) 하거나, 기본 값이 없으면 0.0이 반환되어야(must) 합니다. 설정할 때, 주어진 값은 부동 소수점 수의 가장 좋은 표현으로 변환되어야(must)하고 그 문자열은 새로운 콘텐트 속성(attribute) 값으로 사용되어야(must) 합니다.

반영하는 IDL 속성(attribute)이 0보다 큰 수로 제한된 부동 소수점 수 유형(double나 unrestricted double)를 가진다면, 이전 경우와 비슷하게 동작하되 0과 음수 값은 허용되지 않습니다. 가져올 때, 콘텐트 속성(attribute)은 부동 소수점 수 값 해석에 대한 규칙에 따라 해석되어야(must) 하고, 그것이 성공하고 값이 0.0보다 크다면, 결과 값이 반환되어야(must) 합니다. 반면에, 그것이 실패 혹은 범위 밖의 값을 반환하거나, 속성(attribute)이 존재하지 않는다면, 기본 값이 대신 반환되어야(must)하거나, 기본 값이 없다면 0.0이 반환되어야(must) 합니다. 설정할 때, 값이 0 이하라면, 값은 무시되어야(must) 합니다. 그렇지 않으면, 주어진 값은 부동 소수점 수의 가장 좋은 표현으로 변환되어야(must)하고 그 문자열은 새로운 콘텐트 속성(attribute) 값으로 사용되어야(must) 합니다.

무한대와 Not-a-Number(NaN) 값은, Web IDL 명세에 정의된 대로, 가져올 때 예외를 던집니다. [WEBIDL]

가져오는 IDL 속성(attribute)이 DOMTokenList 유형을 가진다면, 가져올 때 연관된 요소(element)가 문제의 요소이고 연관된 속성(attribute)의 지역 이름이 문제의 속성의 이름인 DOMTokenList 객체를 반환해야(must) 합니다. 동일한 DOMTokenList 객체는 각 속성(attribute)에 대해 매 번 반환되어야(must) 합니다.

반영하는 IDL 속성(attribute)이 HTMLElement 유형이나 HTMLElement의 자손 인터페이스를 가진다면, 가져올 때, 다음 알고리즘을 수행해야(must) 합니다(값을 반환하는 첫 번째 단계에서 중단하여):

1. 해당하는 콘텐트 속성(attribute)이 존재하지 않는다면, IDL 속성(attribute)은 null을 반환해야(must) 합니다.

2. document.getElementById() 메서드가 인수로 해당 컨텐츠 속성의 현재의 값을 건네 받았을 경우 콘텐트 속성(attribute)의 요소(element)의 노드 문서에서 호출 될 때 찾는 요소로 둡니다.

3. candidate이 null이거나 IDL 속성(attribute)와 유형 호환되지 않는다면, IDL 속성(attribute)은 null을 반환해야(must) 합니다.

4. 그렇지 않으면, candidate를 반환해야 합니다.

설정할 때, 주어진 요소(element)가 id 속성(attribute)을 가지고, 속성(attribute)이 설정된 요소와 동일한 홈 하위 트리를 가지며, 주어진 요소(element)가 그 홈 하위 트리에서 ID가 그 id 속성(attribtue)의 값인 첫 번째 요소(element)라면, 콘텐트 속성(attribute)은 그 id 속성(attribute)의 값으로 설정되어야(must) 합니다. 그렇지 않으면, 콘텐트 속성(attribute)은 빈 문자열로 설정되어야(must) 합니다.

2.7.2. 컬렉션

HTMLFormControlsCollection과 HTMLOptionsCollection 인터페이스들은 HTMLCollection 인터페이스로부터 유래된 컬렉션입니다. 하지만 HTMLAllCollection은 HTMLCollection으로부터 상속하기에 바람직하지 않은 다양한 기이한 특징을 가지기 때문에 독립적입니다.

2.7.2.1. HTMLAllCollection 인터페이스

HTMLAllCollection 인터페이스는 레거시 document.all 속성(attribtue)에 사용됩니다. HTMLCollection과 비슷하게 동작합니다; 함수처럼 호출 될 수 있는 것과 같은 웹 호환성을 위해 요구되는 다양한 다른 레거시 기능도 지원합니다(legacycaller).

모든 HTMLAllCollection 객체는 Document에 뿌리를 두고 있고 모든 요소와 일치하는 필터를 가지기 때문에, HTMLAllCollection 객체의 컬렉션에 의해 나타나는 요소(element)들은 루트 Document의 후손 요소(element)들로 구성됩니다.

[LegacyUnenumerableNamedProperties]
interface HTMLAllCollection {
  readonly attribute unsigned long length;
  getter Element? (unsigned long index);
  getter (HTMLCollection or Element)? namedItem(DOMString name);
  legacycaller (HTMLCollection or Element)? item(optional DOMString nameOrItem);
};

collection . length

컬렉션 내 요소(element)의 수를 반환합니다.

element = collection . item(index)

element = collection(index)

element = collection[index]

컬렉션으로부터 (트리 순서에 의해 결정된) 인덱스 index를 가진 항목을 반환합니다.

element = collection . item(name)

collection = collection . item(name)

element = collection . namedItem(name)

collection = collection . namedItem(name)

element = collection(name)

collection = collection(name)

element = collection[name]

collection = collection[name]

컬렉션으로부터 ID나 이름 name를 가진 항목을 반환합니다.

여러 개의 매칭되는 항목이 있다면, 그 요소들 모두를 포함하는 HTMLCollection 객체가 반환됩니다.

name 속성(attribute)의 값은 button, input, select, textarea에 대한 이름을 제공합니다. 비슷하게, iframe의 name, object의 name, meta의 name, map의 name, form의 name 속성(attribute)의 값은 각 요소(element)에 대한 이름을 제공합니다. 언급된 요소(element)들만이 이 메서드의 목적을 위한 name을 가집니다.

객체의 지원되는 속성(property) 인덱스는 HTMLCollection 객체에 대해 정의된 것과 같습니다.

지원되는 속성(property) 이름은 트리 순서에 따라, 이후 중복된 것을 무시하여, id와 name를 모두 제공한다면, 요소(element)의 name에 앞선 id를 가지고 컬렉션에 의해 나타나는 모든 요소(element)들의 모든 id과 name 속성(attribute)의 비어 있지 않은 값으로 구성됩니다. id와 name이 모두 있을 경우, 이것들은 서로 다른 것이며 앞선 엔트리의 복제 역시 아닙니다.

가져올 때, length 속성(attribute)은 컬렉션에 의해 나타난 노드의 수를 반환합니다.

인덱싱 된 속성(property) getter는 전달받은 인덱스가 주어진 이 HTMLAllCollection로부터 모든 인덱싱 된 요소(element)를 가져온 결과를 반환해야(must) 합니다.

namedItem(name) 메서드는 name이 주어진 이 HTMLAllCollection로부터 모든 이름이 붙은 요소(element)나 요소들(elements)을 가져온 결과를 반환해야(must) 합니다.

item(nameOrIndex) 메서드는 (그리고 legacycaller 동작은) 다음 알고리즘을 따라 수행해야(must) 합니다:

1. nameOrIndex가 제공되지 않았다면, null을 반환합니다.

2. 자바스크립트 문자열 값으로 변환 된 nameOrIndex가 배열 인덱스 속성(property) 이름이라면, nameOrIndex에 의해 나타난 숫자가 주어진 이 HTMLAllCollection으로부터 인덱싱 된 모든 요소(element)를 가져온 결과를 반환합니다.

3. nameOrIndex가 주어진 이 HTMLAllCollection으로부터 이름이 붙은 모든 요소(element) 혹은 요소들(elements)을 가져온 결과를 반환합니다.