W3C

HTML 5.1

W3C Recommendation,

This version:
https://www.w3.org/TR/2016/REC-html-5.1-20161101/
Latest published version:
http://www.w3.org/TR/html51/
Editor's Draft:
https://w3c.github.io/html/
Previous Versions:
http://www.w3.org/TR/2016/WD-html51-20160503/
Editors:
(The Paciello Group)
(Microsoft)
(Microsoft)
(Google)
Former Editors:
(Microsoft)
(Apple Inc.)
Robin Berjon (W3C)
Participate:
File an issue (open issues)
Others:
Single page version

Abstract

This specification defines the 5th major version, first minor revision of the core language of the World Wide Web: the Hypertext Markup Language (HTML). In this version, new features continue to be introduced to help Web application authors, new elements continue to be introduced based on research into prevailing authoring practices, and special attention continues to be given to defining clear conformance criteria for user agents in an effort to improve interoperability.

Status of this document

The following features are at-risk, and may be dropped during the CR period:

“At-risk” is a W3C Process term-of-art, and does not necessarily imply that the feature is in danger of being dropped or delayed. It means that the WG believes the feature may have difficulty being interoperably implemented in a timely manner, and marking it as such allows the WG to drop the feature if necessary when transitioning to the Proposed Rec stage, without having to publish a new Candidate Rec without the feature first.

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)를 추가하기 위해 사용될 수 있는 다수의 확장성 메커니즘을 가집니다:

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 소개

HTML 표준에 대한 컨텍스트를 제공하는 비규범적 자료.

§2 공통 인프라

적합한 클래스, 알고리즘, 정의, 명세 나머지 부분의 공통적인 기초 보강

§3 HTML 문서의 의미론, 구조, API

문서는 요소들로 이루어져있습니다. 이 요소들은 DOM을 사용하는 트리로 구성됩니다. 이 섹션은 이 DOM의 기능뿐 아니라, 모든 요소에 대한 공통 기능과, 정의하는 요소들에 사용되는 개념을 정의합니다.

§4 HTML의 요소(element)들

각 요소들은 사전에 정의된 의미(meaning)를 가지고, 이것이 이 섹션에서 설명됩니다. 작성자가 요소를 사용하는 방법에 대한 규칙이, 유저 에이전트가 각 요소를 처리하는 방법에 대한 요구사항들과 함께 제공됩니다. 이것은 비디오 재생과 자막, 양식 제어와 양식 전송, HTML 캔버스로 알려진 2D 그래픽 API 같은 HTML의 큰 특징들을 포함합니다.

§5 User interaction

HTML 문서는 사용자가 콘텐트와 상호작용하고 수정하도록 다수의 메커니즘을 제공할 수 있고, 이는 포커스가 동작하는 방식, 드래그 앤 드롭 같은 것이 이 섹션에 기술됩니다.

§6 Loading Web pages

HTML 문서는 의미 없이 존재하지 않습니다 — 이 섹션은 웹 브라우저들과 웹 어플리케이션의 오프라인 캐싱 같은, 여러 페이지를 처리하는 환경에 영향을 미치는 많은 기능들을 정의합니다.

§7 Web application APIs

이 섹션은 HTML에서 어플리케이션의 스크립팅에 대한 기본 기능을 소개합니다.

§8 The HTML syntax

§9 The XHTML syntax

모든 이 기능들은 직렬화 된 양식으로 표현될 수 없고 다른 사람에게 보낼 수 없다면 쓸모 없게 될 것이고, 그래서 이 섹션들은 HTML과 XHTML의 구문과 함께, 그 구문들을 사용하여 콘텐트를 해석하는 방법에 대한 규칙을 정의합니다.

§10 Rendering

이 섹션은 웹 브라우저에 대한 기본 렌더링 규칙들을 정의합니다.

또한 §11 Obsolete features§12 IANA considerations을 나열하는 몇 가지 부록이 있고, 약간의 색인이 있습니다.

1.7.1. 이 명세를 읽는 방법

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

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

예를 들어, "foo 속성(attribute)의 값은 유효한 정수이어야(must) 합니다."는 허용된 값을 제시하는 것으로서, 제작자에 대한 요구사항입니다; 그에 반해, "foo 속성(attribute)의 값은 정수를 해석하기 위한 규칙을 사용하여 해석되어야(must) 합니다."는 콘텐트를 어떻게 처리해야 하는지를 설명하는 것으로, 소비자에 대한 요구사항입니다.

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

위 예에 이어서, 특정한 속성(attribute)의 값이 유효한 정수로 강요된다고 서술된 요구 사항은 전혀 소비자에 대한 요구사항에 대하여 어떠한 것도 의미하지 않습니다. 소비자는 사실 불분명한 문자열로 속성을 취급하도록 요구될 수도 있으며, 값이 요구사항에 맞는지 맞지 않는지에 전혀 영향을 받지 않습니다. (이전 예제에서와 같이) 소비자는 값을 유효하지 않은 값(이 경우에는 숫자가 아닌)을 처리하는 방법을 정의하는 특정한 규칙을 사용하여 해석하도록 요구될 수도 있습니다.

1.7.2. 표기법

이것은 정의, 또는 요구사항, 또는 설명입니다.

이것은 주석(note)입니다.

이것은 예시입니다.

이것은 해결되지 않은 이슈입니다.

이것은 경고입니다.

interface Example {
    // 이것은 IDL 정의입니다.
};
variable = object . method( [ optionalArgument ] )
이것은 사용자에게 인터페이스 사용을 설명하는 주석입니다.
/*  CSS  . */

용어를 정의하는 것은 this와 같이 마크업 됩니다. 그 용어의 사용은 thisthis와 같이 마크업 됩니다.

요소(element), 속성(attribute), API를 정의하는 것은 this와 같이 마크업됩니다. 그 요소(element), 속성(attribute), API를 참조하는 것은 this와 같이 마크업 됩니다.

다른 코드 조각들은 이렇게 마크업 됩니다..

0x00 부터 0x7F까지 폭넓은 범위 내 바이트를 가진 바이트 시퀀스는 `this`와 같이 마크업 됩니다.

변수는 this와 같이 마크업 됩니다.

알고리즘에서, 동기 섹션 내 단계들은 ⌛과 함께 마크업 됩니다.

경우에 따라, 요구 사항들은 조건과 해당하는 요구 사항들을 가지고 리스트 형태로 주어집니다. 그러한 경우에, 조건에 적용되는 요구 사항들은, 그 요구 사항들에 대한 여러 세트의 조건이 존재하는 경우에도, 항상, 조건이 따르는 요구 사항의 첫 번째 세트입니다. 그러한 경우들이 다음과 같이 표현됩니다:

이것은 조건입니다.
이것은 다른 조건입니다.
이것은 위 조건에 적용되는 요구 사항입니다.
이것은 세 번째 조건입니다.
이것은 세 번째 조건에 적용되는 요구 사항 입니다.

1.8. 개인 정보 보호

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

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

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

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

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

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

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

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

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

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

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

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

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 트리로 바뀔 것 입니다:

이 트리의 루트 요소(element)html 요소(element)이고, 이것은 항상 HTML 문서의 루트에서 발견됩니다. 이 요소는 두 요소(element), headbody 뿐 아니라 둘 사이에 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 요소들과 load 이벤트로 명시할 수 있습니다. 이벤트는 요소(element)가 해석 되자마자, 특히 이미지가 이미 캐시되었다면(이것이 일반적입니다), 발생 될 수 있습니다.

여기서, 작성자는 load 이벤트를 발견하기 위해 img 요소(element)의 onload 핸들러를 사용합니다:

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

요소(element)가 스크립트에 의해 추가된 후 이벤트 핸들러가 동일한 스크립트에서 추가되는 한, 이벤트는 If the element is being added by script, then so long as the event handlers are added in the 여전히 놓치지 않습니다:

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

그러나, 작성자가 처음 img 요소(element)를 생성했고 분리된 스크립트에서 이벤트 리스너가 추가되었다면, 그것을 놓치게 유도하여 load 이벤트가 그 사이에 발생되는 기회가 생깁니다.

<!-- 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"는 "&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)은, circcircle 값을 실제로 동의어로서 모두 허용함에도 불구하고, 튜토리얼과 다른 학습 지원을 간소화 하기 위해, 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 사이에서 마이그레이션 하는 경우 과도기적 단계로 작성자가 이것을 사용하는 것을 더 쉽게 합니다.

예를 들어, 동기화를 유지하도록 의도된 langxml: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) 같은)의 DocumentNodeownerDocument IDL 속성(attribute)이 반환하는 Document 입니다. NodeDocument 안에 있는 경우 그 Document는 항상 NodeDocument이고, NodeownerDocument 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 인자로 AoldParent 인자로 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/plainapplication/octet-stream 유형을 등록된 플러그인을 가지는 것으로 간주해서는 안됩니다.

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

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

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

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

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

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

2.1.6. 문자 인코딩

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

UTF-16 인코딩UTF-16BEUTF-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.

여기서 키워드는 "must"입니다.

전자의(명령조) 방식은 일반적으로 문제상의 이유로 이 명세에서 선호됩니다.

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

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]

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

HTTP 그리고 관련된 명세

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

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

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

가져오기(Fetch)

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

웹 IDL

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

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

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

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

이 명세가 유저 에이전트가 특정 시간(특별한 값 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]:

DOM

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

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

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

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

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

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

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

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

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

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

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

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

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

파일 API

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

미디어 소스 확장

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

미디어 캡쳐와 스트림

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

XMLHttpRequest

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

ProgressEvent

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

서버 발송 이벤트(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]

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

<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]

SVG

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

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

WebGL

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

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]

게다가, 다음 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]

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

서비스 워커

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

  • 서비스 워커 등록 매칭

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

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

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

2.2.3. 확장성

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

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

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

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

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

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

예를 들어, 사용자가 엘레베이터에서 올라갈 때 보여주기 위한 이벤트 "Pleasold"를 호출했다면, "pleasold" 접두어를 사용할 수 있고 따라서 이벤트를 아마 "onpleasoldgoingup"라고 명명된 이벤트 핸들러가 있는 "pleasoldgoingup"로 명명합니다.

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

예를 들어, 그렇게 하는 것이 강하게 지양되는 동안, "Foo Browser" 구현은 새로운 IDL 속성(attribute) "fooTypeTime"를 사용자가 컨트롤의 현재 값을 선택한 시간이 반환되는 컨트롤의 DOM 인터페이스에 추가할 수 있습니다(일례로). 다른 한편으로, 양식(form)의 elements 배열에 나타나는 새로운 컨트롤을 정의하는 것은 이 명세에 주어진 elements의 정의를 위반할 것이기 때문에 위 요구사항을 위반할 것입니다.

"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) 내 해당하는 문자로 바꾸는 것을 의미합니다.

문자열 patterns보다 길지 않고 spattern의 길이로 잘라내는 것이 두 문자열을 서로 일치하게 하는 경우 문자열 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. inputposition를 이 단계들을 호출하는 알고리즘에 동일한 이름의 것들로서 같은 변수가 되도록 합니다.

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

  3. positioninput의 끝을 지나치지 않고 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. positioninput의 끝을 지나치지 않은 동안:

    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) 합니다.

여기 checked와 disabled인 checkbox의 예가 있습니다. checkeddisabled 속성(attribute)은 불리언 속성(attribute)입니다.
<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. positioninput의 끝을 지났다면, 오류를 반환합니다.

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

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

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

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

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

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

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

  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. positioninput의 끝을 지났다면, 오류를 반환합니다.

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

    1. valuedivisor를 -1로 변경합니다.

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

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

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

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

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

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

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

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

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

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

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

    2. positioninput의 끝을 지났거나, 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. positioninput의 끝을 지났다면, 변환으로 라벨링 된 단계로 건너뜁니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  17. rounded-value가 21024나 -21024라면, 오류를 반환합니다.

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

2.4.4.4. 백분율과 길이

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

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

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

  3. 여백을 건너뜁니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  11. positioninput의 끝을 지났다면, 길이로서 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. positioninput의 끝을 지나지 않은 경우:

    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. numbernumbers에 추가합니다.

    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. unitabsolute로 둡니다.

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

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

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

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

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

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

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

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

        3. valuefraction 만큼 증가시킵니다.

    8. 여백을 건너뜁니다.

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

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

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

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

2.4.5. 날짜와 시간

이 명세는 날짜에 대한 [ISO8601] 표준의 공통 부분 집합에 따라 날짜와 시간을 인코드합니다.

이는 인코드 된 날짜는 1582-03-01, 0033-03-27, 2016-03-01 와 같이 보이고, 날짜-시간은 1929-11-13T19:00Z, 0325-06-03T00:21+10:30와 같이 보이는 것을 의미합니다. 형식은, 비록 일부분은 예를 들어 생일의 월과 일, 표준 시간대 정보가 없는 시간 등과 같이 표현하기 위해 선택적이기는 하지만, 대략 YYYY-MM-DDTHH:MM:SS.DD±HH:MM 입니다.

시간은 24시간제를 사용하여 표현되고, 윤초를 표현하는 것은 오류입니다.

날짜는 역산 0000년과 9999년 사이의 역산 그레고리력으로 표현됩니다. 다른 해는 인코드될 수 없습니다.

역산 그레고리력은 1950년 이후로 전 세계적으로 가장 일반적인 달력이고, 1950년과 9999년 사이 날짜의 모든 사람들, 그리고 지난 수십 년 또는 수세기 동안 많은 사람들이 이해할 수 있습니다.

그레고리력은 교황 그레고리 13세에 의해 율리우스력에 대한 대체로서 제안된 1582년과 중국 인민 공화국에 의해 채택된 1947년 사이에, 다른 나라, 다른 시간에 공식적으로 채택되었습니다.

현재, 가까운 과거, 다음 몇 천년을 다루는, 대부분의 현실적인 목적을 위해, 이것은 문제없이 작동 할 것입니다. 그레고리력 채택 전 날짜에 대해 - 예를 들어 러시아나 터키에서 1917년에 앞선, 영국 혹은 이후 아메리카 영국 식민지에서 1752년에 앞선, 스페인, 아메리카 스페인 식민지, 세계 나머지에서 1582년에 앞선, 날짜는 그 때 쓰여진 것들과 일치하지 않을 것입니다.

그레고리력을 기본 인코딩으로 사용하는 것은 다소 임의적인 선택입니다. 많은 다른 달력이 사용 되었거나 사용되고 있고, 관심있는 독자는 웹에 대한 정보를 찾아야(should) 합니다.

(작성자를 위한) 형식에서 날짜, 시간, 숫자 형식의 논의, 폼 컨트롤의 지역화에 관한 구현 노트, time 요소(element) 또한 참고하세요.

다음 알고리즘에서, 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. yearmonth를 얻기 위해 월 컴포넌트를 해석합니다. 이것이 아무 것도 반환하지 않는다면, 실패입니다.

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

  5. yearmonth를 반환합니다.

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

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

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

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

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

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

  6. yearmonth를 반환합니다.

2.4.5.2. 날짜

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

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

  1. yearmonth를 나타내는 유효한 월 문자열

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

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

예를 들어, 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. positioninput의 끝을 지나지 않으면, 실패입니다.

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

  6. date를 반환합니다.

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

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

  2. maxdayyearmonth월의 날짜의 수로 둡니다.

  3. positioninput의 끝을 지나거나 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. maxdaymonth월과 임의의 윤년(예를 들어, 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. monthday를 얻기 위해 연도 없는 날짜 컴포넌트를 해석합니다. 이것이 아무 것도 반환하지 않는다면 실패입니다.

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

  5. monthday를 반환합니다.

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

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

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

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

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

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

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

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

  8. monthday를 반환합니다.

2.4.5.4. 시간

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

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

  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. positioninput의 끝을 지나지 않으면, 실패입니다.

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

  6. time을 반환합니다.

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

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

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

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

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

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

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

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

    1. positioninput 내 다음 문자로 전진시킵니다.

    2. positioninput의 끝 혹은 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. positioninput의 끝을 지났거나 position에 있는 문자가 U+0054 라틴 대문자 T (T)나 U+0020 공백 문자가 아니라면, 실패입니다. 그렇지 않으면, position를 한 글자 앞으로 이동합니다.

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

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

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

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

  9. datetime을 반환합니다.

2.4.5.6. 표준 시간대

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

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

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

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

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

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

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

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

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

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

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

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

    1. timezonehours를 0으로 둡니다.

    2. timezoneminutes를 0으로 둡니다.

    3. positioninput 내 다음 문자로 전진시킵니다.

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

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

    2. positioninput 내 다음 문자로 전진시킵니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  2. timezonehourstimezoneminutes를 반환합니다.

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)합니다.

다음은 유효한 세계 날짜와 시간 문자열로 작성된 날짜의 몇 가지 예입니다.

"0037-12-13 00:00Z"

런던 시간 사용하는 지역에서 네로(로마 황제)의 생일의 자정. 이것이 실제로 어느 날짜에 해당하는지에 대한 자세한 설명은 아래를 참고하세요.

"1979-10-14T12:00:00.001-04:00"

일광 절약 시간제 동안 미국 동부 해안에서 사용하는 표준 시간대에서, 1979년 10월 14일 정오 이후 1밀리 초.

"8592-01-01T02:09+02:09"

8598년 1월 1일 자정 UTC. 그 시간과 관련된 표준 시간대는 현재 실제 표준 시간대가 아닌, UTC보다 2시간 9분 빠르지만, 그렇더라도 허용됩니다.

