차례
  1. 1 소개
    1. 1.1 배경
    2. 1.2 대상 독자
    3. 1.3 초점
    4. 1.4 역사
    5. 1.5 디자인 노트
      1. 1.5.1 스크립트 실행의 직렬화
      2. 1.5.2 다른 명세와의 관계
    6. 1.6 HTML 과 XHTML
    7. 1.7 명세의 구조
      1. 1.7.1 명세를 읽는 방법
      2. 1.7.2 표현 방법
    8. 1.8 HTML에 대한 간단한 소개
    9. 1.9 저자가 지켜야 할 것
      1. 1.9.1 표현적 마크업
      2. 1.9.2 문법 에러
      3. 1.9.3 내용 모델과 속성값에 대한 제한
    10. 1.10 읽을만한 것들

1 소개

1.1 배경

This section is non-normative.

월드 와이드 웹의 마크업 언어는 항상 HTML이었습니다. HTML은 원래 과학 문서를 의미에 따라 기술하기 위하여 디자인된 언어지만, 그 디자인과 이행은 몇 년에 걸쳐 변화되어 다른 타입의 문서를 기술하는데에도 사용할 수 있게 되었습니다.

The World Wide Web's markup language has always been HTML. HTML was primarily designed as a language for semantically describing scientific documents, although its general design and adaptations over the years have enabled it to be used to describe a number of other types of documents.

웹 어플리케이션이라 불리는 모호한 분야는 HTML의 주된 분야인데도 적절히 다루어지지 않았습니다. 이 명세에서는 이것을 교정하는 시도를 할 것이며, 동시에 지난 몇 년간 제기되었던 이슈들을 다룰 수 있도록 HTML 명세를 갱신할 것입니다.

The main area that has not been adequately addressed by HTML is a vague subject referred to as Web Applications. This specification attempts to rectify this, while at the same time updating the HTML specifications to address issues raised in the past few years.

1.2 독자

This section is non-normative.

이 명세는 포함된 기능들을 이용하여 문서와 스크립트를 작성하는 사람들과 여기에 기술된 기능을 이용하여 사용자 에이전트를 제작하는 이행자, 또한 문서들, 혹은 이행안에 수정을 가하기를 원하는 사람들을 위한 것입니다.

This specification is intended for authors of documents and scripts that use the features defined in this specification, implementors of tools that operate on pages that use the features defined in this specification, and individuals wishing to establish the correctness of documents or implementations with respect to the requirements of this specification.

이 문서는 웹 기술에 어느 정도라도 익숙하지 않은 사람들에게는 아마도 적합하지 않을 것인데, 왜냐하면 이 문서는 정확한 표현을 위해 명쾌함을 어느 정도 희생하고 있으며, 또한 완전함을 위해서 간결함을 희생하고 있기 때문입니다. 좀 더 친숙한 설명서와 가이드들이 있을 수 있습니다.

This document is probably not suited to readers who do not already have at least a passing familiarity with Web technologies, as in places it sacrifices clarity for precision, and brevity for completeness. More approachable tutorials and authoring guides can provide a gentler introduction to the topic.

특히, DOM 코어와 DOM 이벤트의 기초에 대한 어느 정도의 지식이 있어야 이 명세에서 다루는 좀 더 기술적인 부분을 이해할 수 있을 것입니다. 웹 IDL, HTTP, XML, 유니코드, 문자 인코딩, 자바스크립트, CSS에 대한 지식 역시 도움이 되는 곳이 있겠지만, 필수는 아닙니다.

In particular, familiarity with the basics of DOM Core and DOM Events is necessary for a complete understanding of some of the more technical parts of this specification. An understanding of Web IDL, HTTP, XML, Unicode, character encodings, JavaScript, and CSS will also be helpful in places but is not essential.

1.3 초점

This section is non-normative.

이 명세는 의미 레벨의 마크업 언어를 제공하며, 또한 의미 레벨의 스크립팅 API를 제공하여 웹에서 정적인 문서로부터 동적인 어플리케이션까지 다양한 페이지를 저작하도록 하는 것에 초점을 맞추고 있습니다.

This specification is limited to providing a semantic-level markup language and associated semantic-level scripting APIs for authoring accessible pages on the Web ranging from static documents to dynamic applications.

이 명세의 초점은 미디어에 국한된, 세부적인 표현이 아닙니다. (웹 브라우저의 기본적인 렌더링 규칙이 이 명세의 후반에 포함되어 있고, CSS를 다루는 몇 가지 기술 사항이 언어의 일부로서 소개되기는 할 것입니다.)

The scope of this specification does not include providing mechanisms for media-specific customization of presentation (although default rendering rules for Web browsers are included at the end of this specification, and several mechanisms for hooking into CSS are provided as part of the language).

이 명세의 초점은 운영체제 전체를 기술하는 것이 아닙니다. 하드웨어 제어를 위한 소프트웨어, 이미지 조작 도구, 그리고 사용자들이 고성능 워크스테이션에서 일상적인 작업으로서 사용할 어플리케이션 등은 명세의 초점을 벗어납니다. 이 명세에서 사용하는 어플리케이션이라는 단어는 사용자들이 이따금, 혹은 자주 사용하고 보통 원격에서 사용하며, 높은 CPU 성능을 요구하지는 않는 그러한 것을 말합니다. 예를 들어 온라인 거래 시스템, 검색 시스템, 게임(특히, 멀티플레이어 온라인 게임), 공용 전화번호부 또는 주소록, 통신 소프트웨어(이메일 클라이언트, 인스턴트 메시징 클라이언트, 토론 소프트웨어), 문서 편집 소프트웨어 등이 있습니다.

The scope of this specification is not to describe an entire operating system. In particular, hardware configuration software, image manipulation tools, and applications that users would be expected to use with high-end workstations on a daily basis are out of scope. In terms of applications, this specification is targeted specifically at applications that would be expected to be used by users on an occasional basis, or regularly but from disparate locations, with low CPU requirements. For instance online purchasing systems, searching systems, games (especially multiplayer online games), public telephone books or address books, communications software (e-mail clients, instant messaging clients, discussion software), document editing software, etc.

1.4 역사

This section is non-normative.

초창기의 5년간(1990-1995), HTML은 많은 개정을 거쳤고 많은 확장을 시도하였습니다. 이러한 시도는 처음에는 CERN에서 이루어졌고, IETF로 넘어왔습니다.

For its first five years (1990-1995), HTML went through a number of revisions and experienced a number of extensions, primarily hosted first at CERN, and then at the IETF.

W3C의 창설과 함께, HTML 개발의 중심은 다시 이동하였습니다. 수포로 돌아간 첫 번째 시도는 1995년에 있었는데, 이것은 HTML 3.0이라 합니다. 좀 더 실용적인 접근이 1997년에 있었고 이것은 HTML 3.2입니다. HTML 4가 뒤를 이었고, 이것은 1998년에 완성되었습니다.

With the creation of the W3C, HTML's development changed venue again. A first abortive attempt at extending HTML in 1995 known as HTML 3.0 then made way to a more pragmatic approach known as HTML 3.2, which was completed in 1997. HTML4 followed, reaching completion in 1998.

이 시기에, W3C 회원들은 HTML의 진화를 멈추기로 하였고, 대신 XML에 기초한 대체품의 작업에 착수하였습니다. 이것이 XHTML입니다. 이러한 노력은 HTML4를 XML로 재형성하는 작업으로 시작하였고, XHTML 1.0이라 알려졌습니다. XHTML 1.0은 직렬화 이외에 새롭게 추가된 기능은 없었으며 2000년도에 완료되었습니다. XHTML 1.0 이후, W3C의 초점은 다른 워킹 그룹들이 XHTML을 확장하는 작업을 쉽게 하는 것으로 바뀌었습니다. 이러한 노력을 XHTML 모듈화라 부릅니다. 이와 동시에, W3C는 기존의 HTML, XHTML 언어와 호환되지 않는 새로운 언어의 개발에 착수하였으며 이것을 XHTML 2라고 칭했습니다.

At this time, the W3C membership decided to stop evolving HTML and instead begin work on an XML-based equivalent, called XHTML. This effort started with a reformulation of HTML4 in XML, known as XHTML 1.0, which added no new features except the new serialization, and which was completed in 2000. After XHTML 1.0, the W3C's focus turned to making it easier for other working groups to extend XHTML, under the banner of XHTML Modularization. In parallel with this, the W3C also worked on a new language that was not compatible with the earlier HTML and XHTML languages, calling it XHTML2.

