W3C

HTML 5.1

W3C Recommendation,

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