HTML5
HTML과 XHTML을 위한 어휘와 관련 API
HTML과 XHTML을 위한 어휘와 관련 API
이 절은 표준에 준하는 내용이 아닙니다.
월드 와이드 웹 마크업 언어는 HTML입니다. 긴 시간에 이른 HTML의 설계와 개선은 HTML을 활용해 여러 형식의 문서를 기술할 수 있도록 하였지만, HTML은 본래 의미에 맞게 과학관련 문서를 기술하기 위한 언어로 설계되었습니다.
HTML에서 적절히 처리하지 못한 주요 영역은 웹 어플리케이션이라 불리는 애매한 문제입니다. 이는 과거 수년간 제기된 문제이며 이를 대응하기 위해 HTML 스펙을 갱신해왔고, 동시에 수정도 진행하고 있습니다.
이 절은 표준에 준하는 내용이 아닙니다.
이 스펙문서는, 이 스펙에서 정의된 기능을 사용하는 문서 및 스크립트 저자를 대상으로 하고있습니다.
이 문서는 쉽기보다는 정확하게, 간결하기 보다는 완전성을 중요시하기 때문에, 웹 기술에 대해 충분한 지식을 가지고 있지 않는 경우에는 맞지 않을 수 있습니다. 쉬운 튜토리얼이나 작성가이드가 HTML5에 더 쉽게 입문할 수 있게 해줄 것입니다.
특히 DOM의 기본을 깨우치는 게, 이 스펙에서 특히 기술적인 몇개의 요소를 완전히 이해하는 데 필요합니다. Web IDL, HTTP, XML, Uncode, 문자 인코딩, JavaScript 및 CSS 이해도 도처에 도움이 되지만 필수는 아닙니다.
이 절은 표준에 준하는 내용이 아닙니다.
이 스펙 문서는 정적 문서에서 동적 어플리케이션을 아우르는, 웹 상에서 접근 가능한 페이지의 시멘틱 레벨 마크업 언어와 관련이 있고, 시멘틱레벨의 스크립트 API를 제공하는 데 한정합니다.
이 스펙 문서의 범위는 외부 미디어에 유효한 커스터마이즈에 대응하는 메커니즘을 제공하지 않습니다. (다만, 웹 브라우저의 기본 렌더링 규칙은 이 스펙 문서의 마지막에 포함하며, 또 CSS를 불러오기 위한 메커니즘을 언어의 일부로써 제공합니다)
이 스펙 문서의 범위는 오퍼레이션 시스템 전체를 기술하지는 않습니다. 구체적으로는 하드웨어 설정 소프트웨어, 이미지 처리 툴, 유저가 매일 고성능 워크스테이션에서 사용하는 게 예상되는 어플리케이션이 범위 밖입니다. 어플리케이션 관점에서 이 스펙 문서는 비정기적인 유저, 또 정기적이지만 낮은 CPU 요건과 함께 다른 장소에서 이용할 가능성이 있는 어플리케이션을 특히 대상으로 합니다. 그런 어플리케이션의 예로는, 온라인 구매 시스템, 검색 시스템, 게임(특히 온라인 게임), 공중전화부나 주소록, 통신 소프트웨어(이메일 클라이언트, 인스턴트 메시지 클라이언트, 디스커션 소프트웨어), 문서편집 소프트웨어를 포함합니다.
이 절은 표준에 준하는 내용이 아닙니다.
최초 5년간(1990-1995) HTML은 여러 개정과 확장을 경험했습니다. 최초에는 CERN에서, 이후엔 IETF에서 호스트했습니다.
W3C 발족과 함께 HTML은 다시 개발의 장을 바꾸었습니다. 1995년 HTML 3.0으로 알려진 초기의 실패로 끝난 HTML을 확장하여 HTML 3.2라 알려진 더 실용적인 접근방법을 통해, 이가 1997년 끝나 HTML4가 같은 해에 바로 이어졌습니다.
수년간 W3C 회원은 HTML5의 발전을 그만두고, 대신 XHTML로 알려진 XML 베이스의 동등물 개발을 착수하기로 결정했습니다. 이로 인해 XML의 HTML4 재정의화를 개시했습니다. 이는, 새로운 직렬화를 제거한 신기능을 추가하지 않는 XHTML 1.0으로 알려져, 2000년 끝났습니다. XHTML 1.0 직후에 W3C의 중심은 XHTML 모듈화로 이어져, XHTML을 확장하는 다른 워킹그룹의 작업을 더 간단히 하는 작업이 많았습니다. 이와 병렬로, W3C는 XHTML2라 불리는, 그 때까지의 HTML이나 XHTML 언어와 상호호환성이 없는 새로운 언어의 개발을 진행하고 있었습니다.
HTML의 진화가 1998년에서 정체하고 있을 때, 브라우저 벤더사에 의해 개발된 HTML을 위한 API 일부가 DOM Level 1 (1998년), DOM Level 2 Core 및 DOM Level 2 HTML(2000년에 시작해 2003년에 절정기)로써 작성되어 발행됩니다. 이러한 대처는 20014년에 발행된 DOM Level 3 스펙 문서와 함께 차츰 약해져, 워킹 그룹은 모든 Level 3 초안을 완료하기 전에 중단하였습니다.
2003년, 차세대 웹 폼으로 자리잡은 기술인 XForms의 공개는 HTML을 대체할 것을 찾기보다 진화하는 HTML에 다시 관심을 가지게 했습니다. 이 관심으로 인해 XML을 전개해나가는 게 실제로 전개된 (HTML 같은) 기술을 대체하는 것이 아닌, 웹 기술로서 (RSS나 이후의 Atom 같은) 새로운 기술에 불과하다는 인식이 생겨나게 됩니다.
기존 HTML 웹 페이지와 호환하지 않는 렌더링 엔진 구현을 브라우저에 요구하지 않고, XForms 1.0에서 도입한 여러 기능을 제공하기 위한 HTML4 폼 확장이 가능하도록 하는 컨셉을 증명함으로써 새로운 관심을 불러들이기 시작하였습니다. 공연히 초안단계의 스펙을 사용할 수 있었으며, 모든 자원을 투입하는 한편 초창기 스펙 문서는 Opera Software에서 지휘하고 있었습니다.
HTML 진화를 재개해야 한다는 의견은 2004년 W3C 워크샵에서 나왔습니다. 여기서 HTML5 작성(후술) 기초 원칙을 세우고, 폼 관련 기능을 커버하는 초안 초기 때 같이, Mozilla와 Opera가 공동으로 W3C에 제안했습니다. 이 제안은 이전 선택한 웹 진화 방향성과 모순하는 것이 있어 기각되었습니다. 대신 W3C 간부와 기업은 XML 베이스의 대체품 발전을 계속하기로 결정했습니다.
그 뒤 얼마 지나지 않아, WHATWG라는 새로운 무대에서 Apple, Mozilla, Opera 공동 작업을 진행하기로 발표했습니다. 공개 메일링 리스트를 생성하고, 초안은 WHATWG 사이트에 올렸습니다. 그 뒤 저작권은 3 벤더 공동 소유하기로 결정하고, 스펙을 다시 이용할 수 있게 했습니다.
WHATWG는 여러 핵심 원칙에 근거합니다. 특히 기술은 스펙이 변하는 것을 의미하더라도 구현은 일치해야할 필요가 있으며, 리버스 엔지니어링 하는 일 없이 완전히 상호 운용성을 가질 수 있어야합니다.
특히 후자는 HTML5의 범위를 HTML4, XHTML1, DOM2 HTML 같은 다른 3개의 문서에서 정의한 내용도 포함하도록 하였습니다. 이는 지금까지 의례적으로 간주했던 것보다 많은 사항을 포함하는 걸 의미합니다.
2006년, 결국 W3C는 HTML5 개발에 참여하는 데 관심을 보여 2007년 HTML5 스펙을 WHATWG와 함께 개발하기 위한 워킹그룹을 설립했습니다. Apple, Mozilla, Opera는 W3C 라이센스 하에 스펙 공개를 허용하고, WHATWG 사이트 버전은 제한이 적은 라이센스를 적용했습니다.
긴 시간에 걸쳐 양 그룹은 Ian Hickson 관리 하에 함께 했습니다. 그런 2011년 양 그룹은 서로 다른 목표를 가지고 있다는 결론에 도달하였습니다. WHATWG는 지속적으로 사양을 유지하고 새로운 기능을 추가하는 HTML Living Standard 작업을 계속하고 싶다는 한편, W3C는 HTML5 권고안으로써의 기능을 일단락하고 싶어했습니다. 2012년 중반 새로운 에디터 팀이 HTML5 권고안 제정을 맡았으며, 다음 버전을 위한 HTML 작업 초안을 W3C에서 준비하기 시작했습니다.
그 이후, W3C HTML 스펙에 등록되어 있는 버그를 해결하였거나, 더 정확하게 유저 에이전트에 구현되어 있는 WHATWG 패치를 W3C 워킹 그룹은 선정하고 있습니다. 이 문서 공개 시점에는 WHATWG HTML 스펙에서 패치 리비젼 8152까지 머지되어있습니다. W3C HTML 에디터는 WHATWG에서 공유하지 않은 버그의 수정을 W3C HTML 워킹 그룹에서 작성한 논의나 결정의 결과로 패치를 추가하고있습니다.
이 문서에서 지정한 HTML과 HTML4 스펙 간 차이점을 제공하는 다른 문서도 제공합니다. [HTMLDIFF]
이 절은 표준에 준하는 내용이 아닙니다.
한 눈에 봤을 때 많은 HTML 특징들이 엉터리며 일관성이 없어보이는 걸 인정해야합니다.
대부분의 HTML, HTML DOM API 지원, HTML을 지원하는 기술은 서로의 존재를 모른채로 다른 우선순위를 가진 많은 사람들에 의해 수십년동안 개발되어왔습니다.
이러한 기능은 많은 곳에서 발생하고 있으며, 일관된 방식으로 설계되어 있지 않습니다. 또한 웹이 가진 특성 중 하나로 버그가 수정되기 전 버그에 의존하는 방식으로, 종종 콘텐츠가 의존하여 사용하기 때문에 구현 버그가 종종 표준이 되는 경우도 이어, 지금은 기관 표준이 되어있습니다.
이런 상황에도 불구하고, 특정한 설계 목표에 집작하려는 시도가 이루어지고 있습니다. 이는 다음 장에서 설명합니다.
이 절은 표준에 준하는 내용이 아닙니다.
웹 저자가 멀티 스레드 처리 복잡성에 관여하는 걸 방지하기 위해, HTML과 DOM API는 스크립트가 다른 스크립트의 동시실행을 감지하지 않도록 설계되어있습니다. 워커와 동일한, 구현 동작이 전부 브라우징 콘텍스트 안에서 모든 스크립트 실행이 직렬화 되어있도록 생각하게 하는 의도입니다.
이 모델에서 navigator.yieldForStorageUpdates() 메소드는 호출 스크립트가 차단되어있는 동안 다른 스크립트가 실행 가능하도록 하는 것과 동일합니다.
이 절은 표준에 준하는 내용이 아닙니다.
이 스펙은 여러 다른 사양과 서로 영향을 주고 의존합니다. 불행히도 특정 상황에서 모순하는 요구사항은 이런 다른 스펙에 속하는 요건 위반을 이 문서에서 가리킵니다. 이 위반이 발생한 때는 언제든지, 위반이 각각 "고의적 위반"으로 언급되며, 위반 이유가 지적당합니다.
이 절은 표준에 준하는 내용이 아닙니다.
HTML은 안전한 방법으로 의미를 부여하는 다양한 확장성 메커니즘을 가지고 있습니다 :
class 속성을 사용할 수 있습니다.
이는 확장 관련 기능을 지원하지 않는 브라우저 및 도구에서도 적절히 지원할 수 있습니다. 이는 마이크로 포맷에서 사용 가능한 정책입니다.
data-*="" 속성을 사용해 처리하기 위한 인라인 클라이언트 스크립트 또는 사이트 전체의 서버사이드 스크립트 데이터를 포함할 수 있습니다.
이는 절대 브라우저에 의해 수정되지 않는 걸 보증하며, 스크립트가 검색 및 실행할 수 있는 HTML 요소가 데이터를 스크립트에 포함하는 걸 허용합니다.
<meta name="" content=""> 매커니즘을 이용할 수 있습니다.
rel="" 매커니즘을 이용할 수 있습니다. 이는 마이크로 포맷에서도 이용합니다.
거기에 더해, ASCII 문자가 아닌 문자를 일절 포함하지 않으며 U+0041（LATIN CAPITAL LETTER A）부터 U+005A（LATIN CAPITAL LETTER Z）범위의 문자를 포함하지 않은 절대 URL은 링크타입으로 사용해도 좋습니다.<script type=""> 매커니즘을 사용해 원시 데이터를 포함할 수 있습니다.embed요소를 이용해 불러오는 게 가능합니다. 이가 Flash의 동작방법입니다.이 절은 표준에 준하는 내용이 아닙니다.
이 스펙문서는 문서나 어플리케이션을 작성하기 위한 추상적인 언어 및 그 언어를 사용하는 리소스의 메모리 내부 표현 및 정보를 교환하기 위한 API를 정의합니다.
메모리 내 표현은 짧게 "DOM HTML" 혹은 "DOM"으로 알려져 있습니다.
이 추상적인 언어를 사용하는 리소스를 보내기 위해 사용할 수 있는 다양한 구체적 구문이 존재하며, 이 스펙 문서에서 정의하는 것이 2개 존재합니다.
첫번째 구문은 HTML 구문입니다. 대부분의 에디터에게 권장하는 형식이며 대부분의 기존 웹 브라우저와 호환합니다.
문서를 text/html MIMEタイプ 타입으로 전송하는 경우 웹 브라우저를 통해 HTML 문서로 처리합니다.
이 스펙 문서에서는 "HTML 5.0"으로 알려진 HTML 구문 버전 5.0을 정의합니다.
두번째 구문은 XML을 응용한 XHTML 구문입니다.
문서가 application/xhtml+xml 같은 XML MIME 타입으로 송신하는 경우 웹 브라우저에서 XML 문서로 처리하여, XML 프로세서로 해석합니다.
에디터는 XML과 HTML 처리가 다름을 주의해야 합니다. 특히 사소한 구문 에러가 XML로 분류 된 문서 렌더링을 중지할 수 있습니다.
이 스펙문서는 "XHTML 5"로 알려진 XHTML 구문 버전 5.0을 정의합니다.
DOM, HTML 구문 및 XHTML 구문은 모두 동일한 내용을 나타내는 게 불가합니다.
예를 들어, name space는 HTML 구문에선 표현 불가하지만, DOM과 XHTML 구문에서는 지원합니다.
마찬가지로 noscript를 사용하는 문서는 HTML 구문으로 표현할 수 있으나,
DOM 및 XHTML 구문으로 표현하는 건 불가합니다.
문자열 "-->"을 포함하는 주석은, HTML과 XHTML 구문에선 나타낼 수 없고,
DOM에서만 나타내는 게 가능합니다.
이 절은 표준에 준하는 내용이 아닙니다.
이 스펙은 아래 주요한 장으로 구성합니다 :
구식 기능 및 IANA 고려 리스트 같은 부록도 존재합니다.
이 스펙 문서는 다른 문서를 읽는 법과 동일하게 읽으면 됩니다. 먼저, 표지부터 끝까지 여러번 읽고, 적어도 1번은 뒤에서부터 읽습니다. 그리고선 콘텐츠 목록에서 무작위로 장을 선택하고, 모든 상호 참조를 따라서 읽어야합니다.
아래의 적합성 요건 장에서 설명하는 바와 같이 이 스펙 문서는 여러 적합성 클래스 적합 기준을 설명하고 있습니다. 구체적으로는 에디터들이 작성한 문서 같이 생산자에게 적용되는 적합성 요구 사항과, 웹 브라우저 같은 소비자에게 적용되는 적합성 요구 사항이 있습니다. 각각은 필요로 하는 것에 의해 구분할 수 있습니다. 생산자에 대한 요구 사항은 허용하는 것에 대한 내용인 반면 소비자에 대한 요구 사항은 어떻게 소프트웨어가 동작해야 하는가에 대한 내용이 많습니다.
예를 들어 허가된 값을 표시하는 "foo속성의 값이 유효한 정수여야만 한다"는 생산자에 대한 요구 사항입니다.
대조적으로 "foo 속성 값은 정수를 위한 구문 분석 규칙을 이용해서 해석해야한다"는 소비자를 대상으로 하는 요구 사항이며, 콘텐츠를 해석하는 방법에 대해 설명하고 있습니다.
생산자에 대한 요구 사항은, 소비자와 전혀 관계 없습니다.
위 예제에 대해 계속 이야기하자면, 특정 속성값이 유효한 정수로써 구속되어있는 요구사항은, 소비자의 요구 사항에 대해 어떤 의미도 가지지 않습니다. 소비자가 실제로 불명확한 문자열로써 속성을 취급하는 걸 요구하여, 그 값이 요구 사항 여부에 준수하는 지에 대해 전혀 영향을 미치지 않습니다. 소배자는, 유효한 (이 경우 숫자가 아닌) 값이 처리되는 방법을 정의하는 특정 규칙을 사용해서 값을 해석하는 것이 (위의 예와 같이) 필요할 수도 있습니다.
이는 정의, 요구 사항, 또는 설명입니다.
참고 사항입니다.
예시입니다.
해결되지 않은 문제입니다.
경고 사항 입니다.
interface Example {
// IDL 정의 입니다.
};
method( [ optionalArgument ] )인터페이스 사용법을 에디터에게 설명하는 참고 사항입니다.
/* CSS 클립입니다 */
용어의 정의 예시는 이렇게 마크업되어 있습니다. 이 용어의 사용은 이렇게나 이렇게 마크업되어 있습니다.
요소, 속성, 또는 API 정의 예시는 이렇게 마크업되어 있습니다. 그 요소, 속성, API의 참조는 이렇게 마크업되어 있습니다.
다른 코드 클립은 이렇게 마크업되어 있습니다.
변수는 이렇게 마크업되어 있습니다.
알고리즘에 대해서는 동기 섹션에서 스텝은 ⌛로 표시되어 있습니다.
경우에 따라서는 요구 조건은 해당 요구사항과 함께 리스트 형태로 주어집니다. 이러한 경우 요구사항에 대응하는 조건이 여러 집합인 경우에도, 조건에 따라 요구사항의 첫번째 집합니다. 다음과 같은 예가 제공됩니다 :
이 절은 표준에 준하는 내용이 아닙니다.
일부 HTML 기능은 유저 프라이버시 보호 대책과 유저의 편리성을 상환합니다.
일반적으로 인터넷 아키텍쳐로 인해 유저 IP 주소로 유저 구별이 가능합니다. IP 주소는 전적으로 사용자와 일치하지 않습니다. 디바이스에서 디바이스로, 네트워크에서 네트워크로 유저가 이동함과 함께 IP 주소 또한 변화합니다. 마찬가지로, NAT 라우팅, 프록시 서버, 공유 컴퓨터는 실제로 여러 유저를 대응하는 단일 IP 주소로 오도록 보이게하는 패킷을 유효하게 합니다. 인터넷 상에서 하나의 노드에서 단일 유저로부터의 리퀘스트는, 네트워크의 여러 다른 부분에서 오는 듯 보이고, 어니언 라우팅 같은 기술은 리퀘스트를 더 익명으로 하기 위해 사용할 수 있습니다.
그러나 유저의 리퀘스트에 사용하는 IP 주소는, 유저의 리퀘스트가 서로 관련이 있을 수 있는 유일한 매커니즘은 아닙니다. 예를 들어 쿠키는 이를 활성화 하기 위해 특별히 설계되어 있으며, 계정이 있는 사이트에서 로그인을 하는 기능의 대부분은 웹 세션에 기초를 둡니다.
더 섬세한 매커니즘이 존재합니다. 유저 시스템의 일부 특성은 유저 그룹을 구별하기 위해 사용할 수 있습니다. 그런 정보를 충분히 수집함으로써 개별 유저 브라우저의 "디지털 지문"은, 더 우수하다 말하지 않아도 될 만큼 좋으며, 리퀘스트가 같은 유저로부터 오는 것인지 확인할 수 있는 IP 주소로 계산 가능합니다.
특히 여러 사이트에서 이 방법으로 그룹화 리퀘스트는 모두에게 유익한 (대부분 문제 없이 긍정적인) 목적뿐만 아니라 악의적인 목적으로도 사용할 수 있습니다. 합리적이고 유익한 목적의 예는, 특정 사람이 고양이 일러스트가 있는 사이트와 강아지 일러스트를 사용한 사이트 중 어느 쪽을 선호하는 지에 대한 여부를 (문제의 사이트를 방문하는 빈도에 따라) 판단하여 자동으로 사이트 재방문 시 우선적인 일러스트를 사용하도록 하는 것입니다. 그러나 악의적인 목적은, 유저가 선거에서 투표하는 것을 방해할지 말지를 결정하기 위한 (참가 포럼 사이트를 조사하여 결정된다) 명확한 소속 정당을 가진 (하나의 사이트 상에서 방향을 특정할 때 이용하는 주소에서 결정됨) 것과 같은 주택주소와 함께 정부기관을 포함할 수도 있습니다.
목적에 따라 악의가 현저히 유해할 수도 있기 때문에, 유저 에이전트 구현 시에 유저에게 익숙해져 있을 정보의 누출을 최소한 하기 위한 툴과 유저에게 제공하는 방법을 고려하는 것이 중요합니다.
아쉽게도 이 장의 첫 단락이 암시하듯, 단순히 모든 가능성 있는 누출을 차단하는 것만큼 간단하지 않기 때문에, 때에 따라서는 지문 채취 목적으로 사용 가능한 정보를 공개함으로써 얻을 수 있는 다양한 이점이 있습니다. 예를 들어 특정 ID로 게시하는 사이트에서 로그인하는 기능은 정의에 따라 많건 적건, 유저의 요구가 모두 동일한 유저로부터 온 것인지 실벽하는 걸 요구합니다. 그러나 더 세밀하게, 어느 정도 큰 텍스트인 정보는 캔버스 상에 텍스트를 그리는데 관련있는 많은 효과 (예를 들어 텍스트 주변에 border를 그리는데 관련한 모든 효과 등)을 필요로 하며, 유저는 리퀘스트를 그룹화하기 위해 사용되는 정보도 유출한다. (이 경우 잠재적으로 공개함으로써, 전력으로 검색을 통해 유저가 설치한 글꼴, 유저에 따라 상당히 변동할 수 있는 정보)
사용자의 지문 채취에 사용되는 가능성이 있는 이 스펙 문서의 기능이 단락에 표시되어있습니다.
플랫폼 안의 다른 기능은, 아래 내용을 포함하더라도 한정되지 않고, 같은 목적에 사용될 수 있습니다:
Screen 객체 같은 유저 환경을 설명하는 기능 [MQ] [CSSOMVIEW]이 절은 표준에 준하는 내용이 아닙니다.
기본적인 HTML 문법은 다음과 같습니다：
<!DOCTYPE html> <html> <head> <title>Sample page</title> </head> <body> <h1>Sample page</h1> <p>This is a <a href="demo.html">simple</a> sample.</p> <!-- this is a comment --> </body> </html>
HTML 문서는 요소와 텍스트 트리로 구성됩니다. 각 요소는 "<body>" 같은 여는 태그와 "</body>" 같은 닫는 태그로 소스에 표시됩니다.（상황에 따라 여는 태그와 닫는 태그는 생략 및 별도 태그에서 표시될 수도 있습니다）
태그는 중복하는 일 없이 그 요소 사이에 완벽히 포함되어 있어야 합니다 :
<p>This is <em>very <strong>wrong</em>!</strong></p>
<p>This <em>is <strong>correct</strong>.</em></p>
이 스펙 문서는 요소의 중첩에 관한 규칙에 따라, HTML에서 사용 가능한 요소의 집합을 정의합니다.
요소는 요소가 동작하는 방법을 제어하는 속성을 가질 수 있습니다.
아래 예시에서는 a요소와 href속성을 사용해서 형성되는 하이퍼 링크가 존재합니다 :
<a href="demo.html">simple</a>
속성은 여는 태그 안에 존재하여 "=" 문자로 구분되는 속성명과 속성값으로 구성됩니다. 속성값이 공백문자 혹은 " ' ` = < >을 포함하지 않는 경우, 속성 값은 따옴 표로 묶지 않은상태가 됩니다. 그렇지 않은 경우, 따옴표나 쌍따옴표 중 하나를 사용해서 따옴표로 묶어야 합니다. 속성 값이 공백문자인 경우 "=" 문자와 함께 속성값을 완전히 생략 가능합니다.
<!-- empty attributes --> <input name=address disabled> <input name=address disabled=""> <!-- attributes with a value --> <input name=address maxlength=200> <input name=address maxlength='200'> <input name=address maxlength="200">
HTML 유저 에이전트 (예를 들면 웹 브라우저)는 이 마크업을 해석하여, 마크업을 DOM(Document Object Model) 트리로 변환시킵니다. DOM 트리는 문서의 메모리 내 표현입니다.
DOM 트리는 여러 종류의 노드를 포함합니다. 구체적으로는 DocumentType 노드, Element 노드, Text 노드, Comment 노드, 때에 따라서는 ProcessingInstruction노드 일 때도 있습니다.
이 절에서 처음 나온 마크업 조각은 아래 DOM 트리로 변환됩니다 :
htmlhtml이 트리의 루트 요소는 html요소입니다. HTML 문서의 루트 요소는 항상 html 요소 입니다.head와 body 두개 요소 뿐만 아니라 Text 노드도 포함합니다.
소스는 DOM 에서 여러개의 공간 （여기서는"␣"로 나타낸다）및Text노드의 마지막 개행（"⏎"）을 포함하기 때문에 최초 기대한 것보다도 DOM 트리에 많은 Text 노드가 있습니다. 그러나, 역시적인 이유로 원래 마크업 안의 빈공간이나 개행 모두 특히 head 여는 태그가 암묵적으로 생략되어 종료하기 전에 모든 공백 및 body 닫는 태그가 생략되어 body 끝에서 종료 후 모든 공백은 DOM에는 표시되지 않습니다.
head요소는, 텍스트 "샘플 페이지"를 가지는 Text 노드를 포함한 title요소를 포함합니다.
마찬가지로 body요소는 h1요소, p요소 및 주석을 포함합니다
이 DOM 트리는 페이지 내의 스크립트로 조작할 수 있습니다.（보통 JavaScript） 스크립트는 script요소를 사용하거나, 이벤트 핸들러 콘텐츠 속성을 사용해서 포함할 수 있는 작은 프로그램입니다. 예를 들어 "Hello World"를 표시하기 위해 output 요소 값을 설정하는 스크립트를 포함하는 폼이 있습니다 :
<form name="main"> Result: <output name="result"></output> <script> document.forms.main.elements.result.value = 'Hello World'; </script> </form>
DOM 트리 내의 각 요소는 객체로 나타나고 각각의 객체는 스스로 조작 가능하도록 하는 API를 가집니다.
예를 들어, 링크 (예를 들어 위 트리의 a요소）는 "href"속성을 여러가지 방법으로 변경할 수 있습니다 :
var a = document.links[0]; // 문서 안의 첫번째 링크를 가져온다
a.href = 'sample.html'; // 이동시킬 URL을 변경
a.protocol = 'https'; // URL 스키마 부분을 변경
a.setAttribute('href', 'http://example.com/'); // 속성 내용을 직접 변경
HTML 문서가 구현(특히 웹브라우저 같은 인터렉티브한 구현)에 따라 처리 및 표시 될 때, HTML문서를 표현하기 위한 수단으로 DOM 트리를 사용하기 때문에, 이 스펙 문서에서는 대부분이 위에서 기술한 마크업 대신 DOM 트리 용어로 기술됩니다.
HTML 문서는 미디어에 의존하지 않는 인터렉티브 콘텐츠 작성을 나타냅니다. HTML 문서는 화면에서 음성 신디사이저나 점자 디스플레이에서 렌더링 될 수도 있습니다. 그러한 렌더링이 이루어질 때 영향을 주기 위해, 에디터는 CSS 등의 스타일 언어를 사용할 수 있습니다.
아래 예시에서 CSS를 이용하는 페이지는 배경을 노란색, 글자를 청색으로 표현합니다.
<!DOCTYPE html>
<html>
<head>
<title>Sample styled page</title>
<style>
body { background: navy; color: yellow; }
</style>
</head>
<body>
<h1>Sample styled page</h1>
<p>This page is just a demo.</p>
</body>
</html>
어떤 식으로 HTML을 사용할까에 대한 상세한 내용에 대해서는, 튜토리얼과 가이드를 참조하는 걸 권장합니다. 이 스펙 문서가 포함하는 예제가 도움이 될 수 있지만, 어쩔 수 없이 처음엔 이해하기 어려울 것입니다. 상세한 레벨에서 언어를 정의하기 때문에 초심자는 주의하길 바랍니다.
이 절은 표준에 준하는 내용이 아닙니다.
인터렉티브 사이트를 만들기 위해 HTML을 사용하는 경우, 공격자가 사이트 자체나 사이트를 이용하는 유저의 무결성을 위태롭게 하여, 취약점을 취득하는 걸 피하도록 해야합니다.
이 문제의 포괄적인 연구는 이 문서의 범위를 넘습니다. 에디터는 더 자세히 문제를 연구하기를 바랍니다. 다만 이 절에서 HTML 어플리케이션을 개발할 때 일반적인 함정에 대한 간단한 지침을 제공하려 합니다.
웹 보안 모델은 "origin" 개념에 기초하며, 웹상에서 잠재적인 공격의 대부분은 거기에 대응하여 cross-origin행동을 수반합니다. [ORIGIN]
예를 들어 텍스트 코멘트 같은 유저가 생산하는 콘텐츠, URL 파라미터 값, 서드 파티 사이트에서 전달하는 메시지 등 신뢰할 수 없는 입력을 받을 때, 데이터를 사용하기 전에 확인하여 표시하는 경우 적절히 에스케이프해야만 합니다. 그렇지 않으면 적대적인 유저가 거짓 나이 같은 거짓 유저 정보를 제공하는 비교적 안전한 것에서부터 정보를 포함한 페이지를 볼 때마다 스크립트를 실행하거나 심한 경우 잠재적 프로세스에 대한 공격을 전파하는 등으로 서버의 모든 데이터를 삭제하는 등 다양한 공격 실행을 허용합니다.
유저가 입력한 값을 검증하기 위한 필터를 작성할 때, 필터는 항상 알려진 안전한 구조값을 허용하고, 그 외의 모든 입력을 허가하지 않는 화이트리스트 기반인 것이 필수입니다. (미래에 개발될 지 모르는) 모든 위험은 알려진 것이 아니므로, 이미 알려진 위험한 입력을 허락하지 않고 그 외는 허락하는 블랙리스트 베이스의 필터는 위험합니다.
예를 들어, 페이지 상의 특정 부분을 표시할 지 결정하기 위해, 페이지의 URL에 리퀘스트 문자열을 보고 사이트가 메시지를 표시함으로써, 그 페이지에 유저를 리다이렉트 시키려고 합니다 :
<ul> <li><a href="message.cgi?say=Hello">Say Hello</a> <li><a href="message.cgi?say=Welcome">Say Welcome</a> <li><a href="message.cgi?say=Kittens">Say Kittens</a> </ul>
메시지가 에스케이프 되지 않고 단순히 유저에게 표시되고 있는 경우, 악의적인 공격자는, script 요소가 포함되어있는 URL을 작성할 가능성이 있습니다:
http://example.com/message.cgi?say=%3Cscript%3Ealert%28%27Oh%20no%21%27%29%3C/script%3E
공격자가 타겟 유저가 이 페이지에 접근할거라 확신하고 있다면, 공격자가 성택한 스크립트는 페이지 상에서 실행될 것입니다. 이러한 스크립트는 사이트가 제공하는 것으로만 제한되고, 원하는만큼 적대적인 행동을 취할 수 있습니다. 예를 들어 사이트가 e 커머스 쇼핑이라면, 스크립트가 사용자가 알지 못하는 사이 많은 불필요한 쇼핑을 할 수 있습니다.
이를 크로스 사이트 스크립팅 공격이라 부릅니다.
코드를 실행시키는 사이트를 속이기 위해 이용 가능한 많은 구성요소가 있습니다. 에디터가 화이트리스트 필터를 쓰는 경우 고무시키는 몇가지가 있습니다 :
img같이 무해하다고 생각하는 요소를 허가하는 경우에는 정해진 속성을 화이트 리스트에 등록하는 게 중요합니다. 예를 들어 img에 모든 속성을 허가하는 경우 공격자는 임의의 스크립트를 실행하기 위해 onload 속성을 사용할 수 있습니다.javascript:" 프로토콜이지만, 유저 에이전트가 다른 것도 구현할 수 있습니다.（그리고 실제로 오랜기간 구현하고 있습니다）。base요소를 삽입할 수 있도록 하는 것은, 상대적인 링크를 가진 페이지에 임의의 script 요소를 납치할 가능성이 있으며, 마찬가지로 어떤 폼을 악의적인 사이트에 리디렉션되어 제출될 수도 있다는 걸 의미합니다.예를 들어, 유저 이름으로 포럼에 메시지 게시, 구매, 여권 신청 등을 할 때, 사이트가 사용자에 대한 유저 고유의 부작용을 포함하는 폼 전송을 허용하는 경우, 다른 사이트에 의해서 유저를 무의식으로 요청하듯 속이기보다, 의도적으로 사용자에 의해서 이루어진 걸 확인하는 게 중요합니다.
HTML 폼을 다른 사이트에 보낼 수 있기 때문에, 이 문제가 존재합니다.
사이트는 유저별로 고유의 토큰을 가지고 하여 폼을 생성하거나 모든 요청에 Origin 헤더를 체크하도록 하여 이러한 공격을 방지할 수 있습니다.
유저가 원하지 않는 행동을 수행하는 인터페이스를 유저에게 제공하는 페이지는, 유저가 활성 인터페이스에 속을 가능성을 방지하도록 설계해야합니다.
예를 들어 적대적인 사이트가 작은 iframe을 피해자의 사이트에 배치하고 사용자가 리액션 게임을 플레하도록 하여, 클릭하도록 유저를 유도하는 것도 유저를 속이는 하나의 방법입니다. 일단 사용자가 게임을 하면 적대 사이트는 사용자가 클릭하려고 할 때 마우스 커서 바로 밑에 iframe을 배치할 수 있습니다. 이렇게 피해자 사이트 인터페이스를 클릭하도록 유도할 수 있습니다.
이를 방지하기 위해 프레임 사용이 예상되는 사이트는 （예를 들어 top속성의 값에 window객체를 비교하여）프레임에 없는 것을 검출한 경우에만 인터페이스를 활성화 하는 것을 권장합니다.
이 절은 표준에 준하는 내용이 아닙니다.
HTML 내부 스크립트는 "실행부터 완료까지" 의미가 있습니다. 이는 이벤트의 발화 및 문서 분석을 계속하는 등 다른 무언가를 실행하기 전에, 일반적으로 브라우저는 중단하지 않고 스크립트를 실행하는 것을 의미합니다.
한편 HTML 파일의 해석은 비동기적이고 점진적으로 발생합니다. 이는 파서가 스크립트를 실행할 수 있도록 시점에 따라 언제든지 일시 정지 할 수 있음을 의미합니다. 이는 일반적으로 좋은 일이지만 이벤트가 발화한 이후에, 에디터는 이벤트 핸들러를 후크하는걸 피하도록 주의해야한다는 것을 의미합니다.
이를 확실하게 할 이벤트 핸들러 콘텐츠 속성을 사용하거나 요소를 작성할 때 같은 스크립트 안의 이벤트 핸들러를 추가하는 2가지 방법이 있습니다. 앞에서 쓴 바와 같이 추가 이벤트가 발동하기 전에는 스크립트가 끝날 때까지 실행되고 있기 때문에 후자가 안전합니다.
이를 명시하고자 할 때 가능한 하나의 방법은 img요소와 load이벤트입니다. 특히 이미지가 이미 (공통으로) 캐시에 들어가있는 경우 요소를 해석할 때 이벤트가 발화할 수 있습니다.
에디터는 load 이벤트를 잡기위해 img 요소에 onload핸들러를 이용할 수 있습니다：
<img src="games.png" alt="Games" onload="gamesLogoHasLoaded(event)">
요소가 스크립트를 통해 추가되는 경우, 이벤트 핸들러는 같은 스크립트 내에서 추가되어, 이벤트를 캐치하지 못하는 일은 없을것입니다 :
<script>
var img = new Image();
img.src = 'games.png';
img.alt = 'Games';
img.onload = gamesLogoHasLoaded;
// img.addEventListener('load', gamesLogoHasLoaded, false); // would work also
</script>
그러나 에디터에 최초에 img요소를 작성해 다른 스크립트에서 이벤트 리스너를 추가한 경우 load 이벤트가 발화했을 때 놓칠 기회가 있습니다 :
<!-- Do not use this style, it has a race condition!-->
<img id="games" src="games.png" alt="Games">
<!-- the 'load' event might fire here while the parser is taking a
break, in which case you will not see it!-->
<script>
var img = document.getElementById('games');
img.onload = gamesLogoHasLoaded; // might never fire!
</script>
이 절은 표준에 준하는 내용이 아닙니다.
에디터는 흔히 볼 수 있는 에러를 찾을 적합성 검사(밸리데이터라고 불린다)를 이용하는 걸 권장합니다. W3C는 Nu Markup Validation Service를 포함한 많은 온라인 검증 서비스를 제공합니다.
이 절은 표준에 준하는 내용이 아닙니다.
HTML 스펙 문서의 이전 버전과는 다릴, 이 스펙 문서는 유효한 문서 및 유효하지 않은 문서에서 자세히 필요한 처리를 정의합니다.
그러나 유효하지 않은 콘텐츠의 처리는 대부분의 경우 명확히 정의되지만, 문서에 대한 적합성 요구는 여전히 중요합니다. 사실 상호운용성(모든 구현이 신뢰성과 동일하거나 유사한 방법으로 특정 콘텐츠를 처리하고 있는 상황)은, 문서 요구 사항을 준수하는 데 유일한 목표는 아닙니다. 이 절에서는 적합 문서와 에러를 가진 문서를 구별하기 위해 일반적인 이유의 일부를 보여줍니다.
이 절은 표준에 준하는 내용이 아닙니다.
더 이상 이전 버전의 HTML에서 사용하던 프레젠테이션 기능은 대부분이 사용 불가능합니다. 일반적으로 프레젠테이션 마크업은 많은 문제를 안고 있습니다 :
유저 지원 기술（AT）에 충분한 경험（ARIA를 이용해서）을 제공하는 방식으로 프레젠테이션 마크업을 이용하는 건 가능하지만, 시맨틱에 적절한 마크업을 이용하는 경우와 비교했을 때 현저히 부족합니다. 또한 설령 그런 기술을 사용하더라도 텍스트 모드 브라우저를 사용하는 유저 같은 AT가 아닌 비 그래픽 유저를 대상으로 할 때 페이지를 접근 가능하도록 할 수 없습니다.
한편 미디어에 의존하지 않는 마크업의 사용은 많은 사용자 (예를 들어 텍스트 브라우저)에서 정상적으로 작동하도록 작성하는 문서를 위한 쉬운 방법을 제공합니다.
마크업이 스타일에 의존하지 않는 방법으로 작성한 사이트의 유지는 상당히 쉽습니다.
예를 들어 <font color="">를 사용해서 사이트의 색상을 변경하면 사이트 전체의 마크업을 변경해야하는 반면, CSS 기반의 사이트에서는 단일 파일의 변경만으로 가능합니다.
프레젠테이션 마크업은 매우 중복되는 경향이 있습니다. 따라서 문서 크기가 더욱 커집니다.
이를 위해 이 버전에서는 프레젠테이션 마크업을 대부분 제거했습니다. 이런 변화는 딱히 놀랄 일은 아니고, HTML4가 몇년 전부터 프레젠테이션 마크업을 비추천하였고, 에디터가 프레젠테이션 마크업에서 일부 유예기간을 갖는 모드인 （HTML4 Transitional）을 제공했습니다. 후에 XHTML 1.1은 더 나아가 완전히 그 기능을 폐지했습니다.
HTML에 유일하게 남아있는 프레젠테이션 마크업 기능은 style속성과 style요소입니다. style속성의 사용은 프로덕션 환경에서 권장하지 않지만, 래피드 프로토타이핑（그 특성을 직접 나중에 다른 스타일시트로 이동할 수 있습니다.） 및 독립 스타일시트로는 하기 어려운 다른 사람과 다른 경우의 스타일을 공유하고자 할 때 도움이 됩니다. 마찬가지로style 요소는 전달할 때나 페이지 고유의 스타일을 적용하고자할 때 유용하지만, 일반적으로 같은 스타일을 여러 페이지에 적용할 경우에는 외부 스타일 시트를 사용하는 게 더 쉽습니다.
또한 이전에는 프레젠테이션 요소였던 것들 중 일부 요소가 미디어에 의존하지 않도록 이 스펙에서 재정의하는 경우도 있어 주목해야합니다：b、i、hr、s、small 및 u.
이 절은 표준에 준하는 내용이 아닙니다.
HTML 구문은 여러가지 문제를 해결하기 위해 구속되어 있습니다.
특정 유효하지 않은 구문 구조가 해석될 때매우 직관적이지 않은 DOM 트리를 생성합니다.
더 기묘하고 복잡한 에러 처리규칙을 구현하지 않고, 제어된 환경에서 사용 가능하도록 하기 위해, 유저 에이전트에서 해석 에러가 발생하는 경우 실패가 허용됩니다.
위에서 작성한 <table><hr>...에 대한 동작 등, 일부 에러 처리 동작 방식은 스트리밍 유저 에이전트（상태를 저장하지 않고 1회 패스로 HTML 파일을 처리하는 유저 에이전트）와 호환하지 않습니다. 그런 유저 에이전트와 상호 운용성 문제를 해결하기 위한 어떤 구문도 타당하지 않다고 봅니다.
XML을 기반으로 두는 유저 에이전트가 HTML 파서에 연결하는 경우, 주석에서 이어지는 2개의 하이픈을 포함할 수 없다는 등의 XML에서 강제하는 특정 요건은 HTML 파일에 의해 침해당할 가능성이 있습니다. 이를 처리할 경우 파서가 XML 호환 infoset에 HTML DOM을 강제하는 걸 요구할 수 있습니다. 이러한 처리를 요구하는 대부분의 구문 구조는 유효하지 않다고 간주합니다.
특정 구문 구조는 불균형한 성능 저하로 이어질 수 있습니다. 이러한 구조의 사용을 단념시키기 위해, 전형적으로 부적합합니다.
예를 들어, 모든 닫히지 않은 i 요소가 각 단락에서 재구성되어야만 하기 ㄷ때문에, 다음 마크업은 퍼포먼스 저하를 초래하고 각 단락에서 점차적으로 더 많은 요소를 가집니다 :
<p><i>He dreamt. <p><i>He dreamt that he ate breakfast. <p><i>Then lunch. <p><i>And finally dinner.
이는 DOM으로 해석되었을 때 :
역사적인 이유로 인해 상대적으로 약한 구문 구조가 존재합니다. 그런 문제에 우발적으로 빠지는 유저를 줄이기 위해, 이를 적합하지 않다고 판단합니다.
예를 들어, 속성에서 지정된 문자참조의 특정 구문 분석은, 닫힘 세미콜론을 생략해도 발생합니다. 지정 문자 참조를 형성하지 않는 문자가 계속하여 앰퍼샌드를 포함하는건 안전하지만, 그 문자가 지정 문자 참조를 형성하는 문자열로 변경된 경우, 그 문자열 대신 문자로써 해석될 것입니다.
아래 예제에서 속성값은 "?bill&ted"이 됩니다:
<a href="?bill&ted">Bill and Ted</a>
그러나, 아래 예제에서 속성값은 "?art©"이 아닌, 실제로는 "?art©"가 됩니다. 왜냐하면 마지막 세미콜론이 없는 "©"와 "©"와 동일하게 취급합니다. 따라서 "©"로 해석됩니다 :
<a href="?art©">Art and Copy</a>
이 문제를 해결하기 위해, 모든 지정 문자 참조는 세미콜론으로 종료할 필요가 있으며, 세미콜론이 없는 지정문자참조의 사용은 에러로 플래그를 지정합니다.
따라서 위 예제는 아래와 같이 변경합니다 :
<a href="?bill&ted">Bill and Ted</a> <!-- &ted는 지정 문자 참조가 아니므로 OK -->
<a href="?art&copy">Art and Copy</a> <!-- ©는 지정 문자 참조이기 때문에 、&를 에스케이프할 필요가 있다 -->
특정 구문 구조는 레거시 유저 에이전트에서는 특히 미묘하거나 중대한 문제를 일으키는 걸로 알려져 있으며, 따라서 에디터가 피할 것을 돕기 위해 부적합으로 표시합니다.
예를 들어 "`"（U+0060）문자를 인용되지 않은 속성에서 허용되지 않는 이유 중 하나입니다. 특정 레거시 유저 에이전트는 이를 따옴표로 처리합니다.
일부 제한사항은 순수하게 알려져있는 보안 문제를 해결하기 위해 존재합니다.
예를 들어 UTF-7을 사용할 때 제한사항은, UTF-7을 이용하여 크로스 사이트 스크립팅 공격에 대해 순수하게 희생되는 걸 막기 위해 존재합니다.[UTF7]
에디터의 의도가 매우 불명확한 마크업은 부적합으로 나타납니다. 이 오류를 초기에 수정하는게 이후 유지보수에 도움이 됩니다.
유저가 단순히 오타를 한 경우, 에러를 초기에 발견할 수 있고 디버깅 시간을 크게 절약할 수 있을 것입니다. 따라서 이 스펙에 정의되어있는 이름과 일치하지 않은 요소명, 속성명 및 기타 사용을 에러로 간주합니다.
예를 들어 <caption> 대신에 <capton>을 입력한 경우, 바로 오타를 수정할 수 있습니다.
언어 구문은 미래에 확장이 가능하도록 무해하더라도 특정 기능을 금지하고 있습니다.
예를 들어 닫는 태그에 들어가는 "속성"은 현재 무시되며, 오히려 유효하지 않습니다. 미래에 언어를 변경하려면 이미 배포된 (그리고 유효한) 콘텐츠와 충돌하지 않고 그 구문을 이용할 수 있어야 합니다.
일부 작성자는 항상 모든 특성을 따옴표로 묶고 임의의 태그를 태그를 포함한 습관이 도움이 될 것이란 걸 발견, HTML 구문의 유연성을 이용한 간결함을 단순히 편리를 뛰어넘어, 습관에서 유래한 견고성을 좋아합니다. 그런 작성자를 지원하기 위해 적합성 검사는 이러한 규칙을 적용하는 모든 동작모드를 제공합니다.
이 절은 표준에 준하는 내용이 아닙니다.
언어 구문의 범위를 넘어, 이 스펙문서는 요소나 속성을 지정할 수 있는 방법도 제한합니다. 이 제한은 비슷한 이유로 존재합니다 :
정의된 의미를 가지는 요소의 오용을 방지하기 위해서, 콘텐츠 모델의 자식이 애매한 값을 가지는 경우, 요소가 자식으로 하는 것이 가능한 방법에 제한을 둡니다.
예를 들어 에디터가 전체 섹션이 키를 입력해야한다고 주정하는 것은 우선 없기 때문에 이 스펙에서는 kbd요소 내부에section요소 입력을 금지합니다.
마찬가지로 요소의 오용에 에디터의 관심을 끌기 위해서, 의미 상 명백히 모순이 있는 표현도 적합성 에러로 간주합니다.
아래 예제에서는 시맨틱이 무의미해집니다. 수평선과 셀은 양립할 수 없으며, 라디오 버튼과 프로그레스 바도 양립할 수 없습니다.
<hr role="cell">
<input type=radio role=progressbar>
다른 예로는li요소만 자식으로 갖는 ul요소의 내용 모델 제약이 있습니다.
정의에 따라 리스트는 0개 이상의 리스트 항목으로 이루어지며 ul요소는 li요소 의외의 것이 포함되는 경우 의도가 불명확해집니다.
특정 요소에서는, 혼란으로 이어질 가능성이 높은 조합의 기본 스타일이나 동작이 있습니다. 이 문제가 없이 동등한 선택권을 가진 장소에서는 혼란하는 조합은 허용하지 않습니다.
예를 들어 div요소는 블록박스로, span 요소는 인라인 박스로 렌더링 됩니다. 인라인 박스 내부에 블록 박스를 넣는 건 불필요한 혼란을 낳습니다.div 요소만 포함하거나, span요소만 포함하거나 div 내부에 span요소를 포함하는 어느쪽이 되었던 간에 모두span요소에서 div요소를 포함하는 것 모두 같은 목적을 이룰 수 있지만, 후자와 같이 인라인 박스에서 블록 박스를 포함하는 조합은 허가하지 않습니다.
또 하나의 예는 인터렉티브 콘텐츠는 자식을 가질 수 없습니다. 예를 들어 button요소는 textarea요소를 포함하는 것이 불가합니다. 이는 자식이 되는 인터렉티브 요소의 기본 동작이 유저에게 매우 혼란을 일으킬 가능성이 있기 때문입니다. 이러한 요소를 자식으로 두는 대신 나란히 둘 수 있습니다.
때에 따라 에디터의 혼란을 일으킬 가능성이 있는 명확하지 않은 것도 있습니다.
예를 들어, 값 "false"를 disabled속성에 정의하는 걸 허가하지 않습니다. 이는 요소의 외관 상 enabled가 되지 않는다는 걸 의미하지만 실제 요소가 disabled를 의미하기（구현을 위해 중요한 건 그 값이 아닌 속성의 존재 여부입니다）때문입니다.
일부 적합성 에러는 에디터가 학습해야할 필요가 있는 언어를 평이하게 합니다.
예를 들어area요소의 shape속성은 circ와 circle의 값을 모두 수용함에도 불구하고 튜토리얼 및 기타 학습 보조를 평이하게 하기 위해 circ값의 사용을 허용하지 않습니다. 양자 모두 허용해도 불이익은 없겠지만, 언어를 가르칠 때 불필요한 혼란을 일으킬 것입니다.
특정 요소는 다소 색다른 방법 (일반적으로는 역사적인 이유 때문에)으로 해석되어, 그 요소의 내용 모델 제약은 이러한 문제에 에디터가 노출되는 걸 회피하도록 의도합니다.
일부 에러는 디버그가 어려운 스크립트의 문제를 방지할 의도를 갖고 있습니다.
예를 들어, 같은 값을 가지는 2개의 id속성을 가지는 건 부적합 사유가 됩니다. 이중 ID는 때에 따라 비참한 결과와 그 원인을 규명하는 걸 어렵게 함과 동시에 잘못된 요소의 선택을 이끌어냅니다.
일부 구조는 역사적으로 불필요한 제작시간이 걸린 원인이며 그 구조를 취하지 않도록 저자에게 권장함으로써 미래에 들일 시간을 절약할 수 있기 때문에 허용하지 않습니다.
예를 들어 script요소의 src속성은 요소의 내용을 무시합니다. 그러나 이는 분명하지 않고, 요소의 내용이 실행 가능한 스크립트처럼 보이는 경우 스크립트가 실행되지 않는 다는 것을 알 수 없이 에디터가 인라인 스크립트를 디버깅하는데 많은 시간을 할애할 것입니다.
이 문제를 완화하기 위해 이 스펙은 src 속성이 존재하는 경우 script요소 내에 실행 가능한 스크립트를 부적합하다고 간주합니다. 이는 이 문서를 검증하는 에디터가 이런 종류의 에러로 인해 시간을 낭비할 가능성을 낮게 함을 의미합니다.
일부 에디터는 XML과 HTML 양쪽에서 동일한 결과를 해석할 수 있는 파일을 쓰는 걸 좋아합니다. 이 습관은 수많은 미묘한 어려움 (특히 스크립트, 스타일, 자동화된 직렬화의 임의 종류를 포함한 경우) 때문에 일반적으로 권장되지 않더라도 이 스펙에서는 적어도 약간의 어려움을 완화하기 위한 몇가지 제약이 있습니다. 이는 에디터가 HTML과 XHTML 사이에서 마이그레이션 하는 경우 과도한 단계로써 쉽게 사용할 수 있도록 합니다.
예를 들어 lang과 xml:lang 속성이 동기화를 유지하는 것을 목적으로 하는 다소 복잡한 규칙이 있습니다.
또 다른 예는 적합한 문서에서 요소가 HTML이나 XML로 처리했는지, 같은 네임스페이스에서 끝났는 지 등을 확인하기 위한 의도로 HTML에서 xmlns 속성 값을 제한합니다.
언어의 향후 개정에서 새로운 구문을 사용 가능하게 하기 위해 의도된 구문과, 요소나 속성값 내용 모델에 대한 일부 제한은 HTML 어휘가 미래에 확장 가능하도록 예정되어있습니다.
예를 들어 "_"（U+005F） 문자로 시작하는 target속성값을 특정 정의 값으로 제한하는 이유는, 새로운 사전 정의 값이 이후에 에디터가 정의한 값과 충돌 없이 도입할 수 있기 때문입니다.
일정 제약사항은 다른 스펙에 따라 만들어진 제약 지원을 의도합니다.
예를 들어 미디어 쿼리를 취하는 속성이 유효한 미디어 쿼리만을 사용하도록 요구함으로써, 그 스펙 준수 규칙에 따르는 중요성을 강조하고 있습니다.
이 절은 표준에 준하는 내용이 아닙니다.
아래 문서는, 이 스펙서의 독자가 흥미를 가질만한 읽을거리입니다.
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.
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 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.
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.
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.
A document that uses polyglot markup is a 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.
This is draft documentation mapping HTML elements and attributes to accessibility API Roles, States and Properties on a variety of platforms. It provides recommendations on deriving the accessible names and descriptions for HTML elements. It also provides accessible feature implementation examples.