1998년에 HTML이 그 진화를 멈추었을 무렵, HTML을 위한 API 일부가 브라우저 제작사들에 의해 개발되었고, DOM 레벨 1이라는 이름으로 명세화되었습니다. 연이어 DOM 레벨 2 코어, DOM 레벨 2 HTML(2000년에 시작되었고 2003년에 절정에 달했습니다)들이 개발되었습니다. 이러한 노력은 2004년에 몇 가지 DOM 레벨 3 명세들이 출판되면서 수그러들었지만, 그 워킹 그룹은 모든 레벨 3 명세들이 초안 단계에 이르기도 전에 종료되었습니다.

Around the time that HTML's evolution was stopped in 1998, parts of the API for HTML developed by browser vendors were specified and published under the name DOM Level 1 (in 1998) and DOM Level 2 Core and DOM Level 2 HTML (starting in 2000 and culminating in 2003). These efforts then petered out, with some DOM Level 3 specifications published in 2004 but the working group being closed before all the Level 3 drafts were completed.

2003년 XForms - 웹 폼의 새로운 세대가 될 기술 - 이 만들어지면서, HTML에 대한 대체품을 찾기보다 HTML 그 자체를 진화시키는 것에 관한 관심이 새롭게 고조되었습니다. 이러한 관심은 XML을 새로운 웹 기술로서 배포하는 것이 완벽히 새로운 기술(RSS, 후반기의 Atom)에 제한되며 HTML 처럼 이미 널리 알려진 기술에 대한 대체는 되지 못하였던 것에 기인합니다.

In 2003, the publication of XForms, a technology which was positioned as the next generation of Web forms, sparked a renewed interest in evolving HTML itself, rather than finding replacements for it. This interest was borne from the realization that XML's deployment as a Web technology was limited to entirely new technologies (like RSS and later Atom), rather than as a replacement for existing deployed technologies (like HTML).

브라우저들이 이미 존재하는 HTML 웹 페이지와 호환되지 않는 렌더링 엔진을 개발할 필요 없이 XForms 1.0에서 소개된 기능들을 HTML4의 폼에 제공하는 것이 가능하다는 증거가, 이 새롭게 고조된 관심의 첫 결과였습니다. 이러한 초기 시기, 초안들이 이미 공개되어 있었고 모든 곳에서 투입하길 갈망하고 있었지만, 명세의 저작권은 오직 오페라 소프트웨어의 소유였습니다.

A proof of concept to show that it was possible to extend HTML4's forms to provide many of the features that XForms 1.0 introduced, without requiring browsers to implement rendering engines that were incompatible with existing HTML Web pages, was the first result of this renewed interest. At this early stage, while the draft was already publicly available, and input was already being solicited from all sources, the specification was only under Opera Software's copyright.

HTML의 진화를 다시 시작해야 한다는 아이디어는 2004년 W3C 워크샵에서 테스트 되었습니다. 이 테스트에는 HTML5 작업의 기반이 되는 원칙들(아래에 설명합니다.)과 함께, 앞서 설명했던 폼 관련 기능들에 대한 초안이 모질라와 오페라에서 공동으로 W3C에 제안되었습니다. 이 제안은 거절되었습니다. W3C 스탭과 회원들은 XML에 기반을 둔 대체품을 웹의 진화를 위한 수단으로 이미 선택하였기 때문에, 새로운 제안과 충돌한다는 이유였습니다.

The idea that HTML's evolution should be reopened was tested at a W3C workshop in 2004, where some of the principles that underlie the HTML5 work (described below), as well as the aforementioned early draft proposal covering just forms-related features, were presented to the W3C jointly by Mozilla and Opera. The proposal was rejected on the grounds that the proposal conflicted with the previously chosen direction for the Web's evolution; the W3C staff and membership voted to continue developing XML-based replacements instead.

그 직후, 애플, 모질라, 오페라는 공동으로 그들이 제안했던 내용을 계속해서 발전시켜 나갈 것을 선언하였습니다. 공개적인 메일링 리스트들이 만들어졌고, 그들의 초안은 WHATWG 사이트로 이동되었습니다. 이에 대한 수정, 그리고 그 명세를 재사용할 수 있는 저작권은 3개 회사가 공동으로 소유하게 되었습니다.

Shortly thereafter, Apple, Mozilla, and Opera jointly announced their intent to continue working on the effort under the umbrella of a new venue called the WHATWG. A public mailing list was created, and the draft was moved to the WHATWG site. The copyright was subsequently amended to be jointly owned by all three vendors, and to allow reuse of the specification.

WHATWG는 몇 개의 핵심적인 원칙들에 기반을 둡니다. 자세히 말해서 기술은 하위 호환성을 가져야 한다는 것, 명세와 이행은 서로 합치되어야 하며, 이행이 아니라 명세를 변경해서라도 이러한 합치를 이루어야 한다는 것, 그리고 명세는 충분히 자세하게 이루어짐으로써 이행안들이 서로 역컴파일하지 않고도 완전한 상호작용성을 가질 수 있어야 한다는 것입니다.

The WHATWG was based on several core principles, in particular that technologies need to be backwards compatible, that specifications and implementations need to match even if this means changing the specification rather than the implementations, and that specifications need to be detailed enough that implementations can achieve complete interoperability without reverse-engineering each other.

마지막의 요구사항은 HTML5 명세의 초점이 이미 3개로 분리되어 명시된 문서들 - HTML4, XHTML1, DOM2 HTML - 을 포함하게끔 하였습니다. 또한, 기존에 일반적인 것으로 간주하던 것보다 훨씬 더 상세한 명세를 포함할 것이 요구되었습니다.

The latter requirement in particular required that the scope of the HTML5 specification include what had previously been specified in three separate documents: HTML4, XHTML1, and DOM2 HTML. It also meant including significantly more detail than had previously been considered the norm.

2006년, W3C는 HTML5 의 개발에 참가할 의사를 표명하였고, 2007년에 HTML5 명세의 개발을 위해 WHATWG와 함께 작업할 워킹그룹이 만들어졌습니다. 애플, 모질라, 오페라는 W3C가 관리하는 저작권을 통해 명세를 발행할 것을 허가하였는데, WHATWG 사이트에 좀 덜 제한적인 라이센스를 제공하는 조건이었습니다.

In 2006, the W3C indicated an interest to participate in the development of HTML5 after all, and in 2007 formed a working group chartered to work with the WHATWG on the development of the HTML5 specification. Apple, Mozilla, and Opera allowed the W3C to publish the specification under the W3C copyright, while keeping a version with the less restrictive license on the WHATWG site.

그때부터 두 그룹은 함께 작업해오고 있습니다.

Since then, both groups have been working together.

WHATWG에서 발행하는 명세는 이 명세와 완벽히 같지는 않습니다. 이 판본을 발행하는 현재, 주요한 차이점은 WHATWG 버전은 W3C 버전에 포함되어 있지 않은 기능들을 포함한다는 것입니다. 몇 가지 기능은 생략되었지만 HTML5 이후의 HTML 개정판에서는 고려할 수도 있습니다. 다른 기능은 W3C에서 별도의 명세로 발행하고 있기 때문에 생략했습니다.

The HTML specification published by the WHATWG is not identical to this specification. At the time of this publication, the main differences were that the WHATWG version included features not included in this W3C version: some features have been omitted, but may be considered for future revisions of HTML beyond HTML5; and other features were omitted because at the W3C they are published as separate specifications.

W3C HTML 워킹 그룹에서 HTML4 명세에서 설명된 언어와 이 명세 사이의 차이를 다루는 별도의 문서를 발행했습니다. [HTMLDIFF]

A separate document has been published by the W3C HTML working group to document the differences between this specification and the language described in the HTML4 specification. [HTMLDIFF]

1.5 디자인 노트

This section is non-normative.

HTML의 많은 모습이 넌센스며 모순으로 보인다는 점을 인정해야만 합니다.

It must be admitted that many aspects of HTML appear at first glance to be nonsensical and inconsistent.

HTML의 DOM API를 지원에, 다른 모든 기능에서 그랬던 것과 마찬가지로, 오랜 기간에 거쳐 수많은 사람이 참여했지만, 대개는 서로의 존재를 알지 못했습니다.

HTML, its supporting DOM APIs, as well as many of its supporting technologies, have been developed over a period of several decades by a wide array of people with different priorities who, in many cases, did not know of each other's existence.

그 결과 다양한 소스로부터 기능이 추가되었고, 따라서 늘 일관적이지 않았습니다. 게다가, 웹의 독특한 특징 때문에, 이를 이행하면서 생기는 버그는 종종 암묵적인 관례가 되었고, 이제는 정당한 표준으로 여겨질 정도인데, (웹 페이지의) 내용이 버그가 수정되기도 전에 그 버그에 의존하여 작성되었기 때문입니다.

