W3C

HTML 5.2

W3C Proposed Recommendation,

Status of this document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.

This document was published by the Web Platform Working Group as a Proposed Recommendation for HTML 5.2 that would obsolete the HTML 5.1 Recommendation. An HTML 5.1 Candidate Recommendation was published on 08 August 2017, and this document has incorporated feedback received on that draft. This document is intended to become a W3C Recommendation. Feedback and comments on this specification are welcome. Please use Github issues. Historical discussions can be found in the public-html@w3.org archives.

The W3C Membership and other interested parties are invited to review the document and provide feedback using Github issues through 30 November 2017. Advisory Committee Representatives should consult their WBS questionnaires. Note that substantive technical comments were expected during the Last Call review period that ended 5 September 2017. All comments are welcome.

Errata for this document are recorded as issues. The latest HTML editors' draft shows the current proposed resolution of errata in situ.

All interested parties are invited to provide implementation and bug reports and other comments through the Working Group's Issue tracker. These will generally be considered in the development of HTML 5.3.

The implementation report produced for this version demonstrates that in almost every case changes are matched by interoperable implementation.

Publication as a Proposed Recommendation does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This document is governed by the 1 March 2017 W3C Process Document.

12. IANA considerations

12.1. text/html

This registration is for community review and will be submitted to the IESG for review, approval, and registration with IANA.

Type name:

text

Subtype name:

html

Required parameters:

No required parameters

Optional parameters:
charset

The charset parameter may be provided to specify the document’s character encoding, overriding any character encoding declarations in the document other than a Byte Order Mark (BOM). The parameter’s value must be one of the labels of the character encoding used to serialize the file. [ENCODING]

Encoding considerations:

8bit (see the section on character encoding declarations)

Security considerations:

Entire novels have been written about the security considerations that apply to HTML documents. Many are listed in this document, to which the reader is referred for more details. Some general concerns bear mentioning here, however:

HTML is scripted language, and has a large number of APIs (some of which are described in this document). Script can expose the user to potential risks of information leakage, credential leakage, cross-site scripting attacks, cross-site request forgeries, and a host of other problems. While the designs in this specification are intended to be safe if implemented correctly, a full implementation is a massive undertaking and, as with any software, user agents are likely to have security bugs.

Even without scripting, there are specific features in HTML which, for historical reasons, are required for broad compatibility with legacy content but that expose the user to unfortunate security problems. In particular, the img element can be used in conjunction with some other features as a way to effect a port scan from the user’s location on the Internet. This can expose local network topologies that the attacker would otherwise not be able to determine.

HTML relies on a compartmentalization scheme sometimes known as the same-origin policy. An origin in most cases consists of all the pages served from the same host, on the same port, using the same protocol.

It is critical, therefore, to ensure that any untrusted content that forms part of a site be hosted on a different origin than any sensitive content on that site. Untrusted content can easily spoof any other page on the same origin, read data from that origin, cause scripts in that origin to execute, submit forms to and from that origin even if they are protected from cross-site request forgery attacks by unique tokens, and make use of any third-party resources exposed to or rights granted to that origin.

Interoperability considerations:

Rules for processing both conforming and non-conforming content are defined in this specification.

Published specification:

This document is the relevant specification. Labeling a resource with the text/html type asserts that the resource is an HTML document using the HTML syntax.

Applications that use this media type:

Web browsers, tools for processing Web content, HTML authoring tools, search engines, validators.

Additional information:
Magic number(s):

No sequence of bytes can uniquely identify an HTML document. More information on detecting HTML documents is available in the MIME Sniffing specification. [MIMESNIFF]

File extension(s):

"html" and "htm" are commonly, but certainly not exclusively, used as the extension for HTML documents.

Macintosh file type code(s):

TEXT

Person & email address to contact for further information:

World Wide Web Consortium <web-human@w3.org>

Intended usage:

Common

Restrictions on usage:

No restrictions apply.

Authors:

Alex Danilo <adanilo@google.com>

Arron Eicholz <arronei@microsoft.com>>