이 날짜들에 대해 몇 가지 주목할 만한 것들이 있습니다:

  • 4자리 숫자 이하의 연도는 0으로 채워져야(have to) 합니다. "37-12-13" 날짜는 유효한 날짜가 되지 않을 것입니다.

  • "T"가 공백으로 대체된다면, 이것은 하나의 공백 문자여야(must) 합니다. "2001-12-21  12:00Z" (컴포넌트 사이에 2개의 공백이 있는) 문자열은 성공적으로 해석되지 않을 것입니다.

  • 그레고리 달력의 도입에 앞선 시간의 때를 분명하게 확인하기 위해 (UTC 형성 이전 시간의 때가 분명하게 식별될 수 있는 한), 날짜는 그 때 사용되는 달력으로부터(예를 들어 율리우스력으로부터) 그레고리력으로 먼저 변환되어야(has to) 합니다. 네로의 생일 날짜는 율리우스력으로 37년 12월 15일이고, 역산 그레고리력으로는 37년 12월 13일입니다.

  • 시간과 표준 시간대 편차 컴포넌트는 선택 사항이 아닙니다.

  • 1년 이전의 날짜는 HTML의 이 버전에서 일시(datetime)로 나타낼 수 없습니다.

  • 시간은 상대적으로 최근 수십 년까지 잘 조정되거나 측정되지 않았기 때문에, 고대의 특정 사건의 시간은 잘해야 근사치입니다.

  • 표준 시간대 편차는 일광 절약 시간제에 따라 달라집니다.

지역 편차는 완전한 표준 시간대 명세가 아닙니다. 실제 날짜와 시간 값으로 작업하는 경우, 아마도 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. positioninput의 끝을 지나거나 position에 위치한 문자가 U+0054 라틴 대문자 T 나 U+0020 공백문자가 아니라면, 실패입니다. 그렇지 않으면, position을 한 글자 앞으로 이동합니다.

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

  6. positioninput의 끝을 지났다면 실패입니다.

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

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

  9. timetimezonehours시간 timezoneminutes분을 뺀, yearmonthdayhourminutesecond초 시간의 시점으로 둡니다. 그 시간의 시점은 UTC 표준 시간대의 시점입니다.

  10. timezone을 UTC로부터 timezonehours 시간 timezoneminutes분 입니다.

  11. timetimezone를 반환합니다.

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) yearweek 주를 나타내는 유효한 주 문자열입니다:

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

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

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

  8. maxweekyear년의 마지막 날의 주차 수로 둡니다.

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

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

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

2.4.5.9. 기간

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

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

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

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

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

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

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

  4. M-disambiguatorminutes로 둡니다.

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

  5. 여백을 건너뜁니다.

  6. positioninput의 끝을 지났다면, 실패입니다.

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

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

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

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

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

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

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

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

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

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

    7. positioninput의 끝을 지났다면, 실패입니다.

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

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

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

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

      3. lengths내 문자의 개수로 둡니다.

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

      5. Nfraction만큼 증가시킵니다.

      6. 여백을 건너뜁니다.

      7. positioninput의 끝을 지났다면, 실패입니다.

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

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

      10. unitsseconds로 설정합니다.

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

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

      2. next character가 U+0059 라틴 대문자 Y나 U+0079 라틴 소문자 Y라면, unitsyears로 설정하고 M-disambiguatormonths로 설정합니다.

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

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

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

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

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

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

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

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

    11. multiplier를 1로 둡니다.

    12. unitsyears라면, multiplier에 12를 곱하고 unitsmonths로 설정합니다.

    13. unitsmonths라면, Nmultiplier의 곱을 months에 더합니다.

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

      1. unitsweeks라면, multiplier에 7을 곱하고 unitsdays로 설정합니다.

      2. unitsdays라면, multiplier에 24를 곱하고 unitshours로 설정합니다.

      3. unitshours라면, multiplier에 60을 곱하고 unitsminutes로 설정합니다.

      4. unitsminutes라면, multiplier에 60을 곱하고 unitsseconds로 설정합니다.

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

    14. 여백을 건너뜁니다.

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

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

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

2.4.5.10. 시간의 모호한 때

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. positioninput의 끝을 지나지 않은 경우:

    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: positioninput의 끝을 지났다면, 마지막 단계로 건너뜁니다.

  5. U+002C COMMA 문자 (,)가 아닌 일련의 문자를 수집합니다. s를 결과 시퀀스(빈 문자열일 수 있습니다)로 둡니다.

  6. s에서 앞뒤 여백 문자를 비워냅니다.

  7. stokens에 추가합니다.

  8. positioninput의 끝을 지나지 않았따면, 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. documentiframe srcdoc 문서라면, Document브라우징 컨텍스트브라우징 컨텍스트 컨테이너노드 문서문서 기본 URL을 반환합니다.

  2. documentURLabout:blank이고, document브라우징 컨텍스트생성자 브라우징 컨텍스트를 가진다면, 생성자 기본 URL을 반환합니다.

  3. documentURL을 반환합니다.

Document 객체의 문서 기본 URL은 이 하위 단계들을 수행하여 얻어지는 절대 URL입니다:

  1. Documenthref 속성(attribute)를 가진 base 요소(element)가 없다면, 문서 절대 URLDocument폴백 기본 URL입니다; 이 단계들을 중단합니다.

  2. 그렇지 않으면, 문서 기본 URL트리 순서에 따라 Document 내의 href 속성(attribute)을 가진 첫 번째 base 요소(element)의 고정(frozen) 기본 URL입니다.

2.5.2. URL 해석

URL 해석은 URL 문자열을 가져오고 그것이 의미하는 URL 레코드를 획득하는 과정입니다. 이 과정이 WAHTWG URL 표준에 정의되어 있지만, 이 명세는 편의상 래퍼를 정의합니다. [URL]

이 래퍼는 레거시 이유로 URL 해석기에 대한 문자 인코딩이 문서나 환경 설정 객체의 문자 인코딩과 일치해야(has to) 하는 경우에만 유용합니다. 문자 인코딩이 그 경우가 아닌 경우 URL 해석기가 직접적으로 사용될 수 있습니다.

documentenvironment settings object과 관련된, url URL을 해석하기 위해, 유저 에이전트는 다음 단계들을 사용해야(must) 합니다. URL 해석은 실패되거나 결과 URL 문자열결과 URL 레코드가 됩니다.

  1. document가 주어졌고, environment settings objectAPI URL 문자 인코딩은 주어지지 않았다면, encodingdocument문자 인코딩으로 둡니다.

  2. document가 주어졌고, environment settings objectbaseURLAPI 기본 URL은 주어지지 않았다면, document기본 URL로 둡니다.

  3. urlRecordbaseURLencoding과 함께, URL 해석기url에 적용한 결과로 둡니다.

  4. urlRecord가 실패라면, 오류와 함께 이 단계를 중단합니다.

  5. urlStringURL 시리얼라이저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 관점에서, 멱등하고 안전합니다.

멱등(idempotent)
멱등성(冪等性, 영어: idempotence)은 수학이나 전산학에서 연산의 한 성질을 나타내는 것으로, 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질을 의미.
메서드를 여러 번 호출해서 한 번만 호출한 것과 동일한 결과가 나오는 경우 이 메서드를 멱등(idempotent)이라고 할 수 있습니다. 예를 들어 읽기 전용 메서드와 같이 일반적으로 서버 측의 어떠한 상태도 변경하지 못하는 모든 메서드는 멱등(idempotent)입니다.
GET 방식과 POST로 데이터를 전송받은 URL을 재요청(refresh 등으로)할 경우, GET 페이지는 이전과 재요청 후와 동일한 결과를 응답하겠지만, POST 페이지는 재요청 시 데이터 누락으로 올바르지 않은 페이지를 응답하게 되는 것. (참고 : protocol spec)

HTTP 응답 코드는 동일한 기본 의미(meanings)를 갖는 다른 프로토콜에서의 상태와 동일합니다. 예를 들어, "file not found" 오류는 404 코드와 동일하고, 서버 오류는 5xx 코드와 동일합니다.

HTTP 헤더는 동일한 기본 의미(meanings)를 갖는 다른 프로토콜에서의 필드와 동일합니다. 예를 들어, HTTP 인증 헤더는 FTP 프로토콜의 인증 측면과 동일합니다.

리퍼러 소스DocumentURL입니다.

url, corsAttributeState, 선택적으로 동일 출처(origin) 폴백 플래그가 주어진 잠정적 CORS 요청을 생성하기 위해 이 단계들을 수행합니다:

  1. corsAttributeStateNo CORS이라면 mode를 "no-cors"로 두고, 그렇지 않으면 "cors"로 둡니다.

  2. 동일 출처(origin) 폴백 플래그가 설정되고 mode가 "no-cors"라면, mode를 "same-origin"로 설정합니다.

  3. credentialsMode를 "include"로 둡니다.

  4. corsAttributeState익명(Anonymous)이라면, credentialsMode를 "same-origin"로 설정합니다.

  5. requestURLurl이고, 목적지가 "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. documentiframe srcdoc 문서임에도 불구하고, document를 대신 document브라우징 컨텍스트브라우징 컨텍스트 컨테이너Document로 둡니다.

  4. Document출처(origin)가 scheme/host/port 튜플이 아니라면, referrer를 빈 문자열로 설정하고 Clean referrer로 라벨링 된 단계로 건너뜁니다.

  5. referrerdocument문서 주소로 둡니다.

  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이나 그와 동등한 것과 같은)을 사용하여 얻어진 것이고, 이미 다른 이유로 다운로드 되고 있고(예를 들어, 이 알고리즘의 다른 발동), 이 요청이 이전의 요청과 동일하고 (예를 들어, 동일한 AcceptOrigin헤더), 유저 에이전트가 새로운 다운로드를 개시하는 대신 기존 다운로드로부터 데이터를 다시 사용하도록 구성되어 있다면, 새로운 다운로드를 시작하는 대신 기존 다운로드의 결과를 사용합니다.

    그렇지 않고, 리소스가 리소스를 획득하기 위한 메커니즘을 정의하지 않는 스킴 (예를 들어, 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) 알고리즘에 의해 수행되는 리다이렉션 처리를 재정의 하여, 리다이렉트 자체를 처리합니다.

유형 스니핑 규칙이 가져와진 리소스에 적용되는지 여부는 규칙을 호출하는 알고리즘에 따라 달라집니다 — 그것들이 항상 적절한 것은 아닙니다.

HTTP를 참조하는 이 명세의 모든 내용은 https 스킴을 나타내는 URL로 표현되는 TLS상의 HTTP에도 적용됩니다. [HTTP]

유저 에이전트는 사용자에게 인증서 오류를 보고 해야(should)하고, 잘못된 인증서로 전송된 리소스를 다운로드하는 것을 거부해야(must)하거나 그러한 리소스가 실제로 암호화 없이 제공되는 것처럼 수행해야(must)합니다.

유저 에이전트는 페이미가 두 번째 방문 시 보안 수준이 낮은 암호화를 사용한다면 사용자가 이전에 방문했던 페이지를 방문 할 때마다 사용자에게 잠재적인 문제가 있음을 경고해야(should) 합니다.

그렇게 하지 않는 것은 사용자가 중간자(man-in-the-middle) 공격을 알아채지 못하게 할 수 있습니다.

중간자(man-in-the-middle) 공격
웹사이트와 방문자 사이에 끼어들어네트워크 통신을 조작하여 통신 내용을 도청하거나 조작하는 공격 기법
중간자 공격은 통신을 연결하는 두 사람 사이에 중간자가 침입하여, 두 사람은 상대방에게 연결했다고 생각하지만 실제로는 두 사람은 중간자에게 연결되어 있으며 중간자가 한쪽에서 전달된 정보를 도청 및 조작한 후 다른 쪽으로 전달합니다.
사용자가 자체 서명된 인증서를 가지고 서버에 연결한다면, 유저 에이전트는 암호화가 없었던 것 처럼 연결을 허용할 수 있습니다. 유저 에이전트가 대신 사용자가 문제를 무시한 후 완전히 안전하게 암호화 된 것처럼 페이지를 표시하도록 허용했다면, 사용자는 중간자(man-in-the-middle) 연결을 수용할 수 있도록 쉽게 속일 수 있습니다.

사용자가 전체 암호화 된 서버에 연결했지만, 페이지가 이후 만료 된 인증서를 가진 외부 리소스를 참조한다면, 유저 에이전트는, 어쩌면 사용자에게 문제를 보고하여, 리소스를 사용할 수 없는 것처럼 동작할 것입니다. 유저 에이전트가 대신 리소스가 사용되도록 허용했다면, 공격자는 다른 호스트의 리소스를 사용한 "보안" 사이트를 찾을 수 있고, 예를 들어 페이지의 스크립트를 넘겨받아, 그 호스트에 중간자(man-in-the-middle) 공격을 적용할 수 있습니다.

사용자가 CA 서명 인증서를 사용하는 사이트를 북마크 한 후, 그 사이트를 직접 방문하지만 해당 사이트가 자체 서명된 인증서를 사용하여 시작된다면, 유저 에이전트는 페이지가 암호화 되지 않은 것 처럼 단순하게 동작하는 대신, 중간자(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)에 대한 키워드와 상태를 나열합니다 — 왼쪽 열의 키워드는 키워드와 동일한 행의 두 번째 열의 셀에 있는 상태에 매핑됩니다.

키워드 상태 간단한 설명
anonymous 익명 요소(element)에 대한 요청은 "cors"로 설정 된 모드와 "same-origin"으로 설정 된 자격 증명 모드를 가질 것입니다.
use-credentials 자격 증명 사용 요소(element)에 대한 요청은 "cors"로 설정 된 모드와 "include"로 설정 된 자격 증명 모드를 가질 것입니다.

빈 문자열은 유효한 키워드이고 익명 상태에 매핑됩니다. 속성(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)이 부동 소수점 수 유형(doubleunrestricted double)을 가진다면, 가져올 때, 콘텐트 속성(attribute)은 부동소수점 수 값 해석에 대한 규칙에 따라 해석되어야 하고 그것이 성공한다면, 결과 값이 반환되어야(must) 합니다. 반면에, 그것이 실패 혹은 속성(attribute)이 존재하지 않는다면, 기본 값이 대신 반환되어야(must) 하거나, 기본 값이 없으면 0.0이 반환되어야(must) 합니다. 설정할 때, 주어진 값은 부동 소수점 수의 가장 좋은 표현으로 변환되어야(must)하고 그 문자열은 새로운 콘텐트 속성(attribute) 값으로 사용되어야(must) 합니다.

반영하는 IDL 속성(attribute)이 0보다 큰 수로 제한된 부동 소수점 수 유형(doubleunrestricted 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. 컬렉션

HTMLFormControlsCollectionHTMLOptionsCollection 인터페이스들은 HTMLCollection 인터페이스로부터 유래된 컬렉션입니다. 하지만 HTMLAllCollectionHTMLCollection으로부터 상속하기에 바람직하지 않은 다양한 기이한 특징을 가지기 때문에 독립적입니다.

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에 대한 이름을 제공합니다. 비슷하게, iframename, objectname, metaname, mapname, formname 속성(attribute)의 값은 각 요소(element)에 대한 이름을 제공합니다. 언급된 요소(element)들만이 이 메서드의 목적을 위한 name을 가집니다.

객체의 지원되는 속성(property) 인덱스HTMLCollection 객체에 대해 정의된 것과 같습니다.

지원되는 속성(property) 이름트리 순서에 따라, 이후 중복된 것을 무시하여, idname를 모두 제공한다면, 요소(element)의 name에 앞선 id를 가지고 컬렉션에 의해 나타나는 모든 요소(element)들의 모든 idname 속성(attribute)의 비어 있지 않은 값으로 구성됩니다. idname이 모두 있을 경우, 이것들은 서로 다른 것이며 앞선 엔트리의 복제 역시 아닙니다.

가져올 때, 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)을 가져온 결과를 반환합니다.

다음 요소(element)들은 이름이 붙은 모든 요소(element)들로 간주됩니다: a, applet, button, embed, form, frame, frameset, iframe, img, input, map, meta, object, select, textarea.

인덱스 index가 주어진 HTMLAllCollection collection으로부터 "인덱싱 된 모든 요소(element)를 얻기 위해, collection내 인덱스 index를 가진 요소(element)를 반환하거나, index에 그러한 요소(element) 가 없다면 null을 반환합니다.

이름 name이 주어진 HTMLAllCollection collection으로부터 이름이 붙은 모든 요소(element) 혹은 요소들(elements)를 얻기 위해, 다음 알고리즘을 수행합니다.

  1. name이 빈 문자열이라면, null을 반환합니다.

  2. subCollection를 필터가 다음 중 하나의 요소(element)에만 일치되는, collection과 동일한 Document에 뿌리를 둔 HTMLCollection 객체로 둡니다:

  3. subCollection에 정확히 한 개 요소(element)가 존재한다면, 그 요소(element)를 반환합니다.

  4. 그렇지 않고, subCollection이 비어있다면, null을 반환합니다.

  5. 그렇지 않으면, subCollection를 반환합니다.

2.7.2.2. HTMLFormControlsCollection 인터페이스

HTMLFormControlsCollection 인터페이스는 form 요소에 나열 된 요소(element)들컬렉션으로 사용됩니다.

interface HTMLFormControlsCollection : HTMLCollection {
  // inherits length and item()
  getter (RadioNodeList or Element)? namedItem(DOMString name); // shadows inherited namedItem()
};
interface RadioNodeList : NodeList {
  attribute DOMString value;
};
collection . length
컬렉션 내 요소(element)들의 수를 반환합니다.
element = collection . item(index)
element = collection[index]
컬렉션으로부터 인덱스 index를 가진 항목을 반환합니다. 항목들은 트리 순서에 따라 정렬됩니다.
element = collection . namedItem(name)
radioNodeList = collection . namedItem(name)
element = collection[name]
radioNodeList = collection[name]
컬렉션으로부터 IDname name을 가진 항목을 반환합니다.

여러 개의 일치하는 항목이 존재한다면, 이 요소(element)들을 모두 포함하는 RadioNodeList 객체가 반환됩니다.

radioNodeList . value [ = value ]
객체에 의해 나타난 첫 번째 체크된 라디오 버튼의 값을 반환합니다.

객체에 의해 나타난 주어진 값을 가진 첫 번째 라디오 버튼을 체크하기 위해, 설정될 수 있습니다.

객체의 지원되는 속성(property) 인덱스HTMLCollection 객체에 대해 정의된 것과 같습니다.

지원되는 속성(property) 이름들트리 순서에 따라, 이후 중복을 무시하고, idname 모두를 제공한다면 요소(element)의 name에 앞서 id를 가지고, 컬렉션에 의해 나타나는 모든 요소(element)들의 모든 idname 속성(attribute)의 비어있지 않은 값으로 구성됩니다. idname은 서로 다르고, 앞선 엔트리의 복제 역시 아닙니다.