Features have thus arisen from many sources, and have not always been designed in especially consistent ways. Furthermore, because of the unique characteristics of the Web, implementation bugs have often become de-facto, and now de-jure, standards, as content is often unintentionally written in ways that rely on them before they can be fixed.

이 모든 것에도, 명확한 디자인 목적을 향한 노력을 해왔습니다. 이것은 이후 이어질 몇 개의 절에서 다루게 될 것입니다.

Despite all this, efforts have been made to adhere to certain design goals. These are described in the next few subsections.

1.5.1 스크립트 실행의 직렬화

This section is non-normative.

웹 저작자들이 멀티쓰레딩의 복잡함에 고민하는 일을 없애기 위해, HTML과 DOM API는 어떠한 스크립트도 다른 스크립트의 동시 실행에 대해 전혀 감지할 수 없도록 디자인되었습니다. 심지어 Worker 쓰레드 간에도, 모든 브라우징 문맥 내에서의 모든 스크립트 실행을 직렬화 하는 것으로 생각하게끔 의도되었습니다.

To avoid exposing Web authors to the complexities of multithreading, the HTML and DOM APIs are designed such that no script can ever detect the simultaneous execution of other scripts. Even with workers, the intent is that the behavior of implementations can be thought of as completely serializing the execution of all scripts in all browsing contexts.

navigator.getStorageUpdates() 메서드는, 이 모델에서는, 호출하는 스크립트가 차단된 상태에서 다른 스크립트의 실행을 허용하는 것과 같습니다.

The navigator.yieldForStorageUpdates() method, in this model, is equivalent to allowing other scripts to run while the calling script is blocked.

1.5.2 다른 명세와의 관계

This section is non-normative.

이 명세는 다른 많은 명세와 상호작용하며, 의존하기도 합니다. 불행하게도, 현존하는 컨텐츠들과 호환되고자 하는 의도의 결과로, 몇몇 상황에서는 이 명세가 다른 명세의 요구사항을 위반하는 때도 있습니다. 이러한 경우가 발생할 때마다, 이것을 "의도된 위반"이라고 기록할 것입니다.

This specification interacts with and relies on a wide variety of other specifications. In certain circumstances, unfortunately, conflicting needs have led to this specification violating the requirements of these other specifications. Whenever this has occurred, the transgressions have each been noted as a "willful violation", and the reason for the violation has been noted.

1.6 HTML과 XHTML

This section is non-normative.

이 명세는 HTML을 사용하는 자원들의 메모리 내부 구조와 상호작용하는 몇 가지 API, 어플리케이션, 문서들을 기술하는 추상화된 언어를 설명합니다.

This specification defines an abstract language for describing documents and applications, and some APIs for interacting with in-memory representations of resources that use this language.

메모리 내부 구조를 DOM HTML, 또는 줄여서 DOM이라 합니다. 이 명세는 DOM HTML의 5번째 버전을 정의하며, 이를 DOM5 HTML이라 합니다.

The in-memory representation is known as "DOM HTML", or "the DOM" for short. This specification defines version 5 of DOM HTML, known as "DOM5 HTML".

이 추상화된 언어를 사용해서 자원을 전달하는 데 사용할 수 있는 다양하고 견고한 문법들이 존재합니다. 그중 두 가지는 이 명세에서 정의합니다.

There are various concrete syntaxes that can be used to transmit resources that use this abstract language, two of which are defined in this specification.

그러한 견고한 문법 중 첫 번째는 HTML 문법입니다. 저자 대부분에게 권장하며, 대부분의 구형 웹 브라우저와 호환됩니다. 문서가 text/html같은 HTML 마임 타입으로 전송된다면, 웹 브라우저는 HTML 문서로서 처리합니다. 이 명세는 HTML 문법의 다섯 번째 버전을 정의하며, 이것을 HTML5 라 합니다.

The first such concrete syntax is the HTML syntax. This is the format suggested for most authors. It is compatible with most legacy Web browsers. If a document is transmitted with an HTML MIME type, such as text/html, then it will be processed as an HTML document by Web browsers. This specification defines version 5 of the HTML syntax, known as "HTML5".

두 번째는 XML을 적용한 XHTML 문법입니다. 문서가 application/xhtml+xml같은 XML 마임 타입으로 전송된다면, 브라우저는 이것을 XML 문서로 간주할 것이며, XML 처리기가 파싱할 것입니다. XML의 처리와 HTML의 처리가 다르다는 것에 유념할 필요가 있습니다. 예를 들어 XML 문서에서는 사소한 문법 오류도 문서가 완벽히 렌더링 되지 못하게 할 것이지만, HTML 문법에서는 그러한 오류는 아마도 무시할 것입니다. 이 명세는 XHTML 문법의 5번째 버전을 정의하며, 이를 XHTML5 라 합니다.

The second concrete syntax is the XHTML syntax, which is an application of XML. When a document is transmitted with an XML MIME type, such as application/xhtml+xml, then it is treated as an XML document by Web browsers, to be parsed by an XML processor. Authors are reminded that the processing for XML and HTML differs; in particular, even minor syntax errors will prevent a document labeled as XML from being rendered fully, whereas they would be ignored in the HTML syntax. This specification defines version 5 of the XHTML syntax, known as "XHTML5".

DOM, HTML 문법, XML은 같은 컨텐츠를 나타내지 못합니다. 예를 들어, HTML 문법은 네임스페이스를 지원하지 못하지만, DOM과 XML은 그것을 지원합니다. 흡사하게, noscript 기능을 사용하는 문서는 HTML 문법에서는 잘 표현되겠지만, DOM과 XML에서는 표현되지 못합니다. 주석에 --> 문자열을 사용한다면 DOM에서는 그것을 주석으로 인식하겠지만, HTML 문법이나 XML에서는 그렇지 못할 것입니다.

The DOM, the HTML syntax, and XML cannot all represent the same content. For example, namespaces cannot be represented using the HTML syntax, but they are supported in the DOM and in XML. Similarly, documents that use the noscript feature can be represented using the HTML syntax, but cannot be represented with the DOM or in XML. Comments that contain the string "-->" can only be represented in the DOM, not in the HTML and XML syntaxes.

1.7 명세의 구조

This section is non-normative.

이 명세는 다음의 주된 섹션으로 분할됩니다.

This specification is divided into the following major sections:

공통 인프라구조 Common infrastructure

명세 전반에 걸쳐 사용될 클래스, 알고리즘, 정의, 그리고 기반구조들입니다.

The conformance classes, algorithms, definitions, and the common underpinnings of the rest of the specification.

HTML 문서의 의미론, 구조, API Semantics, structure, and APIs of HTML documents

문서는 요소로 구성됩니다. 이러한 요소는 DOM을 통해 트리 구조를 가집니다. 이 섹션은 이러한 DOM의 기능을 정의하며, 또한 모든 요소에 공통인 기능을 정의하고, 요소를 정의하는데 사용되는 컨셉을 설명합니다.

Documents are built from elements. These elements form a tree using the DOM. This section defines the features of this DOM, as well as introducing the features common to all elements, and the concepts used in defining elements.

HTML의 요소들 The elements of HTML

이 섹션에서는 각각의 요소에 미리 정의된 의미와 함께 해당 요소의 사용법도 설명합니다.

Each element has a predefined meaning, which is explained in this section. Rules for authors on how to use the element, along with user agent requirements for how to handle each element, are also given.

웹 페이지 로딩 Loading Web pages

HTML 문서는 진공 속에 존재하는 것이 아닙니다. 이 섹션은 다양한 문서들을 다루는 환경들에 영향을 미치는 기능들을 설명합니다.

HTML documents do not exist in a vacuum — this section defines many of the features that affect environments that deal with multiple pages.

웹 어플리케이션 API Web application APIs

이 섹션은 HTML 어플리케이션의 스크립팅을 위한 간단한 기능들을 소개합니다.

This section introduces basic features for scripting of applications in HTML.

사용자 상호작용 User interaction

이 섹션에서는 HTML 문서에서 사용자들이 컨텐츠와 상호작용하고 그것을 변경할 수 있도록 제공하는 다양한 메커니즘을 설명합니다.

HTML documents can provide a number of mechanisms for users to interact with and modify content, which are described in this section.

HTML 문법 The HTML syntax
XHTML 문법 The XHTML syntax

이러한 모든 기능은 직렬화된 형태로 나타나고 다른 이들에게 보낼 수 없다면 무가치한 것입니다. 이 섹션에서는 HTML의 문법들을 정의하며, 그러한 문법을 사용해 컨텐츠를 파싱하는 규칙을 정의합니다.