Sangwhan Moon <sangwhan@iki.fi>

Steve Faulkner <sfaulkner@paciellogroup.com>

Travis Leithead <travil@microsoft.com>

Change controller:

W3C

Fragments used with text/html resources either refer to the indicated part of the document or provide state information for in-page scripts.

12.2. multipart/x-mixed-replace

This registration is for community review and will be submitted to the IESG for review, approval, and registration with IANA.

Type name:

multipart

Subtype name:

x-mixed-replace

Required parameters:
Optional parameters:

No optional parameters.

Encoding considerations:

binary

Security considerations:

Subresources of a multipart/x-mixed-replace resource can be of any type, including types with non-trivial security implications such as text/html.

Interoperability considerations:

None.

Published specification:

This specification describes processing rules for Web browsers. Conformance requirements for generating resources with this type are the same as for multipart/mixed. [RFC2046]

Applications that use this media type:

This type is intended to be used in resources generated by Web servers, for consumption by Web browsers.

Additional information:
Magic number(s):

No sequence of bytes can uniquely identify a multipart/x-mixed-replace resource.

File extension(s):

No specific file extensions are recommended for this type.

Macintosh file type code(s):

No specific Macintosh file type codes are recommended for this type.

Person & email address to contact for further information:

Ian Hickson <ian@hixie.ch>

Intended usage:

Common

Restrictions on usage:

No restrictions apply.

Author:

Ian Hickson <ian@hixie.ch>

Change controller:

W3C

Fragments used with multipart/x-mixed-replace resources apply to each body part as defined by the type used by that body part.

12.3. application/xhtml+xml

This registration is for community review and will be submitted to the IESG for review, approval, and registration with IANA.

Type name:

application

Subtype name:

xhtml+xml

Required parameters:

Same as for application/xml [RFC7303]

Optional parameters:

Same as for application/xml [RFC7303]

Encoding considerations:

Same as for application/xml [RFC7303]

Security considerations:

Same as for application/xml [RFC7303]

Interoperability considerations:

Same as for application/xml [RFC7303]

Published specification:

Labeling a resource with the application/xhtml+xml type asserts that the resource is an XML document that likely has a document element from the HTML namespace. Thus, the relevant specifications are the XML specification, the Namespaces in XML specification, and this specification. [XML] [XPTR-XMLNS]

Applications that use this media type:

Same as for application/xml [RFC7303]

Additional information:
Magic number(s):

Same as for application/xml [RFC7303]

File extension(s):

"xhtml" and "xht" are sometimes used as extensions for XML resources that have a document element from the HTML namespace.

Macintosh file type code(s):

TEXT

Person & email address to contact for further information:

Ian Hickson <ian@hixie.ch>

Intended usage:

Common

Restrictions on usage:

No restrictions apply.

Author:

Ian Hickson <ian@hixie.ch>

Change controller:

W3C

Fragments used with application/xhtml+xml resources have the same semantics as with any XML MIME type. [RFC7303]

12.4. web+ scheme prefix

This section describes a convention for use with the IANA URI scheme registry. It does not itself register a specific scheme. [RFC7595]

Scheme name:

Schemes starting with the four characters "web+" followed by one or more letters in the range a-z.

Status:

Permanent

Scheme syntax:

Scheme-specific.

Scheme semantics:

Scheme-specific.

Encoding considerations:

All "web+" schemes should use UTF-8 encodings where relevant.

Applications/protocols that use this scheme name:

Scheme-specific.

Interoperability considerations:

The scheme is expected to be used in the context of Web applications.

Security considerations:

Any Web page is able to register a handler for all "web+" schemes. As such, these schemes must not be used for features intended to be core platform features (e.g., network transfer protocols like HTTP or FTP). Similarly, such schemes must not store confidential information in their URLs, such as usernames, passwords, personal information, or confidential project names.

Contact:

Ian Hickson <ian@hixie.ch>

Change controller:

Ian Hickson <ian@hixie.ch>

References:

Custom scheme and content handlers, HTML Living Standard: https://html.spec.whatwg.org/#custom-handlers