W3C

HTML 5.1

W3C Working Draft 06 May 2015

This Version:
http://www.w3.org/TR/2015/WD-html51-20150506/
Latest Published Version:
http://www.w3.org/TR/html51/
Previous Version:
http://www.w3.org/TR/2015/WD-html51-20150417/
Editors:
WHATWG:
Ian Hickson, Google, Inc.
W3C:
Robin Berjon, W3C
Steve Faulkner, The Paciello Group
Travis Leithead, Microsoft
Erika Doyle Navara, Microsoft
Edward O'Connor, Apple Inc.
For the img and picture elements:
Tab Atkins (Google)
(Opera Software)
Yoav Weiss
Marcos Cáceres (Mozilla)
Mat Marquis

1 Introduction

2 Common infrastructure

3 Semantics, structure, and APIs of HTML documents

3.2 Elements

3.2.6 Requirements relating to the bidirectional algorithm

4 The elements of HTML

4.1 The root element

4.2 Document metadata

4.3 Sections

4.4 Grouping content

4.5 Text-level semantics

4.7 Edits

The ins and del elements represent edits to the document.

4.8 Embedded content

4.9 Tabular data

4.10 Forms

4.11 Interactive elements

4.12 Scripting

Scripts allow authors to add interactivity to their documents.

Authors are encouraged to use declarative alternatives to scripting where possible, as declarative mechanisms are often more maintainable, and many users disable scripting.

For example, instead of using script to show or hide a section to show more details, the details element could be used.

Authors are also encouraged to make their applications degrade gracefully in the absence of scripting support.

For example, if an author provides a link in a table header to dynamically resort the table, the link could also be made to function without scripts by requesting the sorted table from the server.

5 User interaction

5.6 Editing

5.7 Drag and drop

This section defines an event-based drag-and-drop mechanism.

This specification does not define exactly what a drag-and-drop operation actually is.

On a visual medium with a pointing device, a drag operation could be the default action of a mousedown event that is followed by a series of mousemove events, and the drop could be triggered by the mouse being released.

When using an input modality other than a pointing device, users would probably have to explicitly indicate their intention to perform a drag-and-drop operation, stating what they wish to drag and where they wish to drop it, respectively.

However it is implemented, drag-and-drop operations must have a starting point (e.g. where the mouse was clicked, or the start of the selection or element that was selected for the drag), may have any number of intermediate steps (elements that the mouse moves over during a drag, or elements that the user picks as possible drop points as he cycles through possibilities), and must either have an end point (the element above which the mouse button was released, or the element that was finally selected), or be canceled. The end point must be the last element selected as a possible drop point before the drop occurs (so if the operation is not canceled, there must be at least one element in the middle step).

6 Loading Web pages

This section describes features that apply most directly to Web browsers. Having said that, except where specified otherwise, the requirements defined in this section do apply to all user agents, whether they are Web browsers or not.

6.7 Offline Web applications

7 Web application APIs

8 The HTML syntax

This section only describes the rules for resources labeled with an HTML MIME type. Rules for XML resources are discussed in the section below entitled "The XHTML syntax".

9 The XHTML syntax

This section only describes the rules for XML resources. Rules for text/html resources are discussed in the section above entitled "The HTML syntax".

10 Rendering

User agents are not required to present HTML documents in any particular way. However, this section provides a set of suggestions for rendering HTML documents that, if followed, are likely to lead to a user experience that closely resembles the experience intended by the documents' authors. So as to avoid confusion regarding the normativity of this section, RFC2119 terms have not been used. Instead, the term "expected" is used to indicate behaviour that will lead to this experience. For the purposes of conformance for user agents designated as supporting the suggested default rendering, the term "expected" in this section has the same conformance implications as the RFC2119-defined term "must".

11 Obsolete features

Index

The following sections only cover conforming elements and features.