All of these features would be for naught if they couldn't be represented in a serialized form and sent to other people, and so these sections define the syntaxes of HTML, along with rules for how to parse content using those syntaxes.

웹 브라우저들의 렌더링 규칙, 고립된 기능들, IANA 고려사항을 정의하는 부록도 포함됩니다.

There are also some appendices, defining rendering rules for Web browsers and listing obsolete features and IANA considerations.

1.7.1 이 명세를 읽는 방법

이 명세는 다른 모든 명세와 마찬가지로 읽어야 합니다. 첫째, 처음부터 끝까지, 여러 번 읽으십시오. 그다음, 적어도 한번은 거꾸로 읽어야 합니다. 마지막으로, 목차에서 랜덤한 섹션을 고른 뒤, 그것의 모든 상호 참조들을 따라가면서 읽어보십시오.

This specification should be read like all other specifications. First, it should be read cover-to-cover, multiple times. Then, it should be read backwards at least once. Then it should be read by picking random sections from the contents list and following all the cross-references.

1.7.2 표현 방법

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

This is a definition, requirement, or explanation.

유의사항입니다.

This is a note.

예제입니다.

This is an example.

오픈 이슈입니다.

This is an open issue.

경고입니다.

This is a warning.

interface Example { // IDL 정의입니다.};
variable = object . method( [ optionalArgument ] )

인터페이스를 사용하고자 하는 저자들을 위한 노트입니다.

This is a note to authors describing the usage of an interface.

/* this is a CSS fragment */

개념의 정의는 이렇게 나타납니다. 그러한 개념의 사용은 이렇게, 혹은 이렇게 나타날 것입니다.

The defining instance of a term is marked up like this. Uses of that term are marked up like this or like this.

요소, 속성, API의 정의는 이렇게 나타납니다. 그러한 것들에 대한 참조는 이렇게, 혹은 이렇게 나타날 것입니다.

The defining instance of an element, attribute, or API is marked up like this. References to that element, attribute, or API are marked up like this.

기타 코드는 이렇게 나타날 것입니다.

Other code fragments are marked up like this.

변수는 이렇게 나타날 것입니다.

Variables are marked up like this.

이행에 대한 요구사항입니다.

This is an implementation requirement.

1.8 HTML에 대한 간단한 소개

This section is non-normative.

기본적인 HTML 문서는 다음과 같이 보입니다:

A basic HTML document looks like this:

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

HTML 문서는 요소와 텍스트로 구성되는 하나의 트리입니다. 각각의 요소는 시작 태그(<body>)/종료 태그(</body>)로 구분합니다. (몇몇 상황에서, 특정 요소는 생략될 수 있으며 그런 때는 바깥의 태그가 생략된 태그를 암시합니다.)

HTML documents consist of a tree of elements and text. Each element is denoted in the source by a start tag, such as "<body>", and an end tag, such as "</body>". (Certain start tags and end tags can in certain cases be omitted and are implied by other tags.)

태그는 삐져나옴 없이 올바른 포함 관계를 가져야 합니다.

Tags have to be nested such that elements are all completely within each other, without overlapping:

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

이 명세는 HTML에서 사용할 수 있는 요소 집합을 정의하며, 이러한 요소들의 상호 포함관계에 대한 규칙 역시 정의합니다.

This specification defines a set of elements that can be used in HTML, along with rules about the ways in which the elements can be nested.

요소는 속성을 가질 수 있으며, 속성은 요소가 어떻게 동작하는지 제어합니다. 위의 예에서는 a 요소href 속성으로 하이퍼링크를 만들었습니다.

Elements can have attributes, which control how the elements work. In the example below, there is a hyperlink, formed using the a element and its href attribute:

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

속성은 시작 태그 내에 있으며, 이름의 쌍으로 이루어지고, 이름과 값은 = 문자로 구분됩니다. 속성의 값이 아무런 특수문자도 포함하지 않을 때에는 따옴표로 감싸지 않아도 됩니다. 그렇지 않다면 반드시 작은따옴표 혹은 큰따옴표로 감싸야 합니다. 속성의 값과 = 문자는 속성값이 빈 문자열일 경우 생략할 수 있습니다.

Attributes are placed inside the start tag, and consist of a name and a value, separated by an "=" character. The attribute value can remain unquoted if it doesn't contain spaces or any of " ' ` = < or >. Otherwise, it has to be quoted using either single or double quotes. The value, along with the "=" character, can be omitted altogether if the value is the empty string.

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

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

사용자 에이전트(예를 들어, 웹 브라우저)는 이러한 마크업을 처리해서, DOM (문서 객체 모델) 트리로 바꿉니다. DOM 트리는 메모리 속에 존재하는 문서입니다.

HTML user agents (e.g. Web browsers) then parse this markup, turning it into a DOM (Document Object Model) tree. A DOM tree is an in-memory representation of a document.

DOM 트리는 여러 종류의 노드들 - DOCTYPE, 요소, 텍스트, 주석 노드들입니다.

DOM trees contain several kinds of nodes, in particular a DOCTYPE node, elements, text nodes, and comment nodes.

이 섹션의 상단에서 예를 들었던 마크업은 다음과 같은 DOM 트리로 변환됩니다.

The markup snippet at the top of this section would be turned into the following DOM tree:

이 트리의 루트 요소html 요소입니다. html 요소는 HTML 문서에서 항상 루트에 존재합니다. html 요소는 head body의 두 요소를 가지며, 그 사이에 텍스트 노드가 있을 수 있습니다.

The root element of this tree is the html element, which is the element always found at the root of HTML documents. It contains two elements, head and body, as well as a text node between them.

일반적으로 예상하는 것보다는 훨씬 많은 텍스트 노드들이 DOM 트리 위에 존재합니다. 왜냐하면, DOM 트리에서는 상당수의 공백문자("␣")와 줄바꿈 문자("⏎")들을 텍스트 노드로 간주하기 때문입니다. 하지만, 이전 버전과의 호환성을 위해 원래 마크업에 있었던 공백과 줄바꿈 중 일부가 제거됩니다. head 요소의 시작 태그 이전에 있는 모든 공백문자와 body 요소의 종료 태그 뒤에 있는 모든 공백문자가 제거됩니다.

There are many more text nodes in the DOM tree than one would initially expect, because the source contains a number of spaces (represented here by "␣") and line breaks ("⏎") that all end up as text nodes in the DOM. However, for historical reasons not all of the spaces and line breaks in the original markup appear in the DOM. In particular, all the whitespace before head start tag ends up being dropped silently, and all the whitespace after the body end tag ends up placed at the end of the body.

head 요소는 title 요소를 가집니다. 이 예제에서는 Sample Page 라는 텍스트 노드를 포함합니다. 이와 흡사하게, body 요소는 h1p 요소, 그리고 주석을 포함하고 있습니다.

The head element contains a title element, which itself contains a text node with the text "Sample page". Similarly, the body element contains an h1 element, a p element, and a comment.


DOM 트리는 페이지에 포함된 스크립트를 통해 제어할 수 있습니다. 스크립트(보통 자바스크립트)는 script 요소, 또는 이벤트 핸들러 내용 속성을 통해 문서에 포함할 수 있습니다. 예를 들어, 아래의 폼은 output 요소의 값을 Hello World로 바꾸는 스크립트를 포함하고 있습니다.

This DOM tree can be manipulated from scripts in the page. Scripts (typically in JavaScript) are small programs that can be embedded using the script element or using event handler content attributes. For example, here is a form with a script that sets the value of the form's output element to say "Hello World":

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

DOM 트리에서 각각의 요소는 객체 형태이고, 이러한 객체는 API를 통해 제어할 수 있습니다. 예를 들어, 링크는 "href" 속성을 다양한 방법으로 변경할 수 있습니다.

Each element in the DOM tree is represented by an object, and these objects have APIs so that they can be manipulated. For instance, a link (e.g. the a element in the tree above) can have its "href" attribute changed in several ways:

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

DOM 트리는, 구현자(특히, 웹 브라우저 처럼 상호작용이 가능한)에 의해 처리되고 표현되었을 때 HTML 문서를 형성하기 위해 사용되는 것이므로, 이 명세는 대부분 위에서 설명된 마크업 대신 DOM 트리의 관점에서 서술하게 될 것입니다.

Since DOM trees are used as the way to represent HTML documents when they are processed and presented by implementations (especially interactive implementations like Web browsers), this specification is mostly phrased in terms of DOM trees, instead of the markup described above.


HTML 문서는 대화형 컨텐츠를 매체에 독립적인 방법으로 표현합니다. HTML 문서는 화면에 그릴 수도 있고, 음성 리더기를 통해 읽을 수도 있으며, 점자 표시기에 표시할 수도 있습니다. 이러한 각각의 렌더링이 정확하게 이루어지게 하기 위해서는 CSS와 같은 스타일 언어를 사용할 수 있습니다.

HTML documents represent a media-independent description of interactive content. HTML documents might be rendered to a screen, or through a speech synthesizer, or on a braille display. To influence exactly how such rendering takes place, authors can use a styling language such as CSS.

다음의 예제 페이지는 CSS를 통해 푸른 바탕 위에 노란색으로 표현될 것입니다.

In the following example, the page has been made yellow-on-blue using CSS.

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

HTML 문서를 어떻게 사용할 것인지 좀 더 알고 싶다면 교습서나 가이드를 사용할 것을 권합니다. 이 명세에 포함된 예제들이 유용할 수도 있지만, 초급 저자는 이 명세가, 필요에 의해, 처음부터 이해하기에는 어려운 레벨에서 언어를 정의하고 있음을 유념해야 합니다.

For more details on how to use HTML, authors are encouraged to consult tutorials and guides. Some of the examples included in this specification might also be of use, but the novice author is cautioned that this specification, by necessity, defines the language with a level of detail that might be difficult to understand at first.

1.9 저자들이 지켜야 할 요구사항

This section is non-normative.

이전 버전들과는 다르게, 이 명세는 잘못된 문서를 처리하는 과정 역시 어느 정도 자세하게 정의하고 있습니다.

Unlike previous versions of the HTML specification, this specification defines in some detail the required processing for invalid documents as well as valid documents.

비록 잘못된 컨텐츠라도 잘 정의된 로직으로 대부분 처리할 수 있지만, 문서에 대한 요구사항은 여전히 중요합니다. 사실, 모든 사용자 에이전트가 특정 컨텐츠를 믿을만하고 이상적인, 혹은 그에 버금가는 방향으로 처리하는 상호운용성이 문서에 대한 요구사항의 유일한 목적인 것은 아닙니다. 이 섹션은 올바른 문서역주와 에러를 포함한 문서들을 구분하는 좀 더 상식적인 이유를 다룹니다.

However, even though the processing of invalid content is in most cases well-defined, conformance requirements for documents are still important: in practice, interoperability (the situation in which all implementations process particular content in a reliable and identical or equivalent way) is not the only goal of document conformance requirements. This section details some of the more common reasons for still distinguishing between a conforming document and one with errors.

1.9.1 표현적 마크업

This section is non-normative.

HTML의 기존 버전에서 비롯된 표현적인 기능은 더는 허용되지 않습니다. 표현적인 마크업은 여러 가지 문제들을 갖는 것으로 판명되었습니다.

The majority of presentational features from previous versions of HTML are no longer allowed. Presentational markup in general has been found to have a number of problems:

표현적인 요소의 사용은 접근성을 저해합니다. The use of presentational elements leads to poorer accessibility

보조 기술의 도움을 받는 사용자에게 받아들일 만한 경험을 제공하는 방향으로 표현적 마크업을 사용(예를 들어, ARIA를 이용해서)하는 것이 가능하기는 하지만, 그렇게 하는 것은 의미에 따라 적합한 마크업을 사용하는 것에 비해 무척 어렵습니다. 이에 더해, 보조기술의 도움을 받지 못하며 그래픽 에이전트를 사용하지 않는 사람에게는 그러한 테크닉 조차 도움이 되지 못합니다.

While it is possible to use presentational markup in a way that provides users of assistive technologies (ATs) with an acceptable experience (e.g. using ARIA), doing so is significantly more difficult than doing so when using semantically-appropriate markup. Furthermore, even using such techniques doesn't help make pages accessible for non-AT non-graphical users, such as users of text-mode browsers.

반면에, 매체에 독립적인 마크업을 사용하면 더 많은 사용자에게 다가서는 방향으로 문서를 저작할 수 있습니다.

Using media-independent markup, on the other hand, provides an easy way for documents to be authored in such a way that they work for more users (e.g. text browsers).

더 높은 유지비용 Higher cost of maintenance

스타일을 독립적인 마크업으로 구축된 사이트를 운영하기는 무척 쉽습니다. 예를 들어, <font color=""> 같은 마크업을 사이트 전체에 걸쳐 사용한 경우에 그 사이트의 색상을 바꾸는 경우를 생각해 보십시오. CSS에 기반을 둔 사이트는 단 하나의 파일을 변경함으로써 작업을 완료하게 될 것입니다.

It is significantly easier to maintain a site written in such a way that the markup is style-independent. For example, changing the color of a site that uses <font color=""> throughout requires changes across the entire site, whereas a similar change to a site based on CSS can be done by changing a single file.

문서 크기의 비대화 Higher document sizes

표현적 마크업은 훨씬 더 방대해지는 경향이 있으며, 따라서 문서 크기가 커지는 결과를 낳게 됩니다.

Presentational markup tends to be much more redundant, and thus results in larger document sizes.

그러한 이유에 따라, 이 버전의 HTML에서는 표현적 마크업이 제거되었습니다. 이러한 변화에 놀라워해서는 안됩니다. HTML4는 이미 여러 해 전부터 표현적 마크업의 사용을 지양해 왔으며 그러한 표현적 마크업에서 벗어날 수 있는 호환 모드를 제공해 왔습니다. 그 후, XHTML 1.1은 더 나아가 그러한 기능을 배제하였습니다.

For those reasons, presentational markup has been removed from HTML in this version. This change should not come as a surprise; HTML4 deprecated presentational markup many years ago and provided a mode (HTML4 Transitional) to help authors move away from presentational markup; later, XHTML 1.1 went further and obsoleted those features altogether.

HTML에 남아 있는 유일한 표현적 마크업 기능은 style 속성과 style 요소입니다. 실무에서 style 속성을 쓰는 것은 지양해야 하지만, 빠르게 문서의 프로토타입을 작성하기엔 유용할 수 있습니다. 그리고 그러한 스타일 규칙은 이후 쉽게 외부 스타일시트로 옮길 수 있습니다. 또한, 별도의 스타일 시트를 사용하는 것이 적절치 않을 때 사용할 수 있을 것입니다. 흡사하게, style 요소는 배포syndication 또는 페이지 고유 스타일에 유용할 수 있습니다. 그러나 일반적으로 외부 스타일 시트를 사용하는 편이, 스타일을 여러 페이지에 적용하려 할 때 유용할 것입니다.

The only remaining presentational markup features in HTML are the style attribute and the style element. Use of the style attribute is somewhat discouraged in production environments, but it can be useful for rapid prototyping (where its rules can be directly moved into a separate style sheet later) and for providing specific styles in unusual cases where a separate style sheet would be inconvenient. Similarly, the style element can be useful in syndication or for page-specific styles, but in general an external style sheet is likely to be more convenient when the styles apply to multiple pages.

다음 네 개의 요소는 기존에는 표현적이었지만 이 명세에서 매체에 독립적이 되도록 다시 정의된 것 역시 유념해 둘 만한 것입니다 : b, i, hr, s, small

It is also worth noting that some elements that were previously presentational have been redefined in this specification to be media-independent: b, i, hr, s, and small.

1.9.2 문법 오류

This section is non-normative.

HTML의 문법은 많은 범주의 문제들을 피하려고 제한되는 부분이 있습니다.

The syntax of HTML is constrained to avoid a wide variety of problems.

이해하기 어려운 에러 핸들링 경향 Unintuitive error-handling behavior

몇몇 잘못된 문법 구조는, 파싱되었을 경우 DOM 트리를 대단히 이해하기 어렵게 만듭니다.

Certain invalid syntax constructs, when parsed, result in DOM trees that are highly unintuitive.

다음의 마크업은 DOM 내부에서 hr 요소가 대응하는 table 요소의 앞 형제 요소가 되게 만듭니다.

For example, the following markup fragment results in a DOM with an hr element that is an earlier sibling of the corresponding table element:

<table><hr>...
선택적 에러 복구가 필요한 에러 Errors with optional error recovery

사용자 에이전트가 기이하고 대단히 난해한 에러 처리 규칙들을 만들어내야 하는 상황을 피하고자, 파싱 에러를 만날 때 중지하는 것을 허용합니다.

To allow user agents to be used in controlled environments without having to implement the more bizarre and convoluted error handling rules, user agents are permitted to fail whenever encountering a parse error.

스트리밍 사용자 에이전트에서 에러 핸들링 규칙이 적합치 않게 만드는 에러 Errors where the error-handling behavior is not compatible with streaming user agents

몇 가지 에러처리 규칙들, 예를 들어 위에서 언급한 <table><hr>...과 같은 마크업에 대한 에러처리 규칙은 스트리밍 사용자 에이전트에는 적합하지 않습니다. 그러한 사용자 에이전트에서 상호운용성 문제를 방지하기 위해, 위와 같은 상황을 만드는 모든 문법은 잘못된 것으로 간주합니다.

Some error-handling behavior, such as the behavior for the <table><hr>... example mentioned above, are incompatible with streaming user agents (user agents that process HTML files in one pass, without storing state). To avoid interoperability problems with such user agents, any syntax resulting in such behavior is considered invalid.

추상화된 데이터셋을 강제하는 에러들 Errors that can result in infoset coercion

XML에 기반을 둔 사용자 에이전트가 HTML 처리기에 연결되었을 때, XML에서 강제하는 특정 불변량 - 예를 들어 두 개의 연이은 하이픈을 포함하지 않는 주석과 같은 - 은 HTML 파일의 규칙을 위반하게 됩니다. 이러한 경우를 해결하기 위해서는 파서가 HTML DOM을 XML에 호환되는 추상화된 데이터세트로 강제할 필요가 있습니다. 그러한 상황을 만들어내는 문법 구조는 대부분 잘못된 것으로 간주합니다.

When a user agent based on XML is connected to an HTML parser, it is possible that certain invariants that XML enforces, such as comments never containing two consecutive hyphens, will be violated by an HTML file. Handling this can require that the parser coerce the HTML DOM into an XML-compatible infoset. Most syntax constructs that require such handling are considered invalid.

불균형하게 성능 하락을 일으키는 에러들 Errors that result in disproportionally poor performance

몇몇 문법 구조는 불균형하게 성능 하락을 일으킬 수 있습니다. 그러한 구조를 피하고자, 그런 구조는 보통 요구사항을 위반하는 것으로 정의합니다.

Certain syntax constructs can result in disproportionally poor performance. To discourage the use of such constructs, they are typically made non-conforming.

다음의 마크업은 성능에 악영향을 끼칩니다. 종료되지 않은 i 요소를 문단마다 재구성해야 하므로, 각각의 문단마다 요소의 숫자가 늘어나게 됩니다.

For example, the following markup results in poor performance, since all the unclosed i elements have to be reconstructed in each paragraph, resulting in progressively more elements in each paragraph:

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

DOM은 이렇게 구성될 것입니다.

The resulting DOM for this fragment would be:

  • p
    • i
      • #text: He dreamt.
  • p
    • i
      • i
        • #text: He dreamt that he ate breakfast.
  • p
    • i
      • i
        • i
          • #text: Then lunch.
  • p
    • i
      • i
        • i
          • i
            • #text: And finally dinner.
깨지기 쉬운 문법 구조와 관련된 에러들 Errors involving fragile syntax constructs

과거에서부터 이어져 온 이유 때문에, 상대적으로 취약한 문법 구조들이 존재합니다. 사용자들이 예기치 못하게 그러한 문제에 빠지는 경우를 방지하기 위해, 그러한 구조는 요구사항을 충족하지 못하는 것으로 정의됩니다.

There are syntax constructs that, for historical reasons, are relatively fragile. To help reduce the number of users who accidentally run into such problems, they are made non-conforming.

속성에 사용된 특정 문자참조에서 종료 세미콜론이 생략되었는데도 파싱되는 경우가 있습니다. 글자들이 명명된 문자참조를 형성하지 않는 때에는 그 앞에 &가 포함되어도 안전합니다. 하지만, 글자들이 명명된 문자참조를 형성하도록 바뀐다면 그 문자로 해석될 것입니다.

For example, the parsing of certain named character references in attributes happens even with the closing semicolon being omitted. It is safe to include an ampersand followed by letters that do not form a named character reference, but if the letters are changed to a string that does form a named character reference, they will be interpreted as that character instead.

이 예제에서 속성의 값은 "?bill&ted" 입니다.

In this fragment, the attribute's value is "?bill&ted":

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

그러나, 다음의 예제에서는, 속성의 값이 원래는 "?art&copy" 가 되도록 의도하였지만 "?art©"가 사용될 것입니다. 역주

In the following fragment, however, the attribute's value is actually "?art©", not the intended "?art&copy":

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

이러한 문제를 방지하기 위하여, 모든 명명된 문자참조는 종료 세미콜론을 가져야 합니다. 따라서 명명된 문자참조를 사용하면서 종료 세미콜론을 생략하는 것은 에러로 간주합니다.

To avoid this problem, all named character references are required to end with a semicolon, and uses of named character references without a semicolon are flagged as errors.

즉, 위의 올바른 표현은 :

Thus, the correct way to express the above cases is as follows:

<a href="?bill&ted">Bill and Ted</a> <!-- &ted is ok, since it's not a named character reference -->
<a href="?art&amp;copy">Art and Copy</a> <!-- the & has to be escaped, since &copy is a named character reference -->
구형 사용자 에이전트에서 이미 알려진 상호운용성 문제를 발생시키는 에러들 Errors involving known interoperability problems in legacy user agents

특정한 문법 구조는 구형 사용자 에이전트에서 특별히 미묘한, 혹은 심각한 문제들을 발생시키는 것으로 알려졌습니다. 따라서 이러한 구조는 올바르지 않은 것으로 간주합니다.

Certain syntax constructs are known to cause especially subtle or serious problems in legacy user agents, and are therefore marked as non-conforming to help authors avoid them.

속성에 따옴표 처리를 하지 않았을 때 U+0060 `문자를 허용하지 않는 것은 이러한 이유 때문입니다. 특정 구형 사용자 에이전트 - IE - 에서는, 이 문자가 간혹 따옴표로 취급됩니다.

For example, this is why the U+0060 GRAVE ACCENT character (`) is not allowed in unquoted attributes. In certain legacy user agents, it is sometimes treated as a quote character.

이것의 다른 예는 비 쿽스 모드를 발생시키기 위해 사용된 DOCTYPE 입니다. 구형 사용자 에이전트들이 쿽스 모드에서 취하는 경향은 거의 문서화되어 있지 않습니다.

Another example of this is the DOCTYPE, which is required to trigger no-quirks mode, because the behavior of legacy user agents in quirks mode is often largely undocumented.

저자들을 보안 문제에 노출하는 에러들 Errors that risk exposing authors to security attacks

몇몇 제한점은 순수하게 보안 문제를 방지하기 위해 존재합니다.

Certain restrictions exist purely to avoid known security problems.

예를 들어, UTF-7 을 제한하는 것은, 그것을 사용한 크로스 사이트 스크립팅 공격에 당하는 것을 막기 위해서입니다.

For example, the restriction on using UTF-7 exists purely to avoid authors falling prey to a known cross-site-scripting attack using UTF-7.

저자의 의도가 불분명한 경우 Cases where the author's intent is unclear

저자의 의도가 매우 모호한 마크업은 종종 에러로 간주합니다. 이러한 에러를 수정하면 이후 유지관리가 쉬워집니다.

Markup where the author's intent is very unclear is often made non-conforming. Correcting these errors early makes later maintenance easier.

이렇게 마크업하면 h1 헤딩을 의도했는지, 아니면 h2 헤딩을 의도했는지 불분명합니다.

For example, it is unclear whether the author intended the following to be an h1 heading or an h2 heading:

<h1>Contact details</h2>
오타로 짐작되는 경우들 Cases that are likely to be typos

간단한 오타를 일찍 발견할 수 있다면 디버깅 시간을 대폭 단축할 수 있을 것입니다. 따라서 이 명세에서는 정의되지 않은 요소명과 속성명 등을 사용하는 것을 보통 에러로 간주합니다.

When a user makes a simple typo, it is helpful if the error can be caught early, as this can save the author a lot of debugging time. This specification therefore usually considers it an error to use element names, attribute names, and so forth, that do not match the names defined in this specification.

<caption> 대신 <capton>으로 입력하였을 경우, 이것은 에러로 표시되며 저자는 오타를 즉시 발견할 수 있을 것입니다.

For example, if the author typed <capton> instead of <caption>, this would be flagged as an error and the author could correct the typo immediately.

미래에 사용될 새로운 문법과 간섭하게 될 가능성이 있는 에러들 Errors that could interfere with new syntax in the future

언어의 문법이 미래에 확장될 수 있도록, 몇몇 기능은 그것이 딱히 해롭지 않아도 금지합니다.

In order to allow the language syntax to be extended in the future, certain otherwise harmless features are disallowed.

종료 태그에서 속성을 사용하는 것은 현재는 무시되고 있지만 잘못된 것인데, 미래에 그러한 문법을 사용하게 되면 혼란을 일으킬 것이기 때문입니다. 언어의 확장은 이미 배포된(그리고 올바른) 컨텐츠들과 충돌하지 않게 설계되었는데도 말입니다.

For example, "attributes" in end tags are ignored currently, but they are invalid, in case a future change to the language makes use of that syntax feature without conflicting with already-deployed (and valid!) content.

몇몇 저자는 HTML 문법의 유연함보다, 모든 속성에 따옴표를 사용하고, 항상 선택적 태그를 포함하는 등의 습관을 한결같이 지키는 것이 더 도움이 된다고 판단합니다. 그러한 저자들을 지원하기 위해, 유효성 검사기는 그러한 관습을 강제하는 모드를 사용할 수 있습니다.

Some authors find it helpful to be in the practice of always quoting all attributes and always including all optional tags, preferring the consistency derived from such custom over the minor benefits of terseness afforded by making use of the flexibility of the HTML syntax. To aid such authors, conformance checkers can provide modes of operation wherein such conventions are enforced.

1.9.3 내용 모델과 속성값에 대한 제한들

This section is non-normative.

언어의 문법 이면에서, 이 명세는 요소와 속성을 명시하는 방법에 제한을 두고 있습니다. 이러한 제한은 비슷한 이유에서 기인합니다:

Beyond the syntax of the language, this specification also places restrictions on how elements and attributes can be specified. These restrictions are present for similar reasons:

불확실한 의미의 컨텐츠에 관계된 에러들 Errors involving content with dubious semantics

이미 정의된 의미를 가진 요소들이 잘못 사용되는 것을 막기 위해, 요소들이 불확실한 중첩을 취하게 되는 것을 제한할 수 있도록 컨텐츠 모델을 정의합니다.

To avoid misuse of elements with defined meanings, content models are defined that restrict how elements can be nested when such nestings would be of dubious value.

이 명세는 section 요소가 kbd 요소 내부에 있는 것을 허용하지 않습니다. 섹션 전체를 타이핑해야 한다고 생각하는 저자는 아마도 없을 것입니다.

For example, this specification disallows nesting a section element inside a kbd element, since it is highly unlikely for an author to indicate that an entire section should be keyed in.

표현된 의미에 혼란을 일으키는 에러 Errors that involve a conflict in expressed semantics

흡사하게, 저자들이 요소의 사용에서 실수하지 않도록 주의를 환기하기 위해, 명백하게 모순되도록 표현된 의미는 에러로 간주합니다.

Similarly, to draw the author's attention to mistakes in the use of elements, clear contradictions in the semantics expressed are also considered conformance errors.

다음의 마크업은 상식적이지 못합니다. 행은 동시에 셀이 될 수 없고, 라디오버튼이 진척 막대가 될 수도 없습니다.

In the fragments below, for example, the semantics are nonsensical: a row cannot simultaneously be a cell, nor can a radio button be a progress bar.

<tr role="cell">
<input type=radio role=progressbar>

다른 예는 ul 요소에서 내용 모델의 제한입니다. ul 요소는 li 자식 요소만을 허용합니다. 목록은 0 또는 그 이상의 아이템들로 구성되도록 정의되었습니다. 따라서 ul 요소가 li 요소 이외의 것을 포함한다면, 의도하는 바가 분명치 않은 것입니다.

Another example is the restrictions on the content models of the ul element, which only allows li element children. Lists by definition consist just of zero or more list items, so if a ul element contains something other than an li element, it's not clear what was meant.

기본 스타일시트로 표현되었을 때 혼란을 일으킬 것으로 짐작되는 경우들 Cases where the default styles are likely to lead to confusion

몇몇 요소는 스타일이나 행동에 대한 기본값을 가집니다. 이러한 기본값이 특정한 방법으로 조합된다면 혼란을 일으킬 가능성이 있습니다. 그러한 문제를 발생시키지 않을 수 있는 같은 요소가 있다면 혼란스러운 조합은 허용되지 않습니다.

Certain elements have default styles or behaviors that make certain combinations likely to lead to confusion. Where these have equivalent alternatives without this problem, the confusing combinations are disallowed.

div 요소는 블럭 박스로 렌더링 되며, span 요소는 인라인 박스로 렌더링 됩니다. 인라인 박스 내부에 블럭 박스를 넣는 것은 불필요한 혼란을 일으킵니다. divdiv를 넣는 것, divspan을 넣는 것, 또는 spanspan을 넣는 것은 모두 spandiv를 넣는 것과 같은 목적을 수행하게 됩니다. 그리고 오직 spandiv를 넣는 것만이 블럭 박스를 인라인 박스에 넣는 문제와 연관되므로, 이것은 허용되지 않습니다.

For example, div elements are rendered as block boxes, and span elements as inline boxes. Putting a block box in an inline box is unnecessarily confusing; since either nesting just div elements, or nesting just span elements, or nesting span elements inside div elements all serve the same purpose as nesting a div element in a span element, but only the latter involves a block box in an inline box, the latter combination is disallowed.

대화형 컨텐츠의 중첩에 관한 제한을 다른 예로 들 수 있습니다. button 요소는 textarea 요소를 포함할 수 없습니다. 이러한 포함 구조에서는 요소의 기본적인 행동 경향이 사용자들에게 많은 혼란을 일으킬 것입니다. 이러한 요소는 포함관계가 아니라 병렬로 배치해야 합니다.

Another example would be the way interactive content cannot be nested. For example, a button element cannot contain a textarea element. This is because the default behavior of such nesting interactive elements would be highly confusing to users. Instead of nesting these elements, they can be placed side by side.

이 명세를 올바르게 이해하지 못했음을 나타내는 에러 Errors that indicate a likely misunderstanding of the specification

때때로, 무언가를 허용함으로써 다른 혼란을 일으킬 가능성이 있기에 금지하는 경우가 있습니다.

Sometimes, something is disallowed because allowing it would likely cause author confusion.

disabled 속성에 "false" 값을 사용할 수 없습니다. 이것은 마치 요소가 활성화되었음을 의미하는 것처럼 보이지만, 사실은 그 요소는 비활성 상태입니다. (중요한 것은 그 속성이 존재한다는 사실이지 그 값이 아닙니다.)

For example, setting the disabled attribute to the value "false" is disallowed, because despite the appearance of meaning that the element is enabled, it in fact means that the element is disabled (what matters for implementations is the presence of the attribute, not its value).

단순화를 위한 단순화에 대한 제한들 Errors involving limits that have been imposed merely to simplify the language

몇몇 오류는 그것을 지적함으로써 저자들이 언어를 배우는 과정을 단순하게 만들어 줍니다.

Some conformance errors simplify the language that authors need to learn.

area 요소의 shape 속성은 circcircle 모두를 같은 값으로서 인식합니다. 하지만 circ 란 값은 허용되지 않는데, 교습서나 기타 학습 도구들을 단순화시키기 위함입니다. 두 개를 다 허용해서 생기는 이점은 없고, 이를 가르칠 때 혼란이 일어날 것입니다.

For example, the area element's shape attribute, despite accepting both circ and circle values in practice as synonyms, disallows the use of the circ value, so as to simplify tutorials and other learning aids. There would be no benefit to allowing both, but it would cause extra confusion when teaching the language.

파서의 특이함에 관련된 에러들 Errors that involve peculiarities of the parser

특정 요소는 조금 별난 방향으로(대개는 호환성 때문에) 파싱됩니다. 그러한 컨텐츠 모델에 대한 제한은 저자들이 그러한 이슈에 노출되는 것을 막기 위함입니다.

Certain elements are parsed in somewhat eccentric ways (typically for historical reasons), and their content model restrictions are intended to avoid exposing the author to these issues.

form 요소를 구문 컨텐츠 내부에 쓸 수는 없습니다. 왜냐하면, 이것을 파싱할때 form 요소의 시작 태그는 p 요소의 종료 태그를 암시하기 때문입니다. 따라서, 다음의 마크업은 하나의 문단이 아니라 두 개의 문단을 만들게 됩니다:

For example, a form element isn't allowed inside phrasing content, because when parsed as HTML, a form element's start tag will imply a p element's end tag. Thus, the following markup results in two paragraphs, not one:

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

이것은 정확히 아래와 같이 파싱됩니다.

It is parsed exactly like the following:

<p>Welcome. </p><form><label>Name:</label> <input></form>
디버깅하기 어려운 스크립트를 만들게 될 에러들 Errors that would likely result in scripts failing in hard-to-debug ways

몇몇 에러는 디버깅하기 어려운 스크립트 문제를 방지하기 위해 의도되었습니다.

Some errors are intended to help prevent script problems that would be hard to debug.

예를 들자면, 이것이, 두 개의 id 속성이 같은 값을 갖지 못하게 하는 원인입니다. 중복된 id는 잘못된 요소를 선택하게 만들고, 의도를 파악하지 못하게 되어 재난에 가까운 영향을 미칩니다.

This is why, for instance, it is non-conforming to have two id attributes with the same value. Duplicate IDs lead to the wrong element being selected, with sometimes disastrous effects whose cause is hard to determine.

저작 시간을 낭비하게 하는 에러들 Errors that waste authoring time

몇몇 구조는 전통적으로 많은 시간 낭비를 일으켰기 때문에 불허됩니다. 이러한 구조를 사용하지 않도록 강제함으로써 저자들이 시간을 아낄 수 있습니다.

Some constructs are disallowed because historically they have been the cause of a lot of wasted authoring time, and by encouraging authors to avoid making them, authors can save time in future efforts.

script 요소의 src 속성은 요소의 (태그로 감싸인) 내용이 무시되도록 만듭니다. 그러나 이러한 무시는 분명하지는 않은데, 특히 요소의 (태그로 감싸인) 내용이 마치 실행될 스크립트처럼 보일 때 더 그러합니다. 이러한 경우, 인라인 스크립트가 실행되지 않을 것이란 점을 의식하지 못한 채 그것을 디버깅하기 위해 엄청난 시간을 낭비하게 될 가능성이 있습니다. 이러한 문제를 덜어 주기 위해, 이 명세에서는 src 속성을 갖는 script 요소가 (태그로 감싸인) 내용을 갖는 것은 에러로 간주합니다. 결과적으로 자신의 문서를 검사하면서 이런 종류의 실수 때문에 시간을 낭비하지 않게 될 것입니다.

For example, a script element's src attribute causes the element's contents to be ignored. However, this isn't obvious, especially if the element's contents appear to be executable script — which can lead to authors spending a lot of time trying to debug the inline script without realizing that it is not executing. To reduce this problem, this specification makes it non-conforming to have executable script in a script element when the src attribute is present. This means that authors who are validating their documents are less likely to waste time with this kind of mistake.

XHTML로, 혹은 XHTML에서 이주하는 저자들에게 영향을 미칠 에러들 Errors that involve areas that affect authors migrating to and from XHTML

몇몇 저자는 XML로도, HTML로도 해석될 수 있으며 또한 비슷한 결과를 가지게끔 파일을 작성하는 경향이 있습니다. 이러한 시도는 무수히 많은 심각한 합병증(특히 이것이 스크립팅, 스타일링, 기타 자동화된 직렬화와 연관된 경우)을 일으킬 가능성이 있기 때문에 지양되어야 합니다. 그럼에도 이 명세는 이러한 어려움을 조금이라도 완화할 의도로 적은 수의 제한을 하고 있습니다. 이것은 저자들이 HTML과 XHTML 사이를 이주할 때 단계적인 지침으로 사용하기 좀 더 쉽게 할 것입니다.

Some authors like to write files that can be interpreted as both XML and HTML with similar results. Though this practice is discouraged in general due to the myriad of subtle complications involved (especially when involving scripting, styling, or any kind of automated serialization), this specification has a few restrictions intended to at least somewhat mitigate the difficulties. This makes it easier for authors to use this as a transitionary step when migrating between HTML and XHTML.

lang 속성과 xml:lang 속성이 동기화된 상태를 유지하기 위해 약간 복잡하게 되어 버린 규칙이 있습니다.

For example, there are somewhat complicated rules surrounding the lang and xml:lang attributes intended to keep the two synchronized.

다른 예는 HTML 직렬화에서 xmlns 속성의 값을 제한하는 것이 될 수 있습니다. 이러한 제한은 문서가 올바르다면 HTML로 파싱되든, XML로 파싱되든 요소가 같은 네임스페이스 안에 있도록 하기 위함입니다.

Another example would be the restrictions on the values of xmlns attributes in the HTML serialization, which are intended to ensure that elements in conforming documents end up in the same namespaces whether processed as HTML or XML.

이후의 확장을 위해 예약된 영역에 관련된 에러들 Errors that involve areas reserved for future expansion

언어의 추후 개정판에서 새로운 문법을 허용하기 위한 몇 가지 제한 사항이 있습니다. 요소의 컨텐츠 모델, 속성의 값에 대한 몇 가지 제한은 이러한 이유로 만들어졌습니다.

As with the restrictions on the syntax intended to allow for new syntax in future revisions of the language, some restrictions on the content models of elements and values of attributes are intended to allow for future expansion of the HTML vocabulary.

target 속성의 값을 U+005F 밑줄문자 (_)로 시작하는 미리 정의된 예약어로만 허용하는 것은, 저자들이 정의하는 커스텀 값과 이후 확장이 충돌하는 상황을 예방하기 위함입니다.

For example, limiting the values of the target attribute that start with an U+005F LOW LINE character (_) to only specific predefined values allows new predefined values to be introduced at a future time without conflicting with author-defined values.

다른 명세의 잘못된 사용을 지적하는 에러 Errors that indicate a mis-use of other specifications

몇 가지 제한사항은 다른 명세에서 만들어진 제한을 지원하려는 의도입니다.

Certain restrictions are intended to support the restrictions made by other specifications.

예를 들어 미디어 쿼리를 받는 속성들이 유효한 미디어 쿼리들만을 받도록 강제하는 것은 그 명세의 요구사항이 중요함을 강화하고 있습니다.

For example, requiring that attributes that take media queries use only valid media queries reinforces the importance of following the conformance rules of that specification.

This section is non-normative.

The following documents might be of interest to readers of this specification.

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

This Architectural Specification provides authors of specifications, software developers, and content developers with a common reference for interoperable text manipulation on the World Wide Web, building on the Universal Character Set, defined jointly by the Unicode Standard and ISO/IEC 10646. Topics addressed include use of the terms 'character', 'encoding' and 'string', a reference processing model, choice and identification of character encodings, character escaping, and string indexing.

Unicode Security Considerations [UTR36]

Because Unicode contains such a large number of characters and incorporates the varied writing systems of the world, incorrect usage can expose programs or systems to possible security attacks. This is especially important as more and more products are internationalized. This document describes some of the security considerations that programmers, system analysts, standards developers, and users should take into account, and provides specific recommendations to reduce the risk of problems.

Web Content Accessibility Guidelines (WCAG) 2.0 [WCAG]

Web Content Accessibility Guidelines (WCAG) 2.0 covers a wide range of recommendations for making Web content more accessible. Following these guidelines will make content accessible to a wider range of people with disabilities, including blindness and low vision, deafness and hearing loss, learning disabilities, cognitive limitations, limited movement, speech disabilities, photosensitivity and combinations of these. Following these guidelines will also often make your Web content more usable to users in general.

Authoring Tool Accessibility Guidelines (ATAG) 2.0 [ATAG]

This specification provides guidelines for designing Web content authoring tools that are more accessible for people with disabilities. An authoring tool that conforms to these guidelines will promote accessibility by providing an accessible user interface to authors with disabilities as well as by enabling, supporting, and promoting the production of accessible Web content by all authors.

User Agent Accessibility Guidelines (UAAG) 2.0 [UAAG]

This document provides guidelines for designing user agents that lower barriers to Web accessibility for people with disabilities. User agents include browsers and other types of software that retrieve and render Web content. A user agent that conforms to these guidelines will promote accessibility through its own user interface and through other internal facilities, including its ability to communicate with other technologies (especially assistive technologies). Furthermore, all users, not just users with disabilities, should find conforming user agents to be more usable.

Polyglot Markup: HTML-Compatible XHTML Documents [POLYGLOT]

A document that uses polyglot markup is document that is a stream of bytes that parses into identical document trees (with the exception of the xmlns attribute on the root element) when processed as HTML and when processed as XML. Polyglot markup that meets a well defined set of constraints is interpreted as compatible, regardless of whether they are processed as HTML or as XHTML, per the HTML5 specification. Polyglot markup uses a specific DOCTYPE, namespace declarations, and a specific case — normally lower case but occasionally camel case — for element and attribute names. Polyglot markup uses lower case for certain attribute values. Further constraints include those on empty elements, named entity references, and the use of scripts and style.

이 번역에서 올바른 문서라고 옮긴 것은 명세의 요구사항을 지키는 문서. conforming document 입니다. 돌아가기

&copy 가 © 로 바뀌어버린 것입니다. &ted 에 해당하는 문자참조는 존재하지 않기 때문에 앞의 예제에선 이러한 치환이 일어나지 않았습니다. 돌아가기