이 방법으로 노출된 속성들은 열거되어야(must) 합니다..

namedItem(name) 메서드는 다음 알고리즘을 따라 수행해야(must) 합니다:

  1. name이 빈 문자열이라면, null을 반환하고 알고리즘을 멈춥니다.

  2. 메서드가 호출되는 시점에 컬렉션에 name과 동일한 id 속성(attribute)이나 name 속성(attribute)을 가지는 정확히 한 개 노드가 존재한다면 그 노드를 반환하고 알고리즘을 멈춥니다.

  3. 그렇지 않고, 컬렉션에 name과 동일한 id 속성(attribute)이나 name 속성을 가지는 노드가 존재하지 않는다면 null을 반환하고 알고리즘을 멉춥니다.

  4. 그렇지 않으면, RadioNodeList 객체의 노드들만이 name과 동일한 id 속성(attribute)이나 name 속성(attribute)을 가지는 HTMLFormControlsCollection 객체이기 때문에 좀 더 걸러진, HTMLFormControlsCollection 객체의 존속되는 뷰를 나타내는 새로운 RadioNodeList 객체를 생성합니다. RadioNodeList 객체의 노드들은 트리 순서에 따라 정렬되어야(must) 합니다.

  5. RadioNodeList 객체를 반환합니다.


NodeList 인터페이스에서 상속된 RadioNodeList 인터페이스의 멤버들은 NodeList 객체에서와 같이 행동해야(must) 합니다.

RadioNodeList 객체의 value IDL 속성(attribute)은, 가져올 때, 다음 단계들을 수행하여 반환되는 값을 반환해야(must) 합니다.

  1. element트리 순서에 따라, type 속성(attribute)이 라디오 버튼 상태이고 체크 상태가 true인 input요소(element)인 RadioNodeList 객체에 의해 나타나는 첫 번째 요소로 둡니다. 그렇지 않으면, null로 둡니다.

  2. element가 null이라면, 빈 문자열을 반환합니다.

  3. elementvalue 속성(attribute)이 없는 요소(element)라면, "on" 문자열을 반환합니다.

  4. 그렇지 않으면, elementvalue 속성(attribute)의 값을 반환합니다.

설정할 때, value IDL 속성(attribute)은 다음 단계들을 수행해야(must) 합니다:

  1. 새로운 값이 문자열 "on"이라면 : element트리 순서에 따라, 라디오 버튼 상태인 type 속성(attribute)과 value 콘텐트 속성이 없거나 혹은 존재하면서 새로운 값과 동일한 input 요소(element)인 RadioNodeList 객체에 의해 나타난 첫 번째 요소(element)로 둡니다. 그러한 요소(element)가 존재하지 않는다면, 대신 element를 null로 둡니다.

    그렇지 않으면, element트리 순서에 따라, type 속성(attribute)이 라디오 버튼 상태이고 value 콘텐트 속성(attribute)이 존재하면서 새로운 값과 동일한 input 요소(element)인 RadioNodeList 객체에 의해 나타난 첫 번째 요소(element)로 둡니다. 그러한 요소(element)가 존재하지 않으면, 대신 element를 null로 둡니다.

  2. element가 null이 아니라면, 그 요소(element)의 체크 상태를 true로 둡니다

2.7.2.3. HTMLOptionsCollection 인터페이스

HTMLOptionsCollection 인터페이스는 option 요소(element)들의 컬렉션으로 사용됩니다. 그것은 항상 select 요소(element)에 뿌리를 두고 요소(element)의 후손을 조작하는 속성(attribute)들과 메서드들을 가집니다.

interface HTMLOptionsCollection : HTMLCollection {
  // inherits item(), namedItem()
  attribute unsigned long length; // shadows inherited length
  setter void (unsigned long index, HTMLOptionElement? option);
  void add((HTMLOptionElement or HTMLOptGroupElement) element, optional (HTMLElement or long)? before = null);
  void remove(long index);
  attribute long selectedIndex;
};
collection . length [ = value ]
컬렉션 내 요소(element)들의 수를 반환합니다.

더 적은 수로 설정하는 경우, 해당하는 컨테이너에서 option 요소(element)의 수를 잘라냅니다.

더 큰 수로 설정하는 경우, 그 컨테이너에 새로운 빈 option 요소(element)들을 추가합니다.

element = collection . item(index)
element = collection[index]
컬렉션에서부터 인덱스 index를 가진 항목을 반환합니다. 항목들은 트리 순서에 따라 정렬됩니다.
collection[index] = element
index가 컬렉션 내 항목들의 수보다 큰 경우, 해당하는 컨테이너에 새로운 빈 option 요소(element)들을 추가합니다.

null로 설정하는 경우, 컬렉션으로부터 인덱스 index에 있는 항목을 제거합니다.

option 요소(element)로 설정하는 경우, 컬렉션으로부터 인덱스 index에 있는 항목을 교체하거나 추가합니다.

element = collection . namedItem(name)
element = collection[name]
컬렉션으로부터 ID 혹은 name name을 가진 항목을 반환합니다.

일치하는 항목이 여러 개가 존재한다면, 첫 번째 것이 반환됩니다.

collection . add(element [, before ] )
before에 의해 주어진 노드 앞에 element를 삽입합니다.

before 인수는 번호가 될 수 있고, 이 경우 element는 그 숫자를 가진 항목 앞에 삽입되거나, 컬렉션의 요소(element)가 되는 경우에는, element는 그 요소 앞에 삽입됩니다.

before가 생략, 또는 null, 또는 범위 밖의 숫자라면, element는 목록의 끝에 삽입될 것입니다.

이 메서드는 element가 삽입될 요소(element)의 조상인 경우 HierarchyRequestError 예외를 던질 것입니다.

collection . remove(index)
컬렉션으로부터 인덱스 index를 가진 항목을 제거합니다.
collection . selectedIndex [ = value ]
첫 번째 선택된 항목이 있다면 그것의 인덱스를 반환하고, 선택된 항목이 없다면 -1을 반환합니다.

선택을 변경하기 위해, 설정될 수 있습니다.

객체의 지원되는 속성(property) 인덱스들HTMLCollection 객체에 대해 정의된 것과 같습니다.

가져올 때, length 속성(attribute)은 컬렉션에 의해 나타나는 노드들의 수를 반환해야(must) 합니다.

설정할 때, 행동은 새로운 값이 그 시간에 컬렉션에 의해 나타나는 노드들의 수와 같거나, 크거나, 작으냐에 따라 다릅니다. 숫자가 같다면, 속성(attribtue)을 설정하는 것은 아무 것도 하지 않아야(must)합니다. 새로운 값이 크다면, 속성(attribute)이 없고 자식 노드가 없는 n개의 새로운 option 요소(element)들은 HTMLOptionsCollection가 뿌리를 둔 select 요소(element)에 삽입되어야(must) 하고, 여기서 n은 두 수의 차이 (새로운 값에서 이전 값을 뺀) 입니다. 변경 이벤트는 새로운 option 요소(element)를 포함하는 DocumentFragment가 삽입된 것 처럼 발생되어야(must) 합니다. 새로운 값이 더 낮으면, 컬렉션의 마지막 n개 노드들은 그들의 부모 노드로부터 제거되어야(must)하고, 여기서 n은 두 수의 차이(이전 값에서 새로운 값을 뺀)입니다.

length를 설정하는 것은 어떤 optgroup 요소(element)들도 제거하거나 추가하지 않고, 새로운 자식을 기존의 optgroup 요소(element)들에 추가하지 않습니다(그것들로 부터 자식을 제거 할 수는 있지만).

지원되는 속성(property) 이름트리 순서에 따라, 이후 중복된 것을 무시하여, idname을 모두 제공한다면, 요소(element)의 name에 앞선 id를 가지고 컬렉션에 의해 나타나는 모든 요소(element)의 모든 idname 속성(attribute)들의 비어있지 않은 값으로 구성됩니다. idname이 모두 있을 경우, 이것들은 서로 다른 것이며 앞선 엔트리의 복제 역시 아닙니다.

이 방법으로 노출된 속성(property)들은 열거 되어야(must) 합니다.

유저 에이전트가 주어진 속성(property) 인덱스 index에 대한 새로운 인덱싱 된 속성(property)의 값 혹은 기존의 인덱싱된 속성(property)의 값의 설정을 새로운 값 value으로 하는 경우, 다음 알고리즘을 수행해야(must) 합니다:

  1. value가 null이라면, 인자로 index를 가진 remove 메서드에 대한 단계를 호출하고, 이 단계들을 중단합니다.

  2. length컬렉션에 의해 나타나는 노드의 수로 둡니다.

  3. nindex에서 length를 뺀 값으로 둡니다.

  4. n이 0보다 크다면, HTMLOptionsCollection에 뿌리를 둔 select 요소(element)에 속성(attribute)이 없고 자식 도느가 없는 새로운 n-1 option 개 요소(element)들로 구성된 DocumentFragment추가(append)합니다.

  5. n이 0 이상이라면, valueselect 요소(element)에 추가(append)합니다. 그렇지 않으면, 컬렉션의 index째 요소(element)를 value바꿉니다.

add(element, before) must act according 메서드는 다음 알고리즘을 따라 동작해야(must)합니다:

  1. elementHTMLOptionsCollection에 뿌리를 둔 select 요소(element)의 조상이라면, HierarchyRequestError 예외를 던지고 이 단계들을 중단합니다..

  2. before가 요소(element)이고 그 요소(element)가 HTMLOptionsCollection에 뿌리를 둔 select 그 요소(element)의 후손이 아니라면, NotFoundError 예외를 던지고 이 단계들을 중단합니다.

  3. elementbefore가 동일한 요소(element)라면, 반환하고 이 단계들을 중단합니다.

  4. before가 노드라면reference를 그 노드로 둡니다. 그렇지 않고, before가 정수이고, 컬렉션에 before 번째 노드가 있다면, reference를 그 노드로 둡니다. 그렇지 않으면, reference를 null로 둡니다.

  5. reference가 null이 아니라면, parentreference의 부모 노드로 둡니다. 그렇지 않으면, parentHTMLOptionsCollection에 뿌리를 둔 select 요소(element)로 둡니다.

  6. 첫 번째 인자로 element와 두 번째 인자로 reference를 가지고 parent 노드에서 DOM insertBefore() 메서드가 동작된 것 처럼 동작시킵니다.

remove(index) 메서드는 다음 알고리즘을 따라 동작해야(must) 합니다:

  1. 컬렉션에 의해 나타나는 노드의 수가 0이라면, 이 단계들을 중단합니다.

  2. index가 0 이상이고 컬렉션에 의해 나타나는 노드의 수보다 작은 수가 아니라면, 이 단계들을 중단합니다.

  3. element를 컬렉션의 index 번째 요소(element)로 둡니다.

  4. 부모 노드로부터 element를 제거합니다.

selectedIndex IDL 속성(attribute)은 HTMLOptionsCollection에 뿌리를 둔 select 요소(element)에서 동일하게 이름이 붙은 속성(attribute)처럼 동작해야(must) 합니다.

2.7.3. DOMStringMap 인터페이스

DOMStringMap 인터페이스는 이름-값 쌍의 세트를 나타냅니다. 이것은 속성(property) 접근을 위한 스크립팅 언어의 네이티브 메커니즘을 사용하여 이것들을 노출합니다.

DOMStringMap 객체가 인스턴스화 되는 경우, 이름-값 쌍의 목록을 가져오는 것, 이름을 특정 값으로 설정 하는 것, 이름을 삭제하는 것, 3가지 알고리즘과 연관되어집니다.

[OverrideBuiltins]
interface DOMStringMap {
  getter DOMString (DOMString name);
  setter void (DOMString name, DOMString value);
  deleter void (DOMString name);
};

임의의 인스턴스에 DOMStringMap 객체에서 지원되는 속성(property) 이름은 반환되는 순서에 따라, 그 인스턴스에서 이름-값 쌍의 목록을 가져오는 알고리즘으로부터 반환된 각 쌍의 이름입니다.

DOMStringMap에서 명명된 속성(property) name의 값을 결정하기 위해, 유저 에이전트는 이름-값 쌍의 목록을 가져오는 알고리즘에 의해 반환된 목록에서 이름 컴포넌트가 name인 이름-값 쌍의 값 컴포넌트를 반환해야(must) 합니다.

명명된 속성(property) name의 값을 value 값으로 설정하기 위해, 이름을 특정한 값으로 설정하는 알고리즘은, 이름으로 name를 그리고 값으로 value를 전달하여 수행해야(must) 합니다.

기존의 명명된 속성(property) name을 삭제하기 위해, 이름을 삭제하는 알고리즘은 이름으로 name을 전달하여 수행해야(must) 합니다.

여기 DOMStringMap 인터페이스 정의는 자바스크립트 환경에 대해서만 의도되었습니다. 다른 언어 바인딩은 DOMStringMap이 그 언어들에 대해 구현되는 방법을 정의할 필요가 있을 것입니다.

요소(element)의 dataset 속성(attribute)은 요소(element)의 data-* 속성(attribute)을 노출합니다.

유사한 구조를 가진 다음 코드 조각과 요소(element)를 고려해 볼 때:

<img class="tower" id="tower5" data-x="12" data-y="5" data-ai="robotarget" data-hp="46" data-ability="flames" src="towers/rocket.png" alt="Rocket Tower">

...하나는 일부 인수를 취하는 함수 splashDamage()를 상상해 볼 수 있고, 첫 번째 인수는 처리할 요소(element)입니다:

function splashDamage(node, x, y, damage) {
  if (node.classList.contains('tower') && // checking the 'class' attribute
      node.dataset.x == x && // reading the 'data-x' attribute
      node.dataset.y == y) { // reading the 'data-y' attribute
    var hp = parseInt(node.dataset.hp); // reading the 'data-hp' attribute
    hp = hp - damage;
    if (hp < 0) {
      hp = 0;
      node.dataset.ai = 'dead'; // setting the 'data-ai' attribute
      delete node.dataset.ability; // removing the 'data-ability' attribute
    }
    node.dataset.hp = hp; // setting the 'data-hp' attribute
  }
}

2.7.4. DOMElementMap 인터페이스

DOMElementMap 인터페이스는 이름-요소(elememt) 매핑 세트를 나타냅니다. 이것은 속성(property) 접근을 위한 스크립팅 언어의 네이티브 메커니즘을 사용하여 이것들을 노출합니다.

DOMElementMap 객체가 인스턴스화 되는 경우, 이름-요소(element) 매핑 목록을 가져오는 것, 이름을 특정 요소(element)에 매핑하는 것, 이름으로 매핑을 삭제하는 것, 3가지 알고리즘과 연관되어집니다.

interface DOMElementMap {
  getter Element (DOMString name);
  setter creator void (DOMString name, Element value);
  deleter void (DOMString name);
};

임의의 인스턴스에 DOMElementMap 객체에서 지원되는 속성(property) 이름은 반환되는 순서에 따라, 그 인스턴스에서 이름-요소(element) 매핑 목록을 가져오는 알고리즘으로부터 반환된 각 매핑에 대한 이름입니다.

DOMElementMap에서 명명된 속성(property) name의 값을 결정하기 위해, 유저 에이전트는 이름-요소(element)매핑 목록을 가져오는 알고리즘에 의해 반환된 목록에서 이름 컴포넌트가 name인 이름-요소(element) 매핑의 요소(element) 컴포넌트를 반환해야(must) 합니다.

새로운 혹은 기존의 명명된 속성(property) name의 값을 value 값으로 설정하기 위해, 이름을 특정 요소(element)에 매팽하기 위한 알고리즘은 이름을 name 요소(element)로 value를 전달하여 수행해야(must) 합니다.

기존의 명명된 속성(property) name을 삭제하기 위해, 매핑을 삭제하기 위한 알고리즘은 삭제될 매핑의 이름 컴포넌트로 name를 전달하여 수행해야(must) 합니다.

여기 DOMElementMap 인터페이스 정의는 자바스크립트 환경에 대해서만 의도되었습니다. 다른 언어 바인딩은 DOMElementMap이 그 언어들에 대해 구현되는 방법을 정의할 필요가 있을 것입니다.

2.7.5. 가비지 컬렉션

이미 존재하는 객체를 그 객체에 돌려주는 IDL 속성(attribute)로부터의 암묵적인 강한 참조가 있습니다.

예를 들어, Window 객체의 window.document 속성(attribute)은 Window 객체로부터 그것의 Document 객체로의 강한 참조가 있음을 의미합니다. 비슷하게, Document로부터 임의의 후손 노드로, 임의의 노드로부터 그 노드의 소유자 노드 문서로의 강한 참조가 항상 있습니다.

2.8. 네임스페이스

HTML 네임스페이스: http://www.w3.org/1999/xhtml

MathML 네임스페이스: http://www.w3.org/1998/Math/MathML

SVG 네임스페이스: http://www.w3.org/2000/svg

XLink 네임스페이스: http://www.w3.org/1999/xlink

XML 네임스페이스: http://www.w3.org/XML/1998/namespace

XMLNS 네임스페이스: http://www.w3.org/2000/xmlns/


스크립트를 수행하지 않고, CSS나 XPath 표현식을 평가하지 않고, 결과 DOM을 임의의 콘텐트에 노출시키지 않고 콘텐트에 연산을 수행하는 데이터 마이닝 툴과 다른 유저 에이전트는 실제로 상기 문자열을 노출하지 않고, 그들의 DOM 노드 아날로그가 특정 네임스페이스에 있다고 당연한 것으로 가정하여 "네임스페이스를 지원"할 수도 있습니다.


HTML 구문에서, 네임스페이스 접두어와 네임스페이스 선언은 XML에서와 동일한 효과를 가지지 않습니다. 예를 들어, 콜론은 HTML 요소(element) 이름에 특별한 의미(meaning)를 가지지 않습니다.

2.9. 구조화 된 데이터의 안전한 전달

이 명세는 자바스크립트 명세의 용어와 표기법을 사용합니다. [ECMA-262]

2.9.1. 복제 가능한 객체

복제 가능한 객체이벤트 반복 전반에 걸쳐 복제되는 것을 지원합니다. 즉, 다른 출처(origin)Document 전반을 포함하여 DocumentWorker 경계 전반에 걸쳐 복제되는 것을 지원합니다. 모든 객체가 복제 가능한 객체는 아니며 복제 가능한 객체의 모든 측면이 복제될 때 반드시 보존되는 것은 아닙니다.

플랫폼 객체는 다음의 내부 메서드를 가집니다:

[[Clone]] ( targetRealm, memory )

달리 지정하지 않는 한, [[Clone]] 내부 메서드를 호출하는 것은 "DataCloneError" DOMException을 던져야 합니다. (기본적으로, 플랫폼 객체복제 가능한 객체가 아닙니다.)

복제 가능한 객체플랫폼 객체는 일련의 단계들을 수행하도록 명시된 [[Clone]] 내부 메서드를 가집니다. 그 단계들을 수행한 결과는 targetRealm에 생성된, 던져진 예외나 this의 복제여야(must) 합니다. 그것들에 대해 복제가 의미하는 바를 정의하는 것은 그 객체들에 달려있습니다.

자바스크립트 명세에 정의된 객체들은 StructuredClone 추상 연산에 의해 직접 처리됩니다.

2.9.2. 전송 가능한 객체

전송 가능한 객체이벤트 반복 전반에 걸쳐 전송 되는 것을 지원합니다. 전송은 기본 데이터로의 참조를 공유하고 전송되는 객체를 분리하는 동안 효과적으로 객체를 다시 생성합니다. 이것은 비용이 많이 드는 리소스의 소유권을 전송하는데 유용합니다. 모든 객체가 전송 가능한 객체는 아니며 전송 가능한 객체의 모든 측면이 전송 될 때 반드시 보존되는 것은 아닙니다.

전송은 되돌릴 수 없고 비멱등 연산입니다. 일단 객체가 전송되면, 다시 전송되거나, 정말로 사용될 수 없습니다.

전송 가능한 객체플랫폼 객체는 [[Detached]] 내부 슬롯(slot)과 다음 내부 메서드를 가집니다:

[[Transfer]] ( targetRealm )

모든 플랫폼 객체가 [[Clone]] 내부 메서드를 가지는 반면, 모두가 [[Detached]] 내부 슬롯(slot)과 [[Transfer]] 내부 메서드를 가지지는 않습니다.

전송 가능한 객체플랫폼 객체는 반환 값과 함께 공유된 this의 기본 데이터를 가지고 targetRealm에서 생성된, 예외를 던지거나 this의 복제를 반환하는 [[Transfer]] 내부 메서드를 정의해야(must) 하고 this의 [[Detached]] 내부 슬롯 값을 true로 설정합니다. 그것들에 대해 전송이 의미하는 바를 정의하는 것은 그 객체들에 달려있습니다.

자바스크립트 명세에 정의된 객체는 StructuredCloneWithTransfer 추상 연산에 의해 직접 처리됩니다. (기술적으로, IsTransferableTransferHelper에 의해.)

2.9.3. StructuredCloneWithTransfer ( input, transferList, targetRealm )

  1. memory를 비어있는 맵으로 둡니다.

    메모리 맵의 목적은, 여기에서와 StructuredClone 추상 연산에서, 객체를 두 번 복제하는 것을 방지하는 것입니다. 이것은 주기와 그래프에서 중복 된 객체의 식별을 보존하게 합니다.

  2. transferList의 각 객체 transferable에 대해:

    1. IsTransferable(transferable) 가 false라면, "DataCloneError" DOMException를 던집니다.

    2. placeholder를 유저 에이전트 정의 플레이스홀더(user-agent-defined) 객체로 둡니다.

    3. transferable과 값 placeholder를 가지고 memory에 엔트리를 생성합니다.

  3. clone을 ? StructuredClone(input, targetRealm, memory)의 결과로 둡니다.

  4. outputTransferList을 새로운 비어있는 List로 둡니다.

  5. transferList 내 각 객체 transferable에 대해:

    1. placeholderResult를 키가 transferablememory 내 엔트리의 값으로 둡니다.

    2. transferResult를 ? TransferHelper(transferable, targetRealm)로 둡니다.

    3. clone 내에서, placeholderResult로의 참조를 transferResult로 교체하여, placeholderResult로의 참조를 보유하는 모든 것이 이제 transferResult로의 참조를 보유합니다.

      이것은 자바스크립트에 의해 정의된 프리미티브(primitive)에 대한 매우 드문 저수준(low-level) 연산입니다.

    4. outputTransferList의 마지막 요소(element)로 transferResult를 추가합니다.

  6. { [[Clone]]: clone, [[transferList]]: outputTransferList } 를 반환합니다.

본래 StructuredCloneWithTransfer 추상 연산은 "구조화된 복제" 알고리즘으로 알려져 있습니다. StructuredClone 추상 연산은 "내부 구조화된 복제" 알고리즘으로 알려져 있습니다. 현재 StructuredCloneWithTransfer 추상 연산에 의해 처리되는, 객체 전송은 Window 객체에서의 postMessage() 메서드와 MessagePort 객체에서의 Window/postMessage() 메서드의 알고리즘의 일부분에 의해 이전에 처리됩니다.

2.9.4. StructuredClone ( input, targetRealm [ , memory ] )

  1. memory가 제공되지 않았다면, memory를 비어있는 맵으로 둡니다.

  2. memory가 키 input를 가진 엔트리를 포함한다면, 엔트리의 값을 반환합니다.

  3. Type(input) 이 Undefined, Null, Boolean, String, Number라면, input을 반환합니다.

  4. Type(input) 이 Symbol이라면, "DataCloneError" DOMException를 던집니다.

  5. deepClone을 false로 둡니다.

  6. input이 [[BooleanData]] 내부 슬롯을 가진다면, output을 [[BooleanData]] 내부 슬롯 값이 input의 [[BooleanData]] 내부 슬롯 값인 targetRealm 내의 새로운 Boolean 객체로 둡니다.

  7. 그렇지 않고, input이 [[NumberData]] 내부 슬롯을 가진다면, output을 [NumberData]] 내부 슬롯 값이 input의 [[NumberData]] 내부 슬롯 값인 targetRealm 내의 새로운 Number 객체로 둡니다.

  8. 그렇지 않고, input이 [[StringData]] 내부 슬롯을 가진다면, output을 [[StringData]] 내부 슬롯 값이 input의 [[StringData]] 내부 슬롯 슬롯 값인 targetRealm 내의 새로운 String 객체로 둡니다.

  9. 그렇지 않고, input이 [[DateValue]] 내부 슬롯을 가진다면, output을 [[DateValue]] 내부 슬롯 값이 input의 [[DateValue]] 내부 슬롯 값인 targetRealm 내의 새로운 Date 객체로 둡니다.

  10. 그렇지 않고, input이 [[RegExpMatcher]] 내부 슬롯을 가진다면, output을 [[RegExpMatcher]] 내부 슬롯 값이 input의 [[RegExpMatcher]] 내부 슬롯 값이고 [[OriginalSource]] 내부 슬롯 값이 input의 [[OriginalSource]] 내부 슬롯 값이며 [[OriginalFlags]] 내부 슬롯 값이 input의 [[OriginalFlags]] 내부 슬롯 값인 targetRealm 내의 새로운 RegExp 객체로 둡니다.

  11. 그렇지 않고, input이 [[ArrayBufferData]] 내부 슬롯을 가진다면:

    1. IsDetachedBuffer(input)가 true라면, "DataCloneError" DOMException를 던집니다.

    2. outputArrayBuffertargetRealm 내의 %ArrayBuffer% 내장 객체로 둡니다.

    3. output을 ? CloneArrayBuffer(input, 0, outputArrayBuffer)로 둡니다.

  12. 그렇지 않고, input이 [[ViewedArrayBuffer]] 내부 슬롯을 가진다면:

    1. bufferinput의 [[ViewedArrayBuffer]] 내부 슬롯의 값으로 둡니다.

    2. bufferClone을 ? StructuredClone(buffer, targetRealm, memory)}}로 둡니다.

    3. input이 [[DataView]] 내부 슬롯을 가진다면, output을 [[DataView]] 내부 슬롯 값이 true이고, [[ViewedArrayBuffer]] 내부 슬롯 값이 bufferClone이고, [[ByteLength]] 내부 슬롯 값이 input의 [[ByteLength]] 내부 슬롯 값이며, [[ByteOffset]] 내부 슬롯 값이 input의 [[ByteOffset]] 내부 슬롯 값인 targetRealm 내의 새로운 DataView 객체로 둡니다.

    4. 그렇지 않으면

      1. Assert: input은 [[TypedArrayName]] 내부 슬롯을 가집니다.

      2. constructortargetRealminput의 [[TypedArrayName]] 내부 슬롯의 값에 대한 TypedArray 생성자 표의 열 1에 나열된 내부 객체로 둡니다.

      3. byteOffsetinput의 [[ByteOffset]] 내부 슬롯 값으로 둡니다.

      4. lengthinput의 [[ArrayLength]] 내부 슬롯 값으로 둡니다.

      5. output을? TypedArrayCreate(constructor, « bufferClone, byteOffset, length »)로 둡니다.

  13. 그렇지 않고, input이 [[MapData]] 내부 슬롯을 가진다면:

    1. output을 [[MapData]] 내부 슬롯 값이 새로운 비어있는 ListtargetRealm 내의 새로운 Map 객체로 둡니다.

    2. deepClone를 true로 설정합니다.

  14. 그렇지 않고, input이 [[SetData]] 내부 슬롯을 가진다면:

    1. output을 [[SetData]] 내부 슬롯 값이 새로운 비어있는 ListtargetRealm 내의 새로운 Set 객체로 둡니다.

    2. deepClone을 true로 둡니다.

  15. 그렇지 않고, input이 배열 외래(exotic) 객체 라면:

    1. inputLenOrdinaryGetOwnProperty(input, "length")로 둡니다.[[value]].

    2. outputPrototargetRealm%ArrayPrototype% 내장 객체로 둡니다.

    3. output을 ! ArrayCreate(inputLen, outputProto)로 둡니다.

    4. deepClone을 true로 둡니다.

  16. 그렇지 않고, input이 [[Clone]] 내부 메서드를 가진다면, output을 ? input로 둡니다. [[Clone]](targetRealm, memory).

  17. 그렇지 않고, IsCallable(input)}}이 true라면, "DataCloneError" DOMException을 던집니다.

  18. 그렇지 않고, input이 [[Prototype]]나 [[Extensible]] 외 다른 어떤 내부 슬롯을 가진다면 "DataCloneError" DOMException을 던집니다.

    예를 들어, [[PromiseState]]나 [[WeakMapData]] 내부 슬롯.

  19. 그렇지 않고, input이 외래(exotic) 객체라면, "DataCloneError" DOMException을 던집니다.

    예를 들어, 프록시(proxy) 객체.

  20. 그렇지 않으면:

    1. outputtargetRealm 내 새로운 객체로 둡니다.

    2. deepClone를 true로 둡니다.

  21. memory whose 키가 input이고 값이 outputmemory 내 엔트리를 생성합니다.

  22. deepClone이 true라면:

    1. input [[MapData]] 내부 슬롯이라면:

      1. inputListinput의 [[MapData]] 내부 슬롯의 값으로 둡니다.

      2. copiedList을 새로운 비어있는 List로 둡니다.

      3. inputList의 요소(element)인 각 Record { [[key]], [[value]] } entry에 대해 반복하여,

        1. copiedEntry을 새로운 Record { [[key]]: entry.[[key]], [[value]]: entry.[[value]] }로 둡니다.

        2. copiedEntry.[[key]] 가 비어있지 않다면, copiedList의 마지막 요소(element)로 copiedEntry를 추가(append)합니다.

      4. outputListoutput의 [[MapData]] 내부 슬롯의 값으로 둡니다.

      5. copiedList의 요소(element)인 각 Record { [[key]], [[value]] } entry에 대해 반복하여,

        1. outputKey를 ? StructuredClone(entry.[[key]], targetRealm, memory)로 둡니다.

        2. outputValue를 ? StructuredClone(entry.[[value]], targetRealm, memory)로 둡니다.

        3. outputList의 마지막 요소(element)로 { [[key]]: outputKey, [[value]]: outputValue }를 추가합니다.

    2. 그렇지 않고, input이 [[SetData]] 내부 슬롯을 가진다면:

      1. copiedListinput의 [[SetData]] 내부 슬롯의 값의 복제로 둡니다.

      2. outputListoutput의 [[SetData]] 내부 슬롯의 값으로 둡니다.

      3. 비어있지 않은 copiedList의 요소(element)인 각 entry에 대해,

        1. outputEntry을 ? StructuredClone(entry, targetRealm, memory)로 둡니다.

        2. outputList의 마지막 요소(element)로 outputEntry를 추가합니다.

    3. 그렇지 않으면:

      1. enumerableKeys를 새로운 비어있는 List로 둡니다.

      2. ! input.[[OwnPropertyKeys]]() 내 각 key 에 대해:

        1. Type(key)이 String이라면:

          1. inputDesc를 ! input.[[GetOwnProperty]](key)로 둡니다.

          2. inputDesc.[[Enumerable]]가 true라면, enumerableKeys의 마지막 요소(element)로 key를 추가합니다

      3. enumerableKeys 내 각 key에 대해:

        1. ! HasOwnProperty(input, key)가 true라면:

          1. inputValue를 ? input.[[Get]](key, input)로 둡니다.

          2. outputValue를 ? StructuredClone(inputValue, targetRealm, memory)로 둡니다.

          3. ? CreateDataProperty(output, key, outputValue)를 수행합니다.

  23. output을 반환합니다.

targetRealm이 다른 이벤트 반복에 있을 수 있고 StructuredCloneWithTransferStructuredClone을 호출하는 코드에 쉽게 접근할 수 없을 수 있기 때문에, 일반적인 구현에서는 targetRealm 내 객체의 생성을 구현하기 위해 일종의 직렬화와 정리하는 것을 사용하는 것이 필요할 것입니다.

2.9.5. IsTransferable ( O )

  1. Assert: Type(O)은 객체입니다.

  2. O가 [[ArrayBufferData]] 내부 슬롯을 가진다면:

    1. IsDetachedBuffer(O)가 true라면, false를 반환합니다.

    2. true를 반환합니다.

  3. 그렇지 않고, O가 [[Detached]] 내부 슬롯을 가진다면:

    1. O의 [[Detached]] 내부 슬롯 값이 true라면, false를 반환합니다.

    2. true를 반환합니다.

  4. false를 반환합니다.

2.9.6. TransferHelper ( input, targetRealm )

  1. input가 [[ArrayBufferData]] 내부 슬롯을 가진다면:

    1. output을 [[ArrayBufferByteLength]] 내부 슬롯 값이 input의 [[ArrayBufferByteLength]] 내부 슬롯 값이고 [[ArrayBufferData]] 내부 슬롯 값이 input의 [[ArrayBufferData]] 내부 슬롯 값인 targetRealm내의 새로운 ArrayBuffer 객체로 둡니다.

    2. ! DetachArrayBuffer(input)을 수행합니다.

    3. output을 반환합니다.

  2. ? input.[[Transfer]](targetRealm)를 반환합니다.

3. HTML 문서의 의미론, 구조, API

3.1. 문서

HTML 유저 에이전트에서 모든 XML과 HTML 문서는 Document 객체로 표현됩니다. [DOM]

문서의 주소Document와 연관된 URL입니다(DOM 표준에 정의된 대로). 그것은 Document가 생성될 때 초기에 설정되지만, Document의 수명 기간 동안 변경될 수 있습니다; 예를 들어, 사용자가 페이지의 문서 조각으로 이동할 때 그리고 pushState() 메서드가 새로운 URL을 가지고 호출 될 때 변경됩니다. [DOM]

대화형 유저 에이전트들은 보통 유저 인터페이스에 문서의 주소를 노출합니다. 이것은 사이트가 다른 사람으로 가장하려하는지를 사용자가 알 수 있는 주된 메커니즘입니다.

DocumentcreateDocument()createHTMLDocument() API를 사용하여 스크립트에 의해 생성되는 경우, 문서의 주소는 스크립트의 설정 객체에 의해 명시된 신뢰할 수 있는 문서문서의 주소와 동일하고, Document는 즉시 로딩 후 작업에 대해 준비되며 완전히 로드됩니다.

문서의 리퍼러Document가 생성될 때 설정될 수 있는 절대 URL입니다. 이것이 명시적으로 설정되지 않는다면, 그 값은 빈 문자열입니다.

Document 객체는 처음에는 설정되어 있지 않은 리로드 재정의 플래그를 가집니다. 이 플래그는 특정한 상황에서 document.open()document.write() 메서드에 의해 설정됩니다. 플래그가 설정 되는 경우, Document는 리로드 될 때 문서의 소스로 사용되는 유니코드 문자열인 리로드 재정의 버퍼를 가집니다.

유저 에이전트가 소스 브라우징 컨텍스트가 주어진, 재정의 된 리로드를 수행하려면, 다음과 같이 동작해야(must) 합니다:

  1. source브라우징 컨텍스트활성 문서리로드 재정의 버퍼의 값으로 둡니다.

  2. address브라우징 컨텍스트활성 문서URL로 둡니다.

  3. HTTPS state브라우징 컨텍스트활성 문서HTTPS 상태로 둡니다.

  4. CSP list브라우징 컨텍스트활성 문서CSP 목록으로 둡니다.

  5. 브라우징 컨텍스트예외 활성화 플래그교체 활성화를 가지고 bodysource이고, CSP 목록CSP list이고 HTTP 상태HTTPS state인 새로운 응답으로 이동합니다. 소스 브라우징 컨텍스트재정의 된 리로드 알고리즘에 주어진 것입니다. 이동 알고리즘이 이 목적을 위해 Document 객체를 생성할 경우, 그 Document리로드 재정의 플래그를 설정하고 그것의 리로드 재정의 버퍼source로 설정합니다. 모든 예외를 다시 던집니다.

    이동 알고리즘에서 문서의 주소를 설정할 때가 되면, 재정의 URLaddress를 사용합니다.

3.1.1. Document 객체

DOM 명세는 Document 인터페이스를 정의하고, 이 명세는 이를 크게 확장합니다:

enum DocumentReadyState { "loading", "interactive", "complete" };

[OverrideBuiltins]
partial /*sealed*/ interface Document {
  // resource metadata management
  [PutForwards=href, Unforgeable] readonly attribute Location? location;
  attribute DOMString domain;
  readonly attribute DOMString referrer;
  attribute DOMString cookie;
  readonly attribute DOMString lastModified;
  readonly attribute DocumentReadyState readyState;

  // DOM tree accessors
  getter object (DOMString name);
  attribute DOMString title;
  attribute DOMString dir;
  attribute HTMLElement? body;
  readonly attribute HTMLHeadElement? head;
  [SameObject] readonly attribute HTMLCollection images;
  [SameObject] readonly attribute HTMLCollection embeds;
  [SameObject] readonly attribute HTMLCollection plugins;
  [SameObject] readonly attribute HTMLCollection links;
  [SameObject] readonly attribute HTMLCollection forms;
  [SameObject] readonly attribute HTMLCollection scripts;
  NodeList getElementsByName(DOMString elementName);
  readonly attribute HTMLScriptElement? currentScript;

  // dynamic markup insertion
  Document open(optional DOMString type = "text/html", optional DOMString replace = "");
  WindowProxy open(DOMString url, DOMString name, DOMString features, optional boolean replace = false);
  void close();
  void write(DOMString... text);
  void writeln(DOMString... text);

  // user interaction
  readonly attribute WindowProxy? defaultView;
  readonly attribute Element? activeElement;
  boolean hasFocus();
  attribute DOMString designMode;
  boolean execCommand(DOMString commandId, optional boolean showUI = false, optional DOMString value = "");
  boolean queryCommandEnabled(DOMString commandId);
  boolean queryCommandIndeterm(DOMString commandId);
  boolean queryCommandState(DOMString commandId);
  boolean queryCommandSupported(DOMString commandId);
  DOMString queryCommandValue(DOMString commandId);

  // special event handler IDL attributes that only apply to Document objects
  [LenientThis] attribute EventHandler onreadystatechange;
};
Document implements GlobalEventHandlers;
Document implements DocumentAndElementEventHandlers;

Document는 초기에 "none"인 HTTP 상태 (HTTPS 상태 값)를 가지고, 이것은 Document의 데이터를 전달하는데 사용된 네트워크 채널의 보안 속성(property)들을 나타냅니다.

DocumentCSP 목록을 가지고, 이것은 이 컨텍스트에서 콘텐트 보안 정책의 목록입니다. 달리 명시되지 않는 한 목록은 비어있습니다.

3.1.2. 리소스 메타데이터 관리

document . referrer
사용자가 이 문서로 이동한 문서로부터, 차단되어 있거나 그러한 문서가 없지 않은 한, Document주소를 반환하고, 그러한 경우에는 빈 문자열을 반환합니다.

noreferrer 링크 유형은 리퍼러를 차단하는 데 사용될 수 있습니다.

referrer 속성(attribute)은 문서의 리퍼러를 반환해야(must) 합니다.

document . cookie [ = value ]
Document에 적용되는 HTTP 쿠키를 반환합니다. 쿠키가 없거나 이 리소스에 쿠키가 적용될 수 없다면, 빈 문자열이 반환 될 것입니다.

새로운 쿠키를 요소(element)의 HTTP 쿠키 세트에 추가하기 위해, 설정 될 수 있습니다.

콘텐츠가 고유 출처(origin)에 샌드박스 되었다면 (예를 들어, sandbox 속성(attribute)를 가진 iframe안에), 가져올 때와 설정할 때 "SecurityError" DOMException이 던져질 것입니다.

cookie 속성(attribute)은 문서 주소에 의해 식별되는 리소스의 쿠키를 나타냅니다.

다음 조건 중 하나로 분류되는 Document 객체는 쿠키를 거부하는 Document 객체입니다:

가져올 때, 문서가 쿠키를 거부하는 Document 객체라면, 유저 에이전트는 빈 문자열을 반환해야(must) 합니다. 그렇지 않고, Document출처(origin)불분명한 출처(origin)라면, 유저 에이전트는 "SecurityError" DOMException를 던져야(must) 합니다. 그렇지 않으면, 유저 에이전트는 "non-HTTP" API를 위해 BOM 없는 UTF-8 디코드를 사용하여 디코드 된 문서의 주소에 대한 쿠키 문자열을 반환해야(must) 합니다. [COOKIES] (이것은 지문 그림입니다.)

설정할 때, 문서가 쿠키를 거부하는 Document 객체라면, 유저 에이전트는 아무 것도 하지 않아야(must) 합니다. 그렇지 않고, Document출처(origin)불분명한 출처(origin)이라면, 유저 에이전트는 "SecurityError" DOMException를 던져야 합니다. 그렇지 않으면, 유저 에이전트는 UTF-8로 인코드 된 새로운 값으로 구성하여, "non-HTTP" API를 통해 문서의 주소에 대해 설정 쿠키 문자열을 받는 경우와 같이 동작해야(must) 합니다. [COOKIES] [ENCODING]

cookie 속성(attribute)은 프레임 전반에 접근이 가능하기 때문에, 쿠키에 대한 경로 제한은 사이트의 어느 부분으로 어떤 쿠키가 전송되는지를 관리하는데 도움이 되는 도구일 뿐이고, 어떤 방식으로든 보안 기능이 아닙니다.

cookie 속성(attribute)의 getter와 setter는 동기적으로 공유 된 상태에 접근합니다. 잠금 매커니즘이 없기 때문에, 다중 프로세스 유저 에이전트에서 다른 브라우징 컨텍스트는 스크립트가 수행되는 중에 쿠키를 수정할 수 있습니다. 예를 들어, 사이트는 쿠키 값을 읽고, 그 값을 증가시키고, 세션에 대한 고유 식별자로서 쿠키의 새로운 값을 사용하여, 다시 그것을 작성하는 것을 시도할 수 있습니다; 사이트가 동시에 두 개의 다른 브라우저에서 이것을 두 번 수행한다면, 잠재적으로 형편없는 영향을 가지고, 양쪽 세션에 대해 동일한 "고유" 식별자를 사용하게 됩니다.


document . lastModified
사용자의 로컬 표준 시간대에 따라, "MM/DD/YYYY hh:mm:ss" 형식으로 서버에 의해 보고 된 대로, 문서에 대한 마지막 수정한 날짜를 반환합니다.

마지막 수정 날짜가 알 수 없다면, 현재 시간이 대신 반환됩니다.

가져올 때, lastModified 속성(attribute)은 사용자의 로컬 표준 시간대에 따라 Document의 소스 파일의 마지막 수정 날짜와 시간을 다음 형식 에 따라 반환해야(must) 합니다:
  1. 날짜의 월 컴포넌트.

  2. U+002F 슬래쉬 문자 (/).

  3. 날짜의 일 컴포넌트.

  4. U+002F 슬래쉬 문자 (/).

  5. 날짜의 연 컴포넌트

  6. U+0020 공백 문자.

  7. 시간의 시 컴포넌트.

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

  9. 시간의 분 컴포넌트.

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

  11. 시간의 초 컴포넌트.

연도를 제외한, 위 모든 숫자 컴포넌트는 필요하다면 0을 채워, 10 진수 숫자를 나타내는 두 ASCII 숫자로 주어져야(must) 합니다. 연도는 필요하다면 0을 채워, 10 진수 숫자를 나타내는 4개 이상의 ASCII 숫자의 가능한 가장 짧은 문자열로 주어져야 합니다.

Document의 소스 파일의 마지막 수정 날짜와 시간은 사용된 네트워크 프로토콜의 관련 기능으로부터, 예를 들어, 문서의 HTTP Last-Modified 헤더의 값으로부터, 혹은 로컬 파일에 대한 파일 시스템 메타데이터로부터 얻어져야(must) 합니다. 마지막 수정 날짜와 시간을 알 수 없다면, 속성(attribute)은 위 형식에 따라 현재 날짜와 시간을 반환해야(must) 합니다.


document . readyState
Document가 로딩되는 동안 "loading"을, 일단 해석이 끝났으나 아직 서브-리소스를 로딩 중에는 "interactive"를, 로드가 완료되었다면 "complete"를 반환합니다.

이 값이 바뀔 경우 Document 객체에서 readystatechange 이벤트가 발생합니다.

각 문서는 현재 문서 준비상태를 가집니다. Document 객체가 생성될 때, 문서가 HTML 해석기, XML 해석기, 혹은 XSLT 처리기와 연관된다면 Document는 문자열 "loading"로, 그렇지 않으면 문자열 "complete"로 설정 된 그것의 현재 문서 준비상태를 가져야(must) 합니다. 페이지 로딩 동안 다양한 알고리즘은 이 값에 영향을 끼칩니다. 값이 설정된 경우, 유저 에이전트는 Document 객체에 readystatechange로 명명된 단순한 이벤트를 발생 시켜야(must) 합니다.

Document는 아직 멈추거나 중단 되지 않은 HTML 해석기XML 해석기와 연관된다면 활성화 해석기를 가진다고 합니다.

readyState IDL 속성(attribute)은 가져올 때, 현재 문서 준비상태를 반환해야(must) 합니다.

3.1.3. DOM 트리 접근자

문서의 html 요소(element)는 문서의 루트 요소(element)가 하나 존재하고 그것이 html 요소(element)라면 문서의 루트 요소(element)이고, 그렇지 않으면 null입니다.


document . head
head 요소(element)를 반환합니다.

문서의 head 요소(element)는 html 요소(element)의 자식인 첫 번째 head 요소(element)가 하나 존재한다면 문서의 head 요소(element)이고, 그렇지 않으면 null 입니다.

head 속성(attribute)은, 가져올 때, 문서의 must return head 요소(element) (head 요소(element)나 null)를 반환해야(must) 합니다.

document . title [ = value ]
HTML에 대해 title 요소(element)에 의해 주어진 대로, SVG에 대해 SVG title 요소(element)에 의해 주어진 대로, 문서의 제목을 반환합니다.

문서의 제목을 업데이트하기 위해, 설정될 수 있습니다. 업데이트를 위한 적절한 요소(element)가 없다면, 새로운 값은 무시됩니다.

문서의 title 요소(element)는 문서에 하나만 존재한다면 문서의 첫 번째 title 요소(element)이고 (트리 순서에 따라), 그렇지 않으면 null 입니다.

title 속성(attribute)은 가져올 때, 다음 알고리즘을 수행해야(must) 합니다:
  1. 루트 요소(element)SVG 네임스페이스에 있는 svg 요소(element)라면 value루트 요소(element)의 자식인 SVG 네임스페이스에 있는 첫 번째 title 요소(element)의 모든 자식 Text 노드의 데이터의 연결로 둡니다. [SVG11]

  2. 그렇지 않으면, value트리 순서에 따라 title 요소(element)의 모든 자식 Text 노드의 데이터의 연결로 두고, title 요소(element)가 null 이라면 빈 문자열로 둡니다.

  3. value에서 여백 문자를 들어내고 병합합니다.

  4. value를 반환합니다.

설정할 때, 다음 목록의 처음 일치하는 조건에 해당하는 단계를 수행해야(must) 합니다:

루트 요소(element)SVG 네임스페이스에 있는 svg 요소(element)라면 [SVG11]
  1. element루트 요소(element)의 자식인 SVG 네임스페이스에 있는 첫 번째 title 요소(element)가 있다면, 그것으로 둡니다. 그것이 없다면, SVG 네임스페이스title 요소(element)를 생성하고, 루트 요소(element)의 첫 번째 자식으로 추가하고, element를 그 요소(element)로 둡니다. [SVG11]

  2. elementtextContent IDL 속성(attribute)이 할당되는 새로운 값으로 설정된 것 처럼 동작합니다.

루트 요소(element)HTML 네임스페이스에 있다면
  1. title 요소(element)가 null이고 head 요소(element)가 null이라면, 이 단계들을 중단합니다.

  2. title 요소(element)가 null이라면, 새로운 title 요소(element)를 생성하고 head 요소(element)에 추가(append)하고, element를 새롭게 생성된 요소(element)로 둡니다; 그렇지 않으면, elementtitle 요소(element)로 둡니다.

  3. elementtextContent IDL 속성(attribute)이 할당되는 새로운 값으로 설정된 것 처럼 동작합니다.

그렇지 않으면
아무 것도 하지 않습니다.

document . body [ = value ]
body 요소(element)를 반환합니다.

body 요소(element)를 바꾸기 위해, 설정 될 수 있습니다.

새로운 값이 bodyframeset 요소(element)가 아니라면, 이것은 HierarchyRequestError 예외를 던질 것입니다.

문서의 body 요소(element)는 html 요소(element)의 첫 번째 자식인 body 요소(element)나 frameset 요소(element)입니다. 그러한 요소(element)가 없다면, null입니다.

body 속성(attribute)은 가져올 때, 문서의 body 요소(body 요소(element)나 frameset 요소(element)나 null)를 반환해야 합니다. 설정할 때, 다음 알고리즘을 수행해야 합니다:
  1. 새로운 값이 bodyframeset 요소(element)가 아니라면, HierarchyRequestError 예외를 던지고 이 단계들을 중단합니다.

  2. 그렇지 않고, 새로운 값이 body 요소(element)와 동일하다면, 아무것도 하지 않습니다. 이 단계들을 중단합니다.

  3. 그렇지 않고, body 요소(element)가 null이 아니라면, 루트 요소(element)의 replaceChild() 메서드가 그것의 두 인자로 각각 새로운 값과 기존 body 요소(element)를 가지고 호출된 것 처럼, 그 요소(element)를 DOM에 새로운 값으로 바꾸고, 이 단계들을 중단합니다.

  4. 그렇지 않고, 루트 요소(element)가 없다면, HierarchyRequestError 예외를 던지고 이 단계들을 중단합니다.

  5. 그렇지 않으면, body 요소(element)는 null이지만, 루트 요소(element)는 존재합니다. 루트 요소(element)에 새로운 값을 추가(append)합니다.


document . images
Document에 있는 img 요소(element)들의 HTMLCollection을 반환합니다.
document . embeds
document . plugins
Document에 있는 embed 요소(element)들의 HTMLCollection을 반환합니다.
document . links
Document에 있는 href 속성(attribute)을 가진 aarea 요소(element)들의 HTMLCollection을 반환합니다.
document . forms
Document에 있는 form 요소(element)들의 HTMLCollection을 반환합니다.
document . scripts
Document에 있는 script 요소(element)들의 HTMLCollection을 반환합니다.
images 속성(attribute)은 Document 노드에 뿌리를 둔 HTMLCollection을 반환해야(must) 하고, 이 속성(attribute)의 필터는 img 요소(element)들과만 일치합니다.

embeds 속성(attribute)은 Document 노드에 뿌리를 둔 HTMLCollection을 반환해야(must) 하고, 이 속성(attribute)의 필터는 embed 요소(element)들과만 일치합니다.

plugins 속성(attribute)은 embeds 속성(attribute)에 의해 반환된 것과 동일한 객체를 반환해야(must) 합니다.

links 속성(attribute)은 Document 노드에 뿌리를 둔 HTMLCollection을 반환해야(must) 하고, 이 속성(attribute)의 필터는 href 속성(attribute)을 가진 a 요소(element)들과 href 속성(attribute)을 가진 area 요소(element)들과만 일치합니다.

forms 속성(attribute)은 Document 노드에 뿌리를 둔 HTMLCollection을 반환해야(must) 하고, 이 속성(attribute)의 필터는 form 요소(element)들과만 일치합니다.

scripts 속성(attribute)은 Document 노드에 뿌리를 둔 HTMLCollection을 반환해야(must) 하고, 이 속성(attribute)의 필터는 script 요소(element)들과만 일치합니다.


collection = document . getElementsByName(name)
Document에 있는 값 name를 가진 name 속성(attribute)을 가진 요소(element)들의 NodeList를 반환합니다.
getElementsByName(name) 메서드는 문자열 name을 사용하고, 트리 순서에 따라, 그 문서 내의 값이 인자 name과 동일한 (대소문자 구분 방법으로) name 속성(attribute)를 가진 모든 html 요소(element)들을 포함하는 존속되는 NodeList를 반환해야(must) 합니다. 메서드가 Document 객체에서 동일한 인자를 가지고 다시 호출 되는 경우, 유저 에이전트는 이전 호출에 의해 반환된 객체와 동일한 객체를 반환할 수도 있습니다. 다른 경우에는 새로운 NodeList 객체가 반환되어야(must) 합니다.

document . currentScript
현재 실행중인 script 요소(element)를 반환합니다. 재진입 script 실행의 경우, 아직 실행을 완료하지 않은 스크립트 중에서 가장 최근에 실행이 시작된 스크립트를 반환합니다.

Document가 현재 script 요소(element)를 실행 중이 아니라면 (예를 들어, 수행 중인 스크립트가 이벤트 처리기나 타임 아웃되었기 때문에) null을 반환합니다.

currentScript 속성(attribute)은 가져올 때, 가장 최근에 초기화 된 값을 반환해야(must) 합니다. Document가 생성될 때, currentScript는 null로 초기화 되어야(must) 합니다.

Document 인터페이스는 명명된 속성(property)들을 지원합니다. 어느 순간에 지원되는 속성(property) 이름들Document 안에 있는 비어 있지 않은 name 콘텐트 속성(attribute)을 가진 모든 applet, 노출 된 embed, form, iframe, img, 노출된 object 요소(element)들의 name 콘텐트 속성(attribute)들의 값들과, Document 안에 있는 비어 있지 않은 id 콘텐트 속성(attribute)을 가진 모든 applet노출된 object 요소(element)들의 id 콘텐트 속성(attribute)들의 값들과, Document 안에 있는 비어 있지 않은 name 콘텐트 속성(attribute)과 비어있지 않은 id 콘텐트 속성(attribute)을 가진 모든 img 요소(element)들의 id 콘텐트 속성(attribute)들의 값들로 구성됩니다. 지원되는 속성(property) 이름들은 동일한 요소(element)가 id 속성(attribute)과 name 속성(attribute) 모두를 제공하는 경우 name 속성(attribute)으로부터의 값 앞에 오는 id 속성(attribute)의 값을 가지고, 나중의 중복을 무시하여, 트리 순서에 따라야(must) 합니다.

Document 객체가 속성(property) 검색(retrieval)을 위해 인덱싱 되는 경우 명명된 속성(property) name의 값을 결정하기 위해, 유저 에이전트는 다음 단계들을 사용하여 얻어진 값을 반환해야(must) 합니다:

  1. elementsDocument에 이름 name을 가진 명명된 요소(element)들의 목록으로 둡니다.

    명세에 의해, 적어도 하나의 그러한 요소(element)가 존재할 것입니다.

  2. elements가 하나의 요소(element)만을 가지고, 그 요소(element)가 iframe 요소(element)라면, 그 iframe 요소(element)에 의해 나타나는 중첩된 브라우징 컨텍스트WindowProxy 객체를 반환하고, 이 단계들을 중단합니다.

  3. 그렇지 않고, elements가 하나의 요소(element)만을 가진다면, 그 요소(element)를 반환하고, 이 단계들을 중단합니다.

  4. 그렇지 않으면 Document에 뿌리를 둔, 필터가 이름 name를 가진 명명된 요소(element)들에만 일치하는 HTMLCollection를 반환합니다.

위 알고리즘의 목적을 위해 이름 name을 가진 명명된 요소(element)들은 다음 중 하나입니다:

  • 값이 namename 콘텐트 속성(attribute)을 가지는 applet, 노출 된 embed, form, iframe, img, 노출 된 object 요소(element)들, 혹은,

  • 값이 nameid 콘텐트 속성(attribute)을 가지는 applet 또는 노출 된 object 요소(element)들

  • 값이 nameid 콘텐트 속성(attribute)을 가지고, 비어 있지 않은 name 콘텐트 속성(attribute)도 가지는 img 요소(element)들

embedobject 요소(element)는 노출 된 조상 object를 가지지 않고, object 요소(element)에 대해 추가적으로 요소의 폴백 콘텐트가 보이지 않거나 후손 objectembed를 가지지 않는다면 노출 되었다라고 합니다.


Document 인터페이스에서 dir 속성(attribute)은 dir 콘텐트 속성(attribute)과 함께 정의됩니다.

3.1.4. XML 문서 로딩

partial interface XMLDocument {
  boolean load(DOMString url);
};

load(url) 메서드는 다음 단계들을 수행해야(must) 합니다:

  1. document를 메서드가 호출되는 XMLDocument 객체로 둡니다.

  2. url을, relative to the 엔트리 설정 객체에 관련하여 해석합니다. 이것이 성공적이지 않다면, "SyntaxError" DOMException를 던지고 이 단계들을 중단합니다. 그렇지 않으면, urlRecord결과 URL 레코드로 둡니다.

  3. urlRecord출처(origin)document출처(origin)와 동일한 것이 아니라면, "SecurityError" DOMException를 던지고 이 단계들을 중단합니다.

  4. 어떤 변경 이벤트도 발생시키지 않고, document의 모든 자식 노드들을 제거합니다.

  5. document현재 문서 준비상태를 "loading" 으로 설정합니다.

  6. 병렬로 이 단계들의 나머지를 수행하고, 메서드로부터 true를 반환합니다.

  7. resultDocument 객체로 둡니다.

  8. success를 false로 둡니다.

  9. requestURLurlRecord이고 클라이언트엔트리 설정 객체이고, 목적지가 "subresource"이며, 동기 플래그가 설정되고, 모드가 "same-origin", 자격 증명 모드가 "same-origin"이고, URL 자격 증명 사용 플래그가 설정 된 새로운 요청으로 둡니다

  10. responserequest가져 온 결과로 둡니다.

  11. responseContent-Type 메타데이터XML MIME 타입이라면, 이 하위 단계들을 수행합니다:

    1. result 문서와 연관된 새로운 XML 해석기를 생성합니다.

    2. 이 해석기 response본문을 전달합니다.

    3. XML well-formedness나 XML 네임스페이스 well-formedness 오류가 있다면, result로부터 모든 자식 노드들을 제거합니다. 그렇지 않으면, success를 true로 둡니다.

  12. 다음 단계들을 수행하기 위한 작업을 대기열에 넣습니다.

    1. document현재 문서 준비상태를 "complete"로 설정합니다.

    2. 새로운 자식을 포함하는 DocumentFragment가 삽입 된 것처럼 변경 이벤트를 발생하여, document의 모든 자식을 result의 자식으로 바꿉니다 (그것이 자식을 가지지 않는다 하더라도).

    3. documentload라는 단순한 이벤트를 발생시킵니다.

3.2. 요소(element)

3.2.1. 의미론(semantic)

HTML에서 요소(element), 속성(attribute), 속성 값(attribute value)은 정의 된 (이 명세에 의해) 특정한 의미(semantic)을 가집니다. 예를 들어, ol 요소(element)는 순서가 있는 목록을 나타내고, lang 속성(attribute)은 콘텐트의 언어를 나타냅니다.

이 정의는 웹 브라우저와 검색 엔진 같은 HTML 처리기가 다른 컨텍스트에서 문서와 어플리케이션을 일관되게 표현하는 것을 허용합니다.

이 예제에서 HTML 제목(heading)은 데스크탑 브라우저에서 큰 텍스트로, 또는 모바일 브라우저에서 굵은 일반 사이즈 텍스트로 보여질 수 있습니다. 두 경우 모두에서 의미론적 정보는 모두 동일하게 남겨집니다 - h1h2 요소(element)들은 제목(heading)을 나타냅니다.
<!doctype html>
<html lang="en">
  <head>
    <title>Favorite books</title>
  </head>
      <body>
    <header>
      <img src="logo.png" alt="Favorite books logo">
    </header>
    <main>
      <h1>Favorite books</h1>
      <p>These are a few of my favorite books.</p>
      <h2>The Belgariad</h2>
      <p>Five books by David and Leigh Eddings.</p>
      <h2>The Hitchhiker’s Guide to the Galaxy</h2>
      <p>A trilogy of five books by Douglas Adams.</p>
    </main>
  </body>
</html>

이 의미론적 정보는 보조 기술에 있어 매우 중요합니다. 예를 들어, 스크린 리더(screen reader)는 브라우저에 의미론적 정보를 질의하고 음성 낭독으로 문서나 어플리케이션을 표시하기 위해 그 정보를 사용합니다.

어떤 경우에 보조 기술은 추가적인 기능을 제공하기 위해 의미론적인 정보를 사용합니다. 음성 인식 도구는 예를 들어 main 요소(element)의 시작 지점으로 초점을 이동하기 위한 음성 명령을 제공 할 수 있습니다.

적절한 HTML 요소(element)나 속성(attribute)가 사용되지 않는 경우, HTML 처리기에 가치 있는 의미론적 정보를 주지 않게 됩니다.

이 예제에서 스타일링은 제목(heading)과 다른 컴포넌트의 시각적 표현을 생성하는데 사용될 수 있지만, 적절한 HTML 요소(element)가 사용 되지 않았기 때문에 웹 브라우저, 검색 엔진, 보저 기술에 사용 가능한 의미론적 정보가 거의 존재하지 않습니다.
<!doctype html>
<html lang="en">
  <head>
    <title>Favorite books</title>
  </head>
        <body>
    <div class="header">
       <img src="logo.png" alt="Favorite books logo">
    </div>
    <div class="main">
       <span class="largeHeading">Favorite books</span>
       <p>These are a few of my favorite books.</p>
       <span class="smallHeading">The Belgariad</span>
       <p>Five books by David and Leigh Eddings.</p>
       <span class="smallHeading">The Hitchhiker’s Guide to the Galaxy</span>
       <p>A trilogy of five books by Douglas Adams.</p>
    </div>
  </body>
</html>

문서는 그것이 처리되는 동안 동적으로 변경될 수 있습니다. 스크립팅과 다른 메커니즘은 속성(tattribute) 값, 텍스트, 전체 문서 구조를 변경하는데 사용될 수 있습니다. 따라서 문서의 의미론은 특정 시점의 문서의 상태에 기반하지만, 외부 이벤트에 대한 응답으로 변경될 수도 있습니다. 유저 에이전트들은 이러한 변경을 반영하기 위해 문서의 표현을 업데이트 해야(must) 합니다.

이 예제에서 audio 요소(element)는 음악 트랙을 재생하는데 사용됩니다. controls 속성(attribute)은 유저 에이전트 플레이어를 보여주는데 사용되고, 음악이 재생하는 동안 진행을 나타내기 위해 컨트롤이 업데이트 됩니다. 사용 가능한 의미론적 정보는 이러한 변경에 대한 응답으로 업데이트 됩니다.
<audio src="comfortablynumb.mp3" controls>

3.2.2. DOM에서의 요소(Element)

DOM에서 html 요소(element)들을 나타내는 노드는 이 명세의 관련 명세에 그것들에 대해 나열된 인터페이스를 구현해야(must) 하고 스크립트에 노출해야(must) 합니다. 여기에는 문서가 다른 컨텍스트(예를 들어, XSLT 변환 내부)에 있는 문서라 하더라도, XML 문서들html 요소(element)들이 포함됩니다.

DOM의 요소(element)들은 상황(things)을 나타냅니다; 즉, DOM의 요소 (element)들은 의미론(semantic)으로 알려진, 고유한 의미(meaning)를 가집니다.

예를 들어, ol 요소(element)는 순서가 있는 목록을 나타냅니다.

모든 html 요소(element)들의 인터페이스가 상속 받 고, 추가적인 요구사항이 없는 요소(element)들을 사용해야(must) 하는 기본 인터페이스는 HTMLElement 인터페이스 입니다.

interface HTMLElement : Element {
  // metadata attributes
  attribute DOMString title;
  attribute DOMString lang;
  attribute boolean translate;
  attribute DOMString dir;
  [SameObject] readonly attribute DOMStringMap dataset;

  // user interaction
  attribute boolean hidden;
  void click();
  attribute long tabIndex;
  void focus();
  void blur();
  attribute DOMString accessKey;
  attribute boolean draggable;
  [PutForwards=value] readonly attribute DOMTokenList dropzone;
  attribute HTMLMenuElement? contextMenu;
  attribute boolean spellcheck;
  void forceSpellCheck();
};
HTMLElement implements GlobalEventHandlers;
HTMLElement implements DocumentAndElementEventHandlers;
HTMLElement implements ElementContentEditable;
interface HTMLUnknownElement : HTMLElement { };

HTMLElement 인터페이스는 다수의 상이한 기능과 관련된 메서드와 속성(attribtue)들을 보유하고, 따라서 이 인터페이스의 멤버들은 이 명세의 다양한 다른 섹션에서 설명됩니다.

HTMLUnknownElement 인터페이스는 이 명세(또는 다른 적용 가능한 명세)에 정의되지 않은 html 요소(element)들에 사용되어야(must) 합니다.

3.2.3. 요소(element) 정의

이 명세에서 각 요소(element)는 다음 정보를 포함하는 정의를 가집니다:

카테고리

요소(element)가 속하는 카테고리의 목록. 이것들은 각 요소(element)에 대해 콘텐트 모델을 정의할 때 사용됩니다.

이 요소(element)가 사용될 수 있는 컨텍스트

요소(element)가 사용될 수 있는 곳의 비 규범적 설명. 이 정보는 자식으로서 이것을 허용하는 요소의 콘텐트 모델과 중복되고, 편의상으로만 제공됩니다.

간결함을 위해, 가장 구체적인 예상되는 것들만 언급됩니다. 예를 들어, 흐름(flow) 콘텐트이면서 어구(phrasing) 콘텐트인 요소(element)는 어구(phrasing) 콘텐트가 예상되는 어느 곳에서나 사용될 수 있지만, 흐름(flow) 콘텐트가 예상되는 곳은 어구(phrasing) 콘텐트도 예상되기 때문에 (모든 어구(phrasing) 콘텐트흐름(flow) 콘텐트이기 때문에), "어구(phrasing) 콘텐트가 예상되는 곳"만 언급 될 것입니다.

콘텐트 모델

요소(element)의 자식과 후손으로 포함되어야(must) 하는 콘텐트의 규범적 설명.

text/html에서 태그 생략

text/html 구문에서, 시작 태그와 종료 태그가 생략될 수 있는지 여부의 비규범적 설명. 이 정보는 선택적 태그 섹션에 주어진 규범적인 요구 사항과 중복되고, 요소(element) 정의에 편의상으로만 제공됩니다.

콘텐트 속성(attribute)

요소(element)에 명시될 수 있는 속성(attribute)의 규범적 목록과 (달리 허용되지 않는 경우를 제외하고) 그 속성(attribute)들의 비 규범적인 설명. (대시의 왼쪽의 콘텐트는 규범적이고, 대시 오른쪽의 콘텐트는 규범적이지 않습니다.)

허용된 ARIA 역학(role) 속성(attribute)

요소에 명시될 수 있는 ARIA 역할(role) 속성(attribute) 값들의 규범적 목록(달리 허용되지 않는 경우를 제외하고). 각 값은 비 규범적 설명에 연결됩니다.

허용된 ARIA 상태(state)와 속성(property) 속성(attribute)들

범용 aria-* 속성(attribute) 목록과 허용된 역할(role), 상태(state), 속성(property) 표로의 링크

DOM 인터페이스

그 요소(element)가 구현해야(must)하는 DOM 인터페이스의 규범적 정의

이것은 요소가 작성자와 구현에 적용할 수 있는 추가적인 규범적 적합성 기준과 함께, 무엇을 나타내는지의 설명이 이후에 따라옵니다. 예제도 때때로 포함됩니다.

3.2.3.1. 속성(attribute)

달리 명시되지 않는 한, html 요소(element)들의 속성(attribute)은 빈 문자열을 포함하여 임의의 문자열 값을 가질 수 있습니다. 명시적으로 정해지지 않는 한, 그러한 속성(attribute)에 명시 될 수 있는 텍스트에 대한 제약 사항은 없습니다.

3.2.4. 콘텐트 모델(Content model)

이 명세에 정의된 각 요소(element)는 콘텐트 모델을 가집니다: 요소의 예상되는 콘텐츠의 설명. HTML 요소(element)는 요소(element)의 콘텐트 모델에 기술된 요구사항에 일치하는 콘텐트를 가져야(must) 합니다. 요소(element)의 콘텐트는 자식이 템플릿 콘텐트에 있는 template 요소(element)를 (요소가 생성될 때 요소에 대입되는 별도의 DocumentFragment) 제외하고, DOM에서 그것의 자식입니다.

공백 문자들은 항상 요소(element)들 사이에 허용됩니다. 유저 에이전트들은 소스 마크업에서 요소(element)들 사이의 이 문자들을 DOM 에서 Text 노드로 나타냅니다. 일련의 그 문자로만 구성되는 빈 Text 노드와 Text 노드는 요소(element) 간 여백으로 간주됩니다.

요소 간 여백, 주석 노드, 처리 지시 노드는 요소(element)의 콘텐트가 요소(element)의 콘텐트 모델과 일치하는지 아닌지의 여부가 수립 될 때 무시되어야(must) 하고, 문서와 요소(element) 의미론을 정의하는 알고리즘을 따를 때 무시되어야(must) 합니다.

따라서, A and B가 동일한 부모 노드를 가지고 둘 사이에 다른 요소(element) 노드나 Text 노드(요소(element) 간 여백 외)가 없다면 요소(element) A는 두 번째 요소(element) B보다 앞서거나 B가 뒤따른다고 합니다. 마찬가지로, 요소(element)가 요소(element) 간 여백, 주석 노드, 처리 지시 노드 외 다른 노드를 포함하지 않는다면 이 노드는 그 요소(element)의 유일한 자식입니다.

작성자는 html 요소(element)들을 각 요소(element)들에 대해 정의 된대로 혹은 다른 명세에 의해 명시적으로 요구 된 대로 그것들이 명시적으로 허용된 곳을 제외한 다른 어떤 곳에도 사용하지 않아야(must) 합니다. XML 복합 문서에 대해, 그 요소(element)들이 관련 컨텍스트를 제공하도록 정의되었다면, 이 상황들은 다른 네임스페이스의 내부 요소(element)가 될 수 있습니다.

예를 들어, 아톰(Atom) 명세는 content 요소(element)를 정의합니다. 그것의 type 속성(attribute)이 xhtml 값을 가지는 경우, 아톰(Atom) 명세는 단일 HTML div 요소(element)를 포함하도록 요구합니다. 따라서, div 요소(element)는 비록 이 명세에 의해 명시적으로 규범적으로 지정되지 않았지만 그 컨텍스트에서는 허용됩니다. [RFC4287]

추가적으로, html 요소(element)들은 고아 노드(즉, 부모 노드가 없는)가 될 수 있습니다.

예를 들어, td 요소(element)가 tr 요소(element) 내부에만 사용되도록 되어있다 하더라도, 스크립트에서 td 요소(element)를 생성하고 전역 변수에 저장하는 것은 적합합니다.
var data = {
  name: "Banana",
  cell: document.createElement('td'),
};
3.2.4.1. "없는(nothing)" 콘텐트 모델

요소(element)의 콘텐트 모델이 없는 경우, 요소(element)는 Text 노드 (요소(element)간 공백 외)와 요소(element) 노드를 포함하지 않아야(must) 합니다.

콘텐트 모델이 "없는" 대부분 HTML 요소(element)들은 편의상 텅 빈 요소(element) (HTML 문법에 따라 종료 태그를 가지지 않는 요소(element)). 하지만, 이것들은 완전히 분리된 개념입니다.

3.2.4.2. 콘텐트의 종류

HTML에서 각 요소(element)는 서로 유사한 특성을 가진 요소(element)를 분류한 0개 이상의 카테고리에 속합니다:

어떤 요소들은 이 명세에서 다른 부분에 정의된 다른 카테고리에도 해당됩니다.

이 카테고리들은 다음과 같이 관련됩니다:

섹션화(sectioning) 콘텐트, 제목(heading) 콘텐트, 어구(phrasing) 콘텐트, 삽입(embedded) 콘텐트, 대화형(interactive) 콘텐트는 흐름(flow) 콘텐트의 모든 유형입니다. 메타데이터는 때때로 흐름(flow) 콘텐트 입니다. 메타데이터와 대화형(interactive) 콘텐트는 때때로 어구(phrasing) 콘텐트 입니다. 삽입(embedded) 콘텐트는 또한 어구(phrasing) 콘텐트이 유형이고, 때때로 대화형(interactive) 콘텐트입니다.

다른 카테고리들은 특정 목적을 위해서도 사용됩니다, 예를 들어, 양식(form) 컨트롤들은 공통 요구사항을 정의하기 위해 여러 가지 카테고리를 사용하여 명시됩니다. 일부 요소(element)들은 고유의 요구사항을 가지고 특정 카테고리에 맞지 않습니다.

3.2.4.2.1. 메타데이터 콘텐트

메타데이터 콘텐트는 콘텐트 나머지의 표현이나 동작을 설정하거나, 다른 문서와 문서의 관계를 설정하거나, 다른 "대역 외" 정보를 전달하는 콘텐트 입니다.

3.2.4.2.2. 흐름(flow) 콘텐트

문서와 어플리케이션의 본문에 사용되는 대부분 요소(element)는 흐름(flow) 콘텐트로 분류됩니다.

3.2.4.2.3. 섹션화(sectioning) 콘텐트

섹션화(sectioning) 콘텐트제목(heading)바닥글(footer)들의 범위를 정의하는 콘텐트 입니다.

섹션화(sectioning) 콘텐트는 잠재적으로 제목(heading)과 개요(outline)를 가집니다. 더 자세한 내용을 위해 §4.3.10 제목(heading)들과 섹션들의 섹션을 참고하세요.

섹션화(sectioning) 루트인 특정 요소(element)들도 있습니다. 이것들은 섹션화(sectioning) 콘텐트와 구별되지만, 이들도 개요(outline)를 가질 수 있습니다.

3.2.4.2.4. 제목(heading) 콘텐트

제목(heading) 콘텐트는 (섹션화(sectioning) 콘텐트 요소(element)를 사용하여 명시적으로 마크업했거나, 제목(heading) 콘텐트 자체로 나타내어) 섹션의 헤더를 정의합니다.

3.2.4.2.5. 어구(phrasing) 콘텐트

어구(phrasing) 콘텐트는 문서의 텍스트 뿐만 아니라 문단 내부(intra-paragraph) 레벨에서 텍스트를 마크업 하는 요소(element) 입니다. 문단에서의 연속 된 어구(phrasing) 콘텐트.

어구(phrasing) 콘텐트로 분류된 대부분 요소(element)들은 흐름(flow) 콘텐트가 아닌 어구(phrasing) 컨텐트로 분류된 자기 자신인 요소(element)만을 포함 할 수 있습니다.

콘텐트 모델의 맥락에서 텍스트는 아무 것도 의미하지 않거나 Text 노드를 의미합니다. 텍스트는 때때로 그 자체로 콘텐트 모델로 사용되지만, 어구(phrasing) 콘텐트이기도 하며, 요소(element) 간 공백이 될 수 있습니다(Text 노드가 비어있거나 공백 문자들만을 포함한다면).

Text 노드와 속성(attribute) 값은 유니코드 문자들로 구성되어야(must) 하고, U+0000 문자는 포함하지 않아야(must) 하고, 영구적으로 정의되지 않은 유니코드 문자(비문자)를 포함하지 않아야(must) 하고, 공백 문자들제어 문자를 포함하지 않아야(must) 합니다.

이 명세는 정확한 컨텍스트에 따른 Text 노드의 정확한 값과 속성(attribtue) 값에 추가 제한 사항들을 포함합니다.

HTML에서 요소(element)들에 대해, 텍스트 콘텐트 모델의 제한 사항도 요소(element)의 종류에 따릅니다. 예를 들어, textarea 요소(element) 안에 "<"는 textarea이스케이프 될 수 있는 원시 텍스트 요소(element)이기 때문에 HTML에서 이스케이프 될 필요가 없습니다. (이것은 XHTML에 적용하지 않습니다. XHTML에서, 요소(element)의 종류콘텐트 모델: 텍스트의 제한 사항에 영향을 주지 않습니다.)

3.2.4.2.6. 삽입(embedded) 콘텐트

삽입(embedded) 콘텐트는 문서에 다른 리소스를 불러오는 콘텐트, 혹은 문서에 삽입 된 다른 표현 형식으로부터의 콘텐트 입니다.

HTML 네임스페이스와 다른 네임스페이스이고 콘텐트를 전달하지만 메타데이터는 전달하지 않는 요소(element)는 이 명세에 정의된 콘텐트 모델의 목적에 대한 삽입(embedded) 콘텐트 입니다. (예를 들어, MathML 혹은 SVG.)

일부 삽입(embedded) 콘텐트 요소(element)들은 폴백 콘텐트를 가질 수 있습니다: 외부 리소스가 사용될 수 없는 경우 (예를 들어, 지원되지 않는 형식의 콘텐트이기 때문에) 사용되는 콘텐트. 폴백이 있다면 요소(element) 정의는 폴백이 무엇인지 지정합니다.

3.2.4.2.7. 대화형(interactive) 콘텐트

대화형(interactive) 콘텐트는 유저 인터랙션을 위해 특별히 의도된 콘텐트 입니다.

tabindex 속성(attribute)은 모든 요소(element)를 대화형(interactive) 콘텐트로 만들 수 있습니다.

3.2.4.2.8. 분명한(palpable) 콘텐트

일반적인 규칙으로, 콘텐트 모델이 흐름(flow) 콘텐트어구(phrasing) 콘텐트를 허용하는 요소(element)는 분명한(palpable) 콘텐트이고 명시된 hidden 속성(attribute)을 가지지 않는 그것의 contents에 적어도 하나의 노드를 가져야(should) 합니다.

분명한(palpable) 콘텐트는 일부 비어 있지 않은 후손 텍스트를 제공하거나, 사용자가 들을 수 있거나(audio 요소(element)들) 볼 수 있거나 (videoimg 혹은 canvas 요소(element)들) 혹은 상호 작용 할 수 있는 (예를 들어, 대화형 양식(form) 컨트롤들) 것을 제공하여 요소를 비어 있지 않게 만듭니다.

하지만, 요소가 타당하게 비어 있을 수 있는 많은 경우, 예를 들어 스크립트에 의해 나중에 채워질 플레이스홀더로 사용되거나, 요소가 템플릿의 일부이고 일부 페이지에서는 아니지만 대다수 페이지에서 채워지는 경우가 있기 때문에 이 요구사항은 견고한 요구 사항이 아닙니다.

적합성 검사기는 작성 보조 도구로서, 작성자에게 이 요구 사항을 충족하는데 실패한 요소(element)들을 찾기 위한 메커니즘을 제공하도록 권장됩니다.

다음 요소(element)들은 분명한(palpable) 콘텐트입니다:

3.2.4.2.9. 스크립트 지원 요소(element)

스크립트 지원 요소(element)는 스스로 아무 것도 나타내지 않지만(즉, 렌더링 되지 않습니다), 스크립트를 지원하는데, 예를 들어 사용자를 위한 기능적 제공을 위해 사용됩니다.

다음 요소(element)들은 스크립트 지원 요소(element)들 입니다:

3.2.4.3. 투명 콘텐트 모델

일부 요소(element)들은 투명으로 기술됩니다; 그것들은 콘텐트 모델의 설명에 "투명"을 가집니다. 투명 요소(element)의 콘텐트 모델은 부모 요소의 콘텐트 모델에서 유래됩니다: "투명"인 콘텐트 모델의 부분에 요구되는 요소(element)들은 투명 요소(element)가 자신을 발견하는 투명 요소(element)의 부모 요소의 콘텐트 모델의 부분에 요구되는 것과 같은 요소(element)입니다.

예를 들어, ruby 요소(element) 안의 ins 요소(element)는, ins 요소(element)를 허용하는 ruby 요소(element)의 콘텐트 모델의 부분은 어구(phrasing) 콘텐트를 허용하는 부분이고, rt 요소(element)는 어구(phrasing) 콘텐트가 아니기 때문에, rt 요소(element)를 포함할 수 없습니다.

어떤 경우에, 투명 요소(element)가 서로 중첩되는 경우, 반복적으로 처리가 적용되어야(has to) 합니다.

다음 마크업 코드 조각을 고려해보세요:
<p><object><param><ins><map><a href="/">Apples</a></map></ins></object></p>

"Apples"가 a 요소(element) 안에 허용되는지를 확인하기 위해, 콘텐트 모델이 검사됩니다. a 요소(element)의 콘텐트 모델은 투명이고, map 요소(element)의 콘텐트 모델도, ins 요소(element)의 콘텐트 모델도, ins 요소(element)가 발견되는 object 요소의 부분도 마찬가지입니다. object 요소(element)는 콘텐트 모델이 어구(phrasing) 콘텐트p 요소(element) 안에서 발견되어집니다. 따라서, 텍스트는 어구(phrasing) 콘텐트이기 때문에, "Apples"는 허용됩니다.

투명 요소(element)가 부모가 없는 경우, "transparent"인 그것의 콘텐트 모델의 부분은 대신 모든 흐름(flow) 콘텐트를 허용하는 것으로 취급되어야(must) 합니다.

3.2.4.4. 문단(paragraphs)

이 섹션에 정의된 용어 문단p 요소(element)의 정의 이상으로 사용됩니다. 여기에 정의 된 문단 개념은 문서를 해석하는 방법을 기술하는데 사용됩니다. p 요소(element)는 문단을 마크업하는 몇 가지 방법 중 단지 한 가지일 뿐입니다.

문단은 일반적으로 타이포그라피에서와 같이, 특정 주제에 관해 논하는 하나 이상의 문장들을 가진 텍스트 블럭을 구성하거나, 좀 더 일반적인 주제 그룹에 사용될 수 있는 어구(phrasing) 콘텐트의 연속입니다. 예를 들어, 주소도 문단이고, 시(詩)의 양식의 일부나, 필자 이름을 적은 행, 혹은 연(聯)도 그러합니다.

다음 예제에서, 섹션에 두 개의 문단이 존재합니다. 문단이 아닌 어구(phrasing) 콘텐트를 포함하는 제목(heading)도 존재합니다. 주석과 요소(element) 간 여백이 문단을 구성하지 않는 방식에 주목하세요.
<section>
  <h2>Example of paragraphs</h2>
  This is the <em>first</em> paragraph in this example.
  <p>This is the second.</p>
  <!-- This is not a paragraph. -->
</section>

흐름(flow) 콘텐트 안의 문단은 문서가 문제를 복잡하게 만드는 a, ins, del, map 요소(element)들은 그들의 혼합 콘텐트 모델을 가지고 아래 처음 두 예제에서 보이는 것과 같이 문단 경계를 모호하게 할 수 있기 때문에, 이 요소(element)들이 없는 것 같이 보이는 것에 관련하여 정의됩니다.

일반적으로, 문단 경계를 모호하게 하는 요소(element)를 가지는 것을 방지하는 것이 가장 좋습니다. 그러한 마크업을 유지보수 하는 것은 어렵게 만들 수 있습니다.

다음 예제는 이전 예제에서 마크업을 가져와서 텍스트가 변경되었음을 나타내기 위해 (이 경우에서 이기는 하지만, 변경 사항은 확실히 말이 안 되기는 합니다) 일부 마크업 주변에 insdel 요소(element)를 넣습니다. 이 예제가 insdel 요소(element)에도 불구하고, 이전의 것과 정확히 동일한 문단을 가지는 방식에 주목하세요 — ins 요소(element)는 제목(heading)과 첫 번째 문단을 모호하게 하고, del 요소(element)는 두 문단 사이 경계를 모호하게 합니다.
<section>
  <ins><h1>Example of paragraphs</h1>
  This is the <em>first</em> paragraph in</ins> this example<del>.
  <p>This is the second.</p></del>
  <!-- This is not a paragraph. -->
</section>
view를 문서의 모든 a, ins, del, map 요소(element)를 그들의 콘텐츠로 바꾸는 DOM의 뷰로 둡니다. 그 후, view에서, 콘텐트의 다른 유형에 의해 연속 된 각 일련의 어구(phrasing) 콘텐트 형제 노드에 대해, 어구(phrasing) 콘텐트 뿐 아니라 어구(phrasing) 콘텐트 외 다른 콘텐트를 허용하는 요소(element) 내에서, first를 연속의 첫 번째 노드로 두고, last를 연속의 마지막 노드로 둡니다. 삽입(embedded) 콘텐트요소(element) 간 여백이 아닌 적어도 하나의 노드로 구성되는 그 각 연속에 대해, 문단은 first 바로 전부터 last 바로 이후까지 본래의 DOM에 존재합니다. (따라서 문단은 a, ins, del, map 요소(element)들 전반에 걸쳐질 수 있습니다.)

적합성 검사기는 서로 겹치는 문단을 가지는 경우의 작성자에게 경고할 수 있습니다 (이것은 object, video, audio, canvas 요소(element))들에 발생될 수 있고, HTML 안에 추가적으로 삽입되는 것을 허용하는 다른 네임스페이스에 있는 요소(element)들을, svg math 같은, 통해 간접적으로 발생될 수 있습니다).

문단은 또한 명식적으로 p 요소(element)에 의해 구성 될 수 있습니다.

p 요소(element)는 서로 문단을 구분하기 위한 어구(phrasing) 콘텐트외 다른 어떤 콘텐트도 존재하지 않을 경우 각각의 문단을 감싸는데 사용 될 수 있습니다.

다음 예제에서, 링크가 첫 번째 문단의 반, 두 번째 문단을 구분하는 제목(heading) 전부, 두 번째 문단의 반에 걸쳐 있습니다. 이는 문단과 헤딩을 모호하게 합니다.
<header>
  Welcome!
  <a href="about.html">
    This is home of...
    <h1>The Falcons!</h1>
    The Lockheed Martin multirole jet fighter aircraft!
  </a>
  This page discusses the F-16 Fighting Falcon’s innermost secrets.
</header>

여기, 이번에는 명시적으로 문단을 보여주고, 한 개 링크 요소(element)를 세개로 분할하여 이를 마크업하는 다른 방법이 있습니다:

<header>
  <p>Welcome! <a href="about.html">This is home of...</a></p>
  <h1><a href="about.html">The Falcons!</a></h1>
  <p><a href="about.html">The Lockheed Martin multirole jet
  fighter aircraft!</a> This page discusses the F-16 Fighting
  Falcon’s innermost secrets.</p>
</header>
폴백 콘텐트를 정의하는 특정 요소(element)를 사용하는 경우 문단이 중첩되는 것이 가능합니다. 예를 들어, 다음 섹션에서:
<section>
  <h2>My Cats</h2>
  You can play with my cat simulator.
  <object data="cats.sim">
    To see the cat simulator, use one of the following links:
    <ul>
      <li><a href="cats.sim">Download simulator file</a>
      <li><a href="https://sims.example.com/watch?v=LYds5xY4INU">Use online simulator</a>
    </ul>
    Alternatively, upgrade to the Mellblom Browser.
  </object>
  I’m quite proud of it.
</section>

다섯 개의 문단이 있습니다:

  1. objectobject 요소(element)인 "You can play with my cat simulator. object I’m quite proud of it." 라고 말하는 문단.

  2. "To see the cat simulator, use one of the following links:" 라고 말하는 문단.

  3. "Download simulator file" 라고 말하는 문단.

  4. "Use online simulator" 라고 말하는 문단.

  5. "Alternatively, upgrade to the Mellblom Browser." 라고 말하는 문단.

첫 번째 문단은 다른 네 개의 문단에 의해 중첩됩니다. "cats.sim" 리소스를 지원하는 유저 에이전트는 첫 번째 문단만을 보여줄 것이지만, 폴백 컨텐트를 보여주는 유저 에이전트는 혼란스럽게 첫 번째 문단의 첫 번째 문장을 두 번째 문장으로서 동일한 문단에 있었던 것 처럼 보여줄 것이고, 마지막 문단을 첫 번째 문단의 두 번째 문장의 시작에 있었던 것 처럼 보여줄 것입니다.

이 혼란을 방지하기 위해, 명시적인 p 요소(element)가 사용될 수 있습니다. 예를 들어:

<section>
  <h2>My Cats</h2>
  <p>You can play with my cat simulator.</p>
  <object data="cats.sim">
    <p>To see the cat simulator, use one of the following links:</p>
    <ul>
      <li><a href="cats.sim">Download simulator file</a>
      <li><a href="https://sims.example.com/watch?v=LYds5xY4INU">Use online simulator</a>
    </ul>
    <p>Alternatively, upgrade to the Mellblom Browser.</p>
  </object>
  <p>I’m quite proud of it.</p>
</section>

3.2.5. 범용 속성(attribute)

다음 속성(attribute)들은 모든 html 요소(element)들에 정의될 수 있습니다 (심지어 이 명세에 정의되어 있지 않더라도):

이 속성(attribute)들은 HTML 요소(element)들에 대한 속성(attribute)들로서 이 명세에 의해서만 정의됩니다. 이 명세가 이 속성(attribute)들을 가지는 요소(element)에 참조하는 경우, 이 속성(attribute)들을 가지는 것으로 정의되지 않은 네임스페이스의 요소(element)들은 이 속성(attribute)들을 가진 요소(element)들이 되는 것으로 간주되지 않아야(must) 합니다.
예를 들어, 다음 XML 코드 조각에서, "bogus" 요소(element)는 리터럴 이름 "dir"을 가진 속성(attribute)을 가짐에도 불구하고, 이 명세에 정의된 대로 dir 속성(attribute)을 가지지 않습니다. 따라서, 가장 안쪽 span 요소(element)의 방향성은 간접적으로 "bogus" 요소(element)를 통해 div 요소(element)로부터 상속 된, "rtl"입니다.
<div xmlns="https://www.w3.org/1999/xhtml" dir="rtl">
  <bogus xmlns="https://example.net/ns" dir="ltr">
    <span xmlns="https://www.w3.org/1999/xhtml">
    </span>
  </bogus>
</div>

보조 기술 제품이 HTML 요소(element)와 속성(attribute)으로 가능한 것보다 좀 더 세밀한 인터페이스를 노출할 수 있게 하기 위해, 보조 기술 제품을 위한 주석(annotation)의 세트가 명시될 수 있습니다 (ARIA rolearia-* 속성(attribute)들). [WAI-ARIA]


다음 이벤트 처리기 콘텐트 속성(attribute)들은 모든 HTML 요소(element)에 명시될 수 있습니다:

별표로 표기 된 속성(attribute)들은 body 요소(element)들에 명시되었을 경우 그 요소(element)들이 동일한 이름을 가지고 Window 객체의 이벤트 처리기를 노출하기 때문에 다른 의미(meaning)를 가집니다.

이 속성(attribute)들이 모든 요소(element)들에 적용되는데 반해, 그것들이 모든 요소(element)에 쓸모있는 것은 아닙니다. 예를 들어 미디어 요소(element)들만이 유저 에이전트에 의해 발생된 volumechange 이벤트를 받을 것입니다.


커스텀 데이터 속성(attribute)들은 (예를 들어, data-foldernamedata-msgid) 모든 HTML 요소(element)에 페이지에 특수한 커스텀 데이터를 저장하기 위해 명시 될 수 있습니다.


HTML 문서들에, HTML 네임스페이스 안에 있는 요소(element)들은 명시된 xmlns 속성(attribute)을 가질 수 있고, 이 속성(attribute)을 가진 경우에만, 정확한 값 "https://www.w3.org/1999/xhtml"을 가집니다. 이것은 XML 문서들에는 적용되지 않습니다.

HTML에서, xmlns 속성(attribute)은 전혀 영향을 가지지 않습니다. 이것은 기본적으로 마스코트 같은 것 입니다. 단지 XHTML로 그리고 XHTML로부터 약간 쉽게 마이그레이션 할 수 있도록 허용된 것입니다. HTML 해석기에 의해 해석된 경우, 속성(attribute)은 XML에서 네임스페이스 선언 속성(attribute)과 같은 "https://www.w3.org/2000/xmlns/" 네임스페이스가 아닌, 어떤 네임스페이스에도 없게 됩니다.

XML에서, xmlns 속성(attribute)은 네임스페이스 선언 메커니즘의 일부이고, 요소(element)는 실제로 명시된 네임스페이스가 없는 xmlns 속성(attribute)을 가질 수 없습니다.


XML 명세는 또한 XML 문서에 있는 모든 요소에 XML 네임스페이스에 있는 xml:space 속성(attribute)의 사용을 허용합니다. 이 속성(attribute)은 HTML에서 기본 동작이 여백을 유지하는 것이기 때문에, html 요소(element)들에 어떤 영향도 가지지 않습니다. [XML]

text/html 문법에서 html 요소(element)들xml:space 속성(attribute)을 직렬화 하는 방법은 없습니다.

3.2.5.1. id 속성(attribute)

id 속성(attribute)은 그 요소(element)의 고유 식별자 (ID)를 명시합니다. [DOM]

값은 요소(element)의 홈 하위 트리에 있는 모든 ID들 중 고유해야(must) 하고 적어도 하나의 문자를 포함해야(must) 합니다. 값은 어떠한 공백 문자들도 포함하지 않아야(must) 합니다.

ID가 취할 수 있는 형식에는 다른 제약사항이 없습니다; 특별히, 숫자로 구성 될 수도, 숫자로 시작할 수도, 밑줄로 시작할 수도, 구두점으로 구성 될 수도, 기타 등등이 가능합니다.

요소(element)의 고유 식별자는 가장 명백하게는 부분 식별자를 사용하여 문서의 특정 부분으로 연결하기 위한 방법으로, 스크립팅의 경우 요소(element)를 목표로 삼기 위한 방법으로, CSS에서 특정 요소(element)를 스타일하기 위한 방법 등 다양한 목적으로 사용될 수 있습니다.

식별자는 분명하지 않은 문자열입니다. 특별한 의미(meanings)가 id 속성(attribute)의 값으로부터 파생되지 않아야(should) 합니다.
3.2.5.2. title 속성(attribute)

title 속성(attribute)은 툴팁에 적절할 것 같은 조언 정보를 나타냅니다. 링크에서, 이것은 제목(title)이나 대상 리소스의 설명이 될 수 있고; 이미지에서, 이미지 제공자(image credit)나 이미지의 설명; 문단에서, 텍스트에 각주나 주석; 인용구에서, 소스에 대한 추가적인 정보; 대화형(interactive) 콘텐트에서, 요소(element)의 사용에 대한 레이블이나 지시사항 등등이 될 수 있습니다. 값은 텍스트입니다.

title 속성(attribute)에 의존하는 것은 많은 유저 에이전트들이 이 명세에 의해 요구된 대로 접근 가능한 방법으로 속성을 노출하지 않기 때문에 (예를 들어, 현대의 폰이나 태블릿을 가진 사람들 같이, 키보드만 사용하는 유저와 터치만 사용하는 유저들을 배제하고, 툴팁이 나타나도록 하기 위해 마우스 같은 포인팅 디바이스를 요구하는 것) 현재 지양됩니다.

이 속성(attribute)이 요소(element)에 생략되었다면, title 속성(attribute) 설정을 가진 가장 가까운 조상 HTML 요소title 속성(attribute)이 이 요소(element)에도 관련 됨을 암시합니다. 속성(attribute)이 이것을 재정의하도록 설정하는 것은, 명시적으로 모든 조상 요소(element)의 조언 정보가 이 요소에 관련되지 않음을 지정하는 것입니다. 속성(attribute)을 빈 문자열로 설정하는 것은 요소(element)가 조언 정보를 가지지 않는 다는 것을 나타냅니다.

title 속성(attribute)의 값이 U+000A 라인피드 (LF) 문자를 포함한다면, 콘텐트는 여러 줄로 나뉘어 집니다. 각 U+000A 라인피드 (LF) 문자는 개행을 나타냅니다.

주의해야 할 것은 title 속성(attribute)에 새로운 행을 사용하는 점에 대해 신중해야 합니다.

예를 들어, 다음 코드 조각은 실제로 개행이 있는 축약어의 본딧말을 정의합니다:

<p>My logs show that there was some interest in <abbr title="Hypertext
Transport Protocol">HTTP</abbr> today.</p>

마치 <br> 이 있는 것과 같이 표현되며, 스크린 리더로 읽을 시에도 <br> 처리가 된 것 처럼 "Hypertext"를 한 개 행으로, "Transport Protocol"를 한 개 행으로 읽습니다.
즉, "Hypertext Transport Protocol" 이라는 하나의 용어를 의미하지 않게 됩니다.

link, abbr, input 같은 어떤 요소(element)들은 위에서 설명된 의미(semantics) 이외에 title 속성(attribute)에 대한 추가적인 의미(semantics)를 정의합니다.

요소(element)의 조언 정보는 일단 값이 반환되면 알고리즘이 중단되는 다음 알고리즘이 반환하는 값입니다. 알고리즘이 빈 문자열을 반환하는 경우, 조언 정보는 없습니다.
  1. 요소(element)가 link, style, dfn, abbr, menuitem 요소(element)라면: 요소(element)가 title 속성(attribute)을 가진다면, 그 속성(attribute)의 값을 반환하고, 그렇지 않으면 빈 문자열을 반환합니다.

  2. 그렇지 않고, 요소(element)가 속성(attribute)을 가진다면, 그 값을 반환합니다.

  3. 그렇지 않고, 요소(element)가 부모 요소를 가진다면, 부모 요소(element)의 조언 정보를 반환합니다.

  4. 그렇지 않으면, 빈 문자열을 반환합니다.

유저 에이전트들은 요소(element)가 조언 정보를 가지는 경우, 사용자에게 알려야(should) 하고, 그렇지 않으면 정보는 인지될 수 없을 것입니다.


title IDL 속성(attribute)은 title 콘텐트 속성(attribute)을 반영해야(must) 합니다.

3.2.5.3. langxml:lang 속성(attribute)

lang 속성(attribute)은 (네임스페이스에 없는) 요소(element)의 콘텐츠와 텍스트를 포함하는 요소(element)의 속성(attribute)에 대한 주 언어를 명시합니다. 그 값은 유효한 BCP 47 언어 태그나 빈 문자열이어야(must) 합니다. 속성(attribute)을 빈 문자열로 설정하는 것은 주 언어가 알 수 없는 것임을 나타냅니다. [BCP47]

XML 네임스페이스에 있는 lang 속성(attribute)은 XML에서 정의됩니다. [XML]

요소(element)에서 이 속성(attribute)들이 생략되었다면, 이 요소(element)의 언어는 부모 요소(element)의 언어가 있다면 그것과 동일합니다.

네임 스페이스가 없는 lang 속성(attribute)은 모든 HTML 요소(element)에 사용 될 수 있습니다.

XML 네임스페이스에 있는 lang 속성(attribute)은 XML 문서html 요소(element)들 뿐만 아니라, 관련 명세가 그것을 허용한다면 (특히, MathML과 SVG는 그들의 요소(elemenet)에 XML 네임스페이스lang 속성(attribute)이 명시되는 것을 허용합니다) 다른 네임스페이스에 있는 요소(element)들에 사용될 수 있습니다. 네임 스페이스가 없는 lang 속성(attribute)과 XML 네임스페이스에 있는 lang 속성(attribute)이 모두 동일한 요소(element)에 명시되었다면, 그것들은 ASCII 대소문자 비구분 방식으로 비교되는 경우 정확히 동일한 값을 가져야(must) 합니다.

작성자는 HTML 문서들html 요소(element)들XML 네임스페이스에 있는 lang 속성(attribute)을 사용하지 않아야(must) 합니다. XHTML로 그리고 XHTML로부터 쉬운 마이그레이션을 위해, 작성자는 XML 네임스페이스가 없는 속성(attribute)을 HTML 문서html 요소(element)들에 지역 이름 "xml:lang"를 가지고 접두어 없이 명시할 수 있지만, 그러한 속성(attribute)들은 네임스페이스가 없는 lang 속성(attribute)도 명시된 경우에만 명시되어야(must) 하고, 두 속성(attribute) 모두 ASCII 대소문자 비구분 방법으로 비교될 경우 동일한 값을 가져야(must) 합니다.

접두어가 없고 리터럴 지역 이름 "xml:lang"을 가진 네임스페이스가 없는 속성(attribute)은 언어 처리에 영향을 가지지 않습니다.

HTML 문서들의 언어는 (문서의 주 언어를 나타내기 위해 HTML 요소(element) 자신에, 언어의 변경을 나타내기 위해 각 요소(element)들에) lang 속성(attribute)을 사용하여 나타납니다. 그것은 콘텐트의 언어에 대해 유저 에이전트들에 명시적인 표시를 제공하기 때문에, 적절한 언어 사전이 사용될 수 있고, 스크린 리더와 음성 출력을 가진 비슷한 보조 기술의 경우에, 콘텐트는 올바른 음성 / 언어 라이브러리를 (사용 가능한 경우) 사용하여 발음됩니다. 문서나 문서 일부의 언어와 일치하지 않는 lang 속성(attribute)을 사용하여 언어를 설정하는 것은 일부 사용자가 내용을 이해할 수 없게 만들 것입니다.


노드의 언어를 결정하기 위해, 유저 에이전트들은 XML 네임스페이스에 있는 lang 속성(attribute) 세트를 가지거나 네임스페이스가 없는 lang 속성(attribute) 세트를 가진 HTML 요소(element)인 가장 가까운 조상 요소(element)를 (노드가 요소(element)라면 그 요소(element)를 포함하여) 고려해야(must) 합니다. 그 속성(attribute)은 노드의 언어를 명시합니다(그 값에 상관하지 않고).

네임 스페이스가 없는 lang 속성(attribute)과 XML 네임스페이스에 있는 lang 속성(attribute)이 둘 모두 요소(element)에 설정된 경우, 유저 에이전트들은 XML 네임스페이스에 있는 lang 속성(attribute)을 사용해야(must)하고, 네임 스페이스가 없는 lang 속성(attribute)은 요소(element)의 언어 결정의 목적에 대해 무시되어야(must) 합니다.

루트 요소(element)를 포함하여 노드나 노드의 조상 중 어떠한 것도 속성(attribute) 세트를 가지지 않지만, 선처리 설정 기본 언어 세트가 존재한다면, 그것은 노드의 언어입니다. 선처리 설정 기본 언어 세트가 없다면, 상위 레벨 프로토콜(HTTP 같은)의 언어 정보가 있다면 대신 마지막 폴백 언어로서 그것이 사용되어야(must) 합니다. 그러한 언어 정보가 없고, 상위 레벨 프로토콜이 여러 언어를 출력하는 경우, 노드의 언어는 알 수 없고, 해당하는 언어 태그는 빈 문자열입니다.

예를 들어, 문서가 HTTP로 전송되고 Content-Language HTTP 헤더가 "en"로 정의되어 있다면 (그리고 선처리 설정 기본 언어가 없다면), 그 자체에 lang 속성이나 해당 요소(element)의 어떤 조상도 가지지 않는 문서 내 모든 요소(element)에 대해, 요소에 대한 폴백 언어는 영어가 될 것입니다. Content-Language 헤더의 값이 "de, fr, it" 였다면, 노드의 언어는 알 수 없습니다. 이 글은 HTTP 헤더와 언어 정보를 제공하는 meta 요소(element) 사용에 대한 몇 가지 추가적인 지침을 제공합니다.

결과 값이 알려진 언어 태그가 아니라면, 모든 다른 언어들와 별개의, 주어진 언어 태그를 가지는 알 수 없는 언어로 취급되어야(must) 합니다. 언어 태그를 기대하는 다른 서비스와 왕복하거나 통신하는 목적을 위해, 유저 에이전트들은 BCP 47 언어 태그가 되도록 태그 되고, 수정되지 않은 채로 알 수 없는 언어를 전달해야(should) 하기 때문에, 차후 서비스들은 언어 설명의 다른 유형으로 데이터를 해석하지 않습니다. [BCP47]

따라서, 예를 들어, lang="xyzzy"를 가진 요소(element)는, 둘 모두 동일하게 유효하지 않기는 하지만, 선택자 :lang(xyzzy)에 (예를 들어, CSS에서) 매칭될 것이지만 :lang(abcde)에는 매칭되지 않을 것입니다. 비슷하게, 웹 브라우저와 스크린 리더가 요소(element)의 언어에 대해 합력하여 통신했다면, 그것이 유효하지 않다는 것을 알았을 지라도, 결국에는 스크린 리더는 실제로 그 태그를 가지고 언어가 지원된 경우에 한하여, 브라우저는 스크린 리더에 언어가 "xyzzy"라고 알려줄 것입니다. 스크린 리더가 BCP 47과 인코딩 언어 이름을 위한 다른 문법이 모두 지원되고 그 다른 문법에서 문자열 "xyzzy"가 벨라루스어를 나타내는 방법이었다 하더라도, "xyzzy"는 벨라루스어가 BCP 47 코드로 기술 된 방식이 아니기 때문에 (BCP 47은 벨라루스어에 대해 코드 "be"를 사용합니다), 그것은 스크린리더가 텍스트를 벨라루스어로 취급하기 시작하는 것은 옳지 않게 될 것입니다.

결과 값이 빈 문자열이라면, 노드의 언어가 명시적으로 알 수 없음을 의미하는 것으로 해석 되어야(must) 합니다.


유저 에이전트들은 요소의 언어를 적절한 처리나 렌더링을 결정하는데 사용할 수 있습니다 (예를 들어, 적절한 폰트나 발음의 선택으로, 혹은 사전 선택을 위해, 혹은 날짜 선택기 같은 양식 컨트롤의 유저 인터페이스를 위해).


lang IDL 속성(attribute)은 네임 스페이스가 없는 lang 콘텐트 속성(attribute)을 반영해야(must) 합니다.

3.2.5.4. translate 속성(attribute)

translate 속성(attribute)은 페이지가 지역화 될 때 요소(element)의 속성(attribute) 값과 그것의 자식 Text 노드의 값이 번역될지 여부를 지정하는데 사용되는 열거 속성(attribute)입니다.

속성(attribute)의 키워드는 빈 문자열, yes, no입니다. 빈 문자열과 yes 키워드는 yes 상태에 매핑됩니다. no 키워드는 no 상태에 매핑됩니다. 게다가, 세번째 상태가 있는데, 누락 기본 값인 (그리고 유효하지 않은 기본 값인) inherit 상태입니다.

각 요소(element)는 (비 HTML 요소(element) 조차) 번역 가능 상태 혹은 번역 안함 상태에 속하는, 번역 모드를 가집니다. HTML 요소(element)translate 속성(attribute)이 yes 상태에 있다면, 요소(element)의 번역 모드번역 가능 상태에 있습니다; 그렇지 않고 요소(element)의 translate 속성(attribute)이 no 상태에 있다면, 요소(element)의 번역 모드번역 안함 상태에 있습니다; 그렇지 않으면, 요소(element)의 translate 속성(attribute)은 inherit 상태에 있거나 요소(element)는 HTML 요소(element)가 아니고 따라서 translate 속성(attribute)을 가지지 않습니다; 어느 경우에나, 요소(element)의 번역 모드는 그 부모 요소(element)의 상태가 있다면 그것과 동일한 상태에 있거나, 요소가 루트 요소(element)라면, 번역 가능 상태에 있습니다.

요소(element)가 번역 가능 상태에 있다면, 요소(element)의 번역 가능 속성(attribute)들과 자식 Text 노드의 값들은 페이지가 지역화 될 경우 번역 되어야 합니다.

요소(element)가 번역 안함 상태에 있는 경우, 예를 들어, 요소(element)가 사람의 이름이나 컴퓨터 프로그램의 이름을 포함하기 때문에, 요소(elment)의 속성(attribure)값과 자식 Text 노드의 값들은 페이지가 지역화 될 때 그대로 남습니다.

다음 속성(attribute)들은 번역 가능 속성(attribute)입니다: