Introduction

Background

Audience

Scope

History

Design notes

Serializability of script execution

Compliance with other specifications

Extensibility

HTML vs XML Syntax

Structure of this specification

How to read this specification

Typographic conventions

      interface Example {
        // this is an IDL definition
      };
    

/* this is a CSS fragment */

Privacy concerns

A quick introduction to HTML

• DOCTYPE: html
• <{html}>
  • <{head}>
    • #text: ⏎␣␣
    • <{title}>
      • #text: Document title
    • #text: ⏎␣
  • #text: ⏎␣
  • <{body}>
    • #text: ⏎␣␣
    • <{h1}>
      • #text: Document heading
    • #text: ⏎␣␣
    • <{p}>
      • #text: This is a paragraph of text.
    • #text: ⏎␣␣
    • <{p}>
      • #text: ⏎␣␣
      • <{a}> <{links/href}>="another-html-document.html"
        • #text: Link text for a link to another-html-document.html
      • #text: ⏎␣␣
    • #text: ⏎␣␣
    • #comment: this is a comment
    • #text: ⏎␣⏎

    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
  

Writing secure applications with HTML

http://example.com/message.cgi?say=%3Cscript%3Ealert%28%27Oh%20no%21%27%29%3C/script%3E

Common pitfalls to avoid when using the scripting APIs

How to catch mistakes when writing HTML: validators and conformance checkers

Conformance requirements for authors

Presentational markup

Syntax errors

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.

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.

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. [[RFC2152]]

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.

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.

Restrictions on content models and on attribute values

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.

Another example is the restrictions on the content models of the <{ul}> element, which only allows <{li}> element children. Lists, by definition, consist 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.

For example, setting the <{disabledformelements/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).

For example, the <{area}> element's <{area/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, and it would cause extra confusion when teaching the language.

This is why, for instance, it is non-conforming to have two <{global/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.

For example, a <{script}> element's <{script/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 <{script/src}> attribute is present. This means that authors who are validating their documents are less likely to waste time with this kind of mistake.

For example, there are somewhat complicated rules surrounding the <{global/lang}> and <{xml/lang|xml:lang}> attributes intended to keep the two synchronized.

Another example would be the restrictions on the values of <{xmlns/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.

For example, limiting the values of the <{links/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.

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

Suggested reading

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 specification 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.1 covers a wide range of recommendations for making Web content more accessible. Following these guidelines will make content more accessible to a wider range of people with disabilities, including blindness and low vision, deafness and hearing loss, limited movement, speech disabilities, photosensitivity, and combinations of these, and some accommodation for learning disabilities and cognitive limitations; but will not address every user need for people with these disabilities. These guidelines address accessibility of web content on desktops, laptops, tablets, and mobile devices. Following these guidelines will also often make Web content more usable to users in general. WCAG 2.1 extends Web Content Accessibility Guidelines 2.0 [[WCAG20]], which was published as a W3C Recommendation December 2008. Content that conforms to WCAG 2.1 also conforms to WCAG 2.0, and therefore to policies that reference WCAG 2.0.

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.

Defines how user agents map HTML 5.1 elements and attributes to platform accessibility APIs. Documenting these mappings promotes interoperable exposure of roles, states, properties, and events implemented by accessibility APIs and helps to ensure that this information appears in a manner consistent with author intent.