What is part of HTML 5 and what does not belong?
We tend to embrace in the standard all new formats of the Web, including CSS 3, but what is exactly HTML 5?
What must be part of HTML 5, it is of course what is described in the HTML specification, but it is not so simple because over time the specification has evolved, included external formats and also was divided into several different standards.
In addition there is a difference between the WHATWG design that considers HTML 5 specification as always evolving while the W3C defines a standard complete before it considers the creation of the next version, HTML 5.1 or HTML 6.
A history of HTML 5 is included in the WHATWG document, a working group created by Mozilla, Opera and Apple. It tends to include in a single document all new Web technologies.
This standard was developed empirically and little ordered from various sources and we will see that all is not evident in the division in specifications.
This is actually part of HTML 5
When creating HTML 5, the WHATWG which wanted to make a format of interface for Web applications, what it has indeed become, described it as a join of Web Application, which replaced HTML 4, and Web Forms. DOM has been included further. Forms tags and their associated protocols are in the standard, and since the beginning.
The <video> tag has many attributes to customize the player, and a protocol. It is standard even if one is not able to choose a codec due to patents on the techniques used.
XHTML and HTML code are part of the same standard. These are two different ways of describing the same elements for different purposes. Browsers support both formulations.
Canvas 2D is an API for using the Canvas tag. There are others for storage, drag and drop, microdata, the offline mode. It is part of the WHATWG specification even if they are not HTML tags, but are not all parts of the W3C version.
Drag and drop, microdata, RDFa, content editable, offline, are part of HTML 5.
Complements to HTML 5 but not part of it
DOM is the structure of a document and the way to access its elements, it is originally the subject of a separate specification of the W3C and had three main iterations: DOM Level 1, 2 and 3. DOM 4 is being defined. When creating HTML 5, the WHATWG has decided to merge the two standards. It is part of HTML 5 for WHATWG which is concerned only with HTML, but not for the W3C which also defines the XML specification and DOM also supports this format.
Version 3 provides many effects including shadows and gradients very useful for improving the appearance of an application. This goes along with the new HTML role which is to serve as interface, but so far, it is not part of HTML 5. Instead we want to completely separate the content and structure of its appearance which is given by CSS.
It is an API to manage a database on the client from the browser. It succeeds WebDB which was abandoned by the W3C. This is another thing that complements HTML 5, the interface language of Web applications, but is not part of it.
FileReader and FileWriter are part of the File API spec., not HTML 5, but works in conjunction with XMLHttpRequest (prior to HTML5) and Web Workers as well as the <input> tag. In fact FileWriter is also defined in a separate specification.
LocalStorage, successor to cookies, can store large amounts of data on the client workstation, so in the browser. As well as sessionStorage, it was initialialement part of HTML 5 and then turned into an independent standard by the W3C.
This is a different specification even if the API works in web pages. It helps to know the location of customers and thus to provide services based on where they live.
This protocol of bidirectional access between the browser and the server is standardized by the IETF and has nothing to do with HTML 5. But we tend to use them together, it is ideally suited for applications that work with a local server, among others (it consumes a lot of bandwidth which limits the use of the Web). W3C has a spec for the WebSocket API.
WebRTC is in a W3C specification independent of HTML 5 too.
Beyond these core API, there are many others that confirm the role of HTML 5 to be the interface for universal applications in the browser, either locally or on the Web. HTML 5 is normally the interface language. But these elements are associated to a protocol of use, which led to incorporate it in the API specification. Others have been developed separately to avoid overloading, so everything is rather a matter of history than logic.