Shape of the universe (updated)

From Wikipedia, the free encyclopedia

https://en.wikipedia.org/wiki/Shape_of_the_universe

The shape of the universe is the local and global geometry of the universe. The local features of the geometry of the universe are primarily described by its curvature, whereas the topology of the universe describes general global properties of its shape as of a continuous object. The shape of the universe is related to general relativity, which describes how spacetime is curved and bent by mass and energy. 

Cosmologists distinguish between the observable universe and the global universe. The observable universe consists of the part of the universe that can, in principle, be observed by light reaching Earth within the age of the universe. It encompasses a region of space that currently forms a ball centered at Earth of estimated radius 46.5 billion light-years (4.40×10²⁶ m). This does not mean the universe is 46.5 billion years old; instead the universe is measured to be 13.8 billion years old, but space itself has also expanded, causing the size of the observable universe to be larger than the distance traversible by light over the duration of its current age. Assuming an isotropic nature, the observable universe is similar for all contemporary vantage points.

The global shape of the universe can be described with three attributes:

1. Finite or infinite
2. Flat (no curvature), open (negative curvature), or closed (positive curvature)
3. Connectivity, how the universe is put together, i.e., simply connected space or multiply connected.

There are certain logical connections among these properties. For example, a universe with positive curvature is necessarily finite. Although it is usually assumed in the literature that a flat or negatively curved universe is infinite, this need not be the case if the topology is not the trivial one: for example, a three-torus is flat but finite.

The exact shape is still a matter of debate in physical cosmology, but experimental data from various independent sources (WMAP, BOOMERanG, and Planck for example) confirm that the universe is flat with only a 0.4% margin of error. Theorists have been trying to construct a formal mathematical model of the shape of the universe. In formal terms, this is a 3-manifold model corresponding to the spatial section (in comoving coordinates) of the 4-dimensional spacetime of the universe. The model most theorists currently use is the Friedmann–Lemaître–Robertson–Walker (FLRW) model. Arguments have been put forward that the observational data best fit with the conclusion that the shape of the global universe is infinite and flat, but the data are also consistent with other possible shapes, such as the so-called Poincaré dodecahedral space and the Sokolov–Starobinskii space (quotient of the upper half-space model of hyperbolic space by 2-dimensional lattice).

 

 

Shape of the observable universe

As stated in the introduction, there are two aspects to consider:

1. its local geometry, which predominantly concerns the curvature of the universe, particularly the observable universe, and
2. its global geometry, which concerns the topology of the universe as a whole.

The observable universe can be thought of as a sphere that extends outwards from any observation point for 46.5 billion light years, going farther back in time and more redshifted the more distant away one looks. Ideally, one can continue to look back all the way to the Big Bang; in practice, however, the farthest away one can look using light and other electromagnetic radiation is the cosmic microwave background (CMB), as anything past that was opaque. Experimental investigations show that the observable universe is very close to isotropic and homogeneous. 

If the observable universe encompasses the entire universe, we may be able to determine the structure of the entire universe by observation. However, if the observable universe is smaller than the entire universe, our observations will be limited to only a part of the whole, and we may not be able to determine its global geometry through measurement. From experiments, it is possible to construct different mathematical models of the global geometry of the entire universe, all of which are consistent with current observational data; thus it is currently unknown whether the observable universe is identical to the global universe, or is instead many orders of magnitude smaller. The universe may be small in some dimensions and not in others (analogous to the way a cuboid is longer in the dimension of length than it is in the dimensions of width and depth). To test whether a given mathematical model describes the universe accurately, scientists look for the model's novel implications—what are some phenomena in the universe that we have not yet observed, but that must exist if the model is correct—and they devise experiments to test whether those phenomena occur or not. For example, if the universe is a small closed loop, one would expect to see multiple images of an object in the sky, although not necessarily images of the same age. 

Cosmologists normally work with a given space-like slice of spacetime called the comoving coordinates, the existence of a preferred set of which is possible and widely accepted in present-day physical cosmology. The section of spacetime that can be observed is the backward light cone (all points within the cosmic light horizon, given time to reach a given observer), while the related term Hubble volume can be used to describe either the past light cone or comoving space up to the surface of last scattering. To speak of "the shape of the universe (at a point in time)" is ontologically naive from the point of view of special relativity alone: due to the relativity of simultaneity we cannot speak of different points in space as being "at the same point in time" nor, therefore, of "the shape of the universe at a point in time". However, the comoving coordinates (if well-defined) provide a strict sense to those by using the time since the Big Bang (measured in the reference of CMB) as a distinguished universal time. 

Curvature of the universe

The curvature is a quantity describing how the geometry of a space differs locally from the one of the flat space. The curvature of any locally isotropic space (and hence of a locally isotropic universe) falls into one of the three following cases:

1. Zero curvature (flat); a drawn triangle's angles add up to 180° and the Pythagorean theorem holds; such 3-dimensional space is locally modeled by Euclidean space E³.
2. Positive curvature; a drawn triangle's angles add up to more than 180°; such 3-dimensional space is locally modeled by a region of a 3-sphere S³.
3. Negative curvature; a drawn triangle's angles add up to less than 180°; such 3-dimensional space is locally modeled by a region of a hyperbolic space H³.

Curved geometries are in the domain of Non-Euclidean geometry. An example of a positively curved space would be the surface of a sphere such as the Earth. A triangle drawn from the equator to a pole will have at least two angles equal 90°, which makes the sum of the 3 angles greater than 180°. An example of a negatively curved surface would be the shape of a saddle or mountain pass. A triangle drawn on a saddle surface will have the sum of the angles adding up to less than 180°.

The local geometry of the universe is determined by whether the density parameter Ω is greater than, less than, or equal to 1.
From top to bottom: a spherical universe with Ω > 1, a hyperbolic universe with Ω < 1, and a flat universe with Ω = 1. These depictions of two-dimensional surfaces are merely easily visualizable analogs to the 3-dimensional structure of (local) space.

 

General relativity explains that mass and energy bend the curvature of spacetime and is used to determine what curvature the universe has by using a value called the density parameter, represented with Omega (Ω). The density parameter is the average density of the universe divided by the critical energy density, that is, the mass energy needed for a universe to be flat. Put another way,

• If Ω = 1, the universe is flat
• If Ω > 1, there is positive curvature
• if Ω < 1 there is negative curvature

One can experimentally calculate this Ω to determine the curvature two ways. One is to count up all the mass-energy in the universe and take its average density then divide that average by the critical energy density. Data from Wilkinson Microwave Anisotropy Probe (WMAP) as well as the Planck spacecraft give values for the three constituents of all the mass-energy in the universe – normal mass (baryonic matter and dark matter), relativistic particles (photons and neutrinos), and dark energy or the cosmological constant:

Ω_mass ≈ 0.315±0.018

Ω_relativistic ≈ 9.24×10⁻⁵

Ω_Λ ≈ 0.6817±0.0018

Ω_total= Ω_mass + Ω_relativistic + Ω_Λ= 1.00±0.02

The actual value for critical density value is measured as ρ_critical= 9.47×10⁻²⁷ kg m⁻³. From these values, within experimental error, the universe seems to be flat.

Another way to measure Ω is to do so geometrically by measuring an angle across the observable universe. We can do this by using the CMB and measuring the power spectrum and temperature anisotropy. For an intuition, one can imagine finding a gas cloud that is not in thermal equilibrium due to being so large that light speed cannot propagate the thermal information. Knowing this propagation speed, we then know the size of the gas cloud as well as the distance to the gas cloud, we then have two sides of a triangle and can then determine the angles. Using a method similar to this, the BOOMERanG experiment has determined that the sum of the angles to 180° within experimental error, corresponding to an Ω_total ≈ 1.00±0.12.

These and other astronomical measurements constrain the spatial curvature to be very close to zero, although they do not constrain its sign. This means that although the local geometries of spacetime are generated by the theory of relativity based on spacetime intervals, we can approximate 3-space by the familiar Euclidean geometry. 

The Friedmann–Lemaître–Robertson–Walker (FLRW) model using Friedmann equations is commonly used to model the universe. The FLRW model provides a curvature of the universe based on the mathematics of fluid dynamics, that is, modeling the matter within the universe as a perfect fluid. Although stars and structures of mass can be introduced into an "almost FLRW" model, a strictly FLRW model is used to approximate the local geometry of the observable universe. Another way of saying this is that if all forms of dark energy are ignored, then the curvature of the universe can be determined by measuring the average density of matter within it, assuming that all matter is evenly distributed (rather than the distortions caused by 'dense' objects such as galaxies). This assumption is justified by the observations that, while the universe is "weakly" inhomogeneous and anisotropic (see the large-scale structure of the cosmos), it is on average homogeneous and isotropic. 

Global universe structure

Global structure covers the geometry and the topology of the whole universe—both the observable universe and beyond. While the local geometry does not determine the global geometry completely, it does limit the possibilities, particularly a geometry of a constant curvature. The universe is often taken to be a geodesic manifold, free of topological defects; relaxing either of these complicates the analysis considerably. A global geometry is a local geometry plus a topology. It follows that a topology alone does not give a global geometry: for instance, Euclidean 3-space and hyperbolic 3-space have the same topology but different global geometries.

As stated in the introduction, investigations within the study of the global structure of the universe include:

• Whether the universe is infinite or finite in extent
• Whether the geometry of the global universe is flat, positively curved, or negatively curved
• Whether the topology is simply connected like a sphere or multiply connected, like a torus

Infinite or finite

One of the presently unanswered questions about the universe is whether it is infinite or finite in extent. For intuition, it can be understood that a finite universe has a finite volume that, for example, could be in theory filled up with a finite amount of material, while an infinite universe is unbounded and no numerical volume could possibly fill it. Mathematically, the question of whether the universe is infinite or finite is referred to as boundedness. An infinite universe (unbounded metric space) means that there are points arbitrarily far apart: for any distance d, there are points that are of a distance at least d apart. A finite universe is a bounded metric space, where there is some distance d such that all points are within distance d of each other. The smallest such d is called the diameter of the universe, in which case the universe has a well-defined "volume" or "scale." 

With or without boundary

Assuming a finite universe, the universe can either have an edge or no edge. Many finite mathematical spaces, e.g., a disc, have an edge or boundary. Spaces that have an edge are difficult to treat, both conceptually and mathematically. Namely, it is very difficult to state what would happen at the edge of such a universe. For this reason, spaces that have an edge are typically excluded from consideration. 

However, there exist many finite spaces, such as the 3-sphere and 3-torus, which have no edges. Mathematically, these spaces are referred to as being compact without boundary. The term compact basically means that it is finite in extent ("bounded") and complete. The term "without boundary" means that the space has no edges. Moreover, so that calculus can be applied, the universe is typically assumed to be a differentiable manifold. A mathematical object that possesses all these properties, compact without boundary and differentiable, is termed a closed manifold. The 3-sphere and 3-torus are both closed manifolds.

Curvature

The curvature of the universe places constraints on the topology. If the spatial geometry is spherical, i.e., possess positive curvature, the topology is compact. For a flat (zero curvature) or a hyperbolic (negative curvature) spatial geometry, the topology can be either compact or infinite. Many textbooks erroneously state that a flat universe implies an infinite universe; however, the correct statement is that a flat universe that is also simply connected implies an infinite universe. For example, Euclidean space is flat, simply connected, and infinite, but the torus is flat, multiply connected, finite, and compact. 

In general, local to global theorems in Riemannian geometry relate the local geometry to the global geometry. If the local geometry has constant curvature, the global geometry is very constrained, as described in Thurston geometries. 

The latest research shows that even the most powerful future experiments (like the SKA) will not be able to distinguish between flat, open and closed universe if the true value of cosmological curvature parameter is smaller than 10⁻⁴. If the true value of the cosmological curvature parameter is larger than 10⁻³ we will be able to distinguish between these three models even now.

Results of the Planck mission released in 2015 show the cosmological curvature parameter, Ω_K, to be 0.000±0.005, consistent with a flat universe.

Universe with zero curvature

In a universe with zero curvature, the local geometry is flat. The most obvious global structure is that of Euclidean space, which is infinite in extent. Flat universes that are finite in extent include the torus and Klein bottle. Moreover, in three dimensions, there are 10 finite closed flat 3-manifolds, of which 6 are orientable and 4 are non-orientable. These are the Bieberbach manifolds. The most familiar is the aforementioned 3-torus universe.

In the absence of dark energy, a flat universe expands forever but at a continually decelerating rate, with expansion asymptotically approaching zero. With dark energy, the expansion rate of the universe initially slows down, due to the effect of gravity, but eventually increases. The ultimate fate of the universe is the same as that of an open universe.

A flat universe can have zero total energy. 

Universe with positive curvature

Universe in an expanding sphere. The galaxies farthest away are moving fastest and hence experience length contraction and so become smaller to an observer in the centre.

 

A positively curved universe is described by elliptic geometry, and can be thought of as a three-dimensional hypersphere, or some other spherical 3-manifold (such as the Poincaré dodecahedral space), all of which are quotients of the 3-sphere. 

Poincaré dodecahedral space is a positively curved space, colloquially described as "soccerball-shaped", as it is the quotient of the 3-sphere by the binary icosahedral group, which is very close to icosahedral symmetry, the symmetry of a soccer ball. This was proposed by Jean-Pierre Luminet and colleagues in 2003 and an optimal orientation on the sky for the model was estimated in 2008.

Universe with negative curvature

A hyperbolic universe, one of a negative spatial curvature, is described by hyperbolic geometry, and can be thought of locally as a three-dimensional analog of an infinitely extended saddle shape. There are a great variety of hyperbolic 3-manifolds, and their classification is not completely understood. Those of finite volume can be understood via the Mostow rigidity theorem. For hyperbolic local geometry, many of the possible three-dimensional spaces are informally called "horn topologies", so called because of the shape of the pseudosphere, a canonical model of hyperbolic geometry. An example is the Picard horn, a negatively curved space, colloquially described as "funnel-shaped".

Curvature: open or closed

When cosmologists speak of the universe as being "open" or "closed", they most commonly are referring to whether the curvature is negative or positive. These meanings of open and closed are different from the mathematical meaning of open and closed used for sets in topological spaces and for the mathematical meaning of open and closed manifolds, which gives rise to ambiguity and confusion. In mathematics, there are definitions for a closed manifold (i.e., compact without boundary) and open manifold (i.e., one that is not compact and without boundary). A "closed universe" is necessarily a closed manifold. An "open universe" can be either a closed or open manifold. For example, in the Friedmann–Lemaître–Robertson–Walker (FLRW) model the universe is considered to be without boundaries, in which case "compact universe" could describe a universe that is a closed manifold. 

Milne model ("spherical" expanding)

If one applies Minkowski space-based special relativity to expansion of the universe, without resorting to the concept of a curved spacetime, then one obtains the Milne model. Any spatial section of the universe of a constant age (the proper time elapsed from the Big Bang) will have a negative curvature; this is merely a pseudo-Euclidean geometric fact analogous to one that concentric spheres in the flat Euclidean space are nevertheless curved. Spatial geometry of this model is an unbounded hyperbolic space. The entire universe is contained within a light cone, namely the future cone of the Big Bang. For any given moment t > 0 of coordinate time (assuming the Big Bang has t = 0), the entire universe is bounded by a sphere of radius exactly c t. The apparent paradox of an infinite universe contained within a sphere is explained with length contraction: the galaxies farther away, which are travelling away from the observer the fastest, will appear thinner.

This model is essentially a degenerate FLRW for Ω = 0. It is incompatible with observations that definitely rule out such a large negative spatial curvature. However, as a background in which gravitational fields (or gravitons) can operate, due to diffeomorphism invariance, the space on the macroscopic scale, is equivalent to any other (open) solution of Einstein's field equations.

XMLHttpRequest

From Wikipedia, the free encyclopedia

https://en.wikipedia.org/wiki/XMLHttpRequest

XMLHttpRequest (XHR) is an API in the form of an object whose methods transfer data between a web browser and a web server. The object is provided by the browser's JavaScript environment. Particularly, retrieval of data from XHR for the purpose of continually modifying a loaded web page is the underlying concept of Ajax design. Despite the name, XHR can be used with protocols other than HTTP and data can be in the form of not only XML, but also JSON, HTML or plain text.

WHATWG maintains an XHR standard as a living document. Ongoing work at the W3C to create a stable specification is based on snapshots of the WHATWG standard.

History

The concept behind the XMLHttpRequest object was originally created by the developers of Outlook Web Access (by Microsoft) for Microsoft Exchange Server 2000. An interface called IXMLHTTPRequest was developed and implemented into the second version of the MSXML library using this concept. The second version of the MSXML library was shipped with Internet Explorer 5.0 in March 1999, allowing access, via ActiveX, to the IXMLHTTPRequest interface using the XMLHTTP wrapper of the MSXML library.

Internet Explorer versions 5 and 6 did not define the XMLHttpRequest object identifier in their scripting languages as the XMLHttpRequest identifier itself was not standard at the time of their releases. Backward compatibility can be achieved through object detection if the XMLHttpRequest identifier does not exist. Microsoft added the XMLHttpRequest object identifier to its scripting languages in Internet Explorer 7.0 released in October 2006.

The Mozilla project developed and implemented an interface called nsIXMLHttpRequest into the Gecko layout engine. This interface was modeled to work as closely to Microsoft's IXMLHTTPRequest interface as possible. Mozilla created a wrapper to use this interface through a JavaScript object which they called XMLHttpRequest. The XMLHttpRequest object was accessible as early as Gecko version 0.6 released on December 6 of 2000, but it was not completely functional until as late as version 1.0 of Gecko released on June 5, 2002. The XMLHttpRequest object became a de facto standard in other major web clients, implemented in Safari 1.2 released in February 2004, Konqueror, Opera 8.0 released in April 2005, and iCab 3.0b352 released in September 2005.

With the advent of cross-browser JavaScript libraries such as jQuery, developers can invoke XMLHttpRequest functionality indirectly. 

Standards

The World Wide Web Consortium published a Working Draft specification for the XMLHttpRequest object on April 5, 2006, edited by Anne van Kesteren of Opera Software and Dean Jackson of W3C. Its goal is "to document a minimum set of interoperable features based on existing implementations, allowing Web developers to use these features without platform-specific code."

The W3C also published another Working Draft specification for the XMLHttpRequest object, "XMLHttpRequest Level 2", on February 25 of 2008. Level 2 consists of extended functionality to the XMLHttpRequest object, including, but not limited to, progress events, support for cross-site requests, and the handling of byte streams. At the end of 2011, the Level 2 specification was abandoned and absorbed into the original specification.

At the end of 2012, the WHATWG took over development and maintains a living standard using Web IDL. W3C's current drafts are based on snapshots of the WHATWG standard. 

HTTP request

The following sections demonstrate how a request using the XMLHttpRequest object functions within a conforming user agent based on the W3C Working Draft. As the W3C standard for the XMLHttpRequest object is still a draft, user agents may not abide by all the functionings of the W3C definition and any of the following is subject to change. Extreme care should be taken into consideration when scripting with the XMLHttpRequest object across multiple user agents. This article will try to list the inconsistencies between the major user agents.

The open method

The HTTP and HTTPS requests of the XMLHttpRequest object must be initialized through the open method. This method must be invoked prior to the actual sending of a request to validate and resolve the request method, URL, and URI user information to be used for the request. This method does not assure that the URL exists or the user information is correct. This method can accept up to five parameters, but requires only two, to initialize a request.

open( Method, URL, Asynchronous, UserName, Password )

The first parameter of the method is a text string indicating the HTTP request method to use. The request methods that must be supported by a conforming user agent, defined by the W3C draft for the XMLHttpRequest object, are currently listed as the following.

• GET (supported by Internet Explorer 7 (and later), Mozilla 1+)
• POST (supported by IE7 (and later), Mozilla 1 (and later))
• HEAD (supported by IE7 (and later))
• PUT
• DELETE
• OPTIONS (supported by IE7 (and later))

However, request methods are not limited to the ones listed above. The W3C draft states that a browser may support additional request methods at their own discretion.

The second parameter of the method is another text string, this one indicating the URL of the HTTP request. The W3C recommends that browsers should raise an error and not allow the request of a URL with either a different port or ihost URI component from the current document.

The third parameter, a boolean value indicating whether or not the request will be asynchronous, is not a required parameter by the W3C draft. The default value of this parameter should be assumed to be true by a W3C conforming user agent if it is not provided. An asynchronous request ("true") will not wait on a server response before continuing on with the execution of the current script. It will instead invoke the onreadystatechange event listener of the XMLHttpRequest object throughout the various stages of the request. A synchronous request ("false") however will block execution of the current script until the request has been completed, thus not invoking the onreadystatechange event listener. Note that starting with Gecko 30.0 (Firefox 30.0 / Thunderbird 30.0 / SeaMonkey 2.27), Blink 39.0 (Chrome), and Edge 13, synchronous requests on the main thread have been deprecated due to their negative impact on the user experience as they will cause freezing of the UI while the thread performs the request.

The fourth and fifth parameters are the username and password, respectively. These parameters, or just the username, may be provided for authentication and authorization if required by the server for this request. 

var xmlhttp;

if (window.XMLHttpRequest) {
    xmlhttp = new XMLHttpRequest();
    xmlhttp.open("GET", filepath, false);
    xmlhttp.send(null);
}

The setRequestHeader method

Upon successful initialization of a request, the setRequestHeader method of the XMLHttpRequest object can be invoked to send HTTP headers with the request.

setRequestHeader( Name, Value )

The first parameter of this method is the text string name of the header. The second parameter is the text string value. This method must be invoked for each header that needs to be sent with the request. Any headers attached here will be removed the next time the open method is invoked in a W3C conforming user agent.

The send method

To send an HTTP request, the send method of the XMLHttpRequest must be invoked. This method accepts a single parameter containing the content to be sent with the request. 

send( Data )

This parameter may be omitted if no content needs to be sent. The W3C draft states that this parameter may be any type available to the scripting language as long as it can be turned into a text string, with the exception of the DOM document object. If a user agent cannot serialise the parameter, then the parameter should be ignored. Firefox 3.0.x and previous versions will however throw an exception if send is called without an argument.

If the parameter is a DOM document object, a user agent should assure the document is turned into well-formed XML using the encoding indicated by the inputEncoding property of the document object. If the Content-Type request header was not added through setRequestHeader yet, it should automatically be added by a conforming user agent as "application/xml;charset=charset," where charset is the encoding used to encode the document.

If the user agent is configured to use a proxy server, then the XMLHttpRequest object will modify the request appropriately so as to connect to the proxy instead of the origin server, and send Proxy-Authorization headers as configured.

The onreadystatechange event listener

If the open method of the XMLHttpRequest object was invoked with the third parameter set to true for an asynchronous request, the onreadystatechange event listener will be automatically invoked for each of the following actions that change the readyState property of the XMLHttpRequest object.

State changes work like this:

• State Description

   0  The request is not initialized.
   1  The request has been set up.
   2  The request has been sent.
   3  The request is in process.
   4  The request is completed.

• After the open method has been invoked successfully, the readyState property of the XMLHttpRequest object should be assigned a value of 1 (OPENED).
• After the send method has been invoked and the HTTP response headers have been received, the readyState property of the XMLHttpRequest object should be assigned a value of 2 (HEADERS_RECEIVED).
• Once the HTTP response content begins to load, the readyState property of the XMLHttpRequest object should be assigned a value of 3 (LOADING).
• Once the HTTP response content has finished loading, the readyState property of the XMLHttpRequest object should be assigned a value of 4 (DONE).

The listener will only respond to state changes which occur after the listener is defined. To detect states 1 and 2, the listener must be defined before the open method is invoked. The open method must be invoked before the send method is invoked.

var request = new XMLHttpRequest();
request.onreadystatechange = function () {
    var DONE = this.DONE || 4;
    if (this.readyState === DONE){
        alert(this.readyState);
    }
};
request.open('GET', 'somepage.xml', true);
request.setRequestHeader('X-Requested-With', 'XMLHttpRequest'); 

// Tells server that this call is made for ajax purposes. 

// Most libraries like jQuery/Prototype/Dojo do this
request.send(null);  // No data needs to be sent along with the request.

The HTTP response

After a successful and completed call to the send method of the XMLHttpRequest, if the server response was well-formed XML and the Content-Type header sent by the server is understood by the user agent as an Internet media type for XML, the responseXML property of the XMLHttpRequest object will contain a DOM document object. Another property, responseText will contain the response of the server in plain text by a conforming user agent, regardless of whether or not it was understood as XML.

Cross-domain requests

In the early development of the World Wide Web, it was found possible to breach users' security by the use of JavaScript to exchange information from one web site with that from another less reputable one. All modern browsers therefore implement a same origin policy that prevents many such attacks, such as cross-site scripting. XMLHttpRequest data is subject to this security policy, but sometimes web developers want to intentionally circumvent its restrictions. This is sometimes due to the legitimate use of subdomains as, for example, making an XMLHttpRequest from a page created by foo.example.com for information from bar.example.com will normally fail.

Various alternatives exist to circumvent this security feature, including using JSONP, Cross-Origin Resource Sharing (CORS) or alternatives with plugins such as Flash or Silverlight. Cross-origin XMLHttpRequest is specified in W3C's XMLHttpRequest Level 2 specification. Internet Explorer did not implement CORS until version 10. The two previous versions (8 and 9) offered similar functionality through the XDomainRequest (XDR) API. CORS is now supported by all modern browsers (desktop and mobile).

The CORS protocol has several restrictions, with two models of support. The simple model does not allow setting custom request headers and omits cookies. Further, only the HEAD, GET and POST request methods are supported, and POST only allows the following MIME types: "text/plain", "application/x-www-urlencoded" and "multipart/form-data". Only "text/plain" was initially supported. The other model detects when one of the non-simple features are requested and sends a pre-flight request to the server to negotiate the feature.

Fetch alternative

Program flow using asynchronous XHR callbacks can present difficulty with readability and maintenance. ECMAScript 2015 (ES6) added the promise construct to simplify asynchronous logic. Browsers have since implemented the alternative fetch() interface to achieve the same functionality as XHR using promises instead of callbacks. 

Fetch is also standardized by WHATWG.

HTML5

From Wikipedia, the free encyclopedia

https://en.wikipedia.org/wiki/HTML5

 

HTML5
(HyperText Markup Language)

Filename extension	.html, .htm
Internet media type	text/html
Type code	TEXT
Uniform Type Identifier (UTI)	public.html
Developed by	W3C
Initial release	28 October 2014 (5 years ago)
Type of format	Markup language
Standard	HTML 5.2
Open format?	Yes

HTML5 is a software solution stack that defines the properties and behaviors of web page content by implementing a markup based pattern to it.

HTML5 was the fifth and last major version of HTML that is a World Wide Web Consortium (W3C) recommendation. The current specification is known as the HTML Living Standard and is maintained by a consortium of the major browser vendors (Apple, Google, Mozilla, and Microsoft), the Web Hypertext Application Technology Working Group (WHATWG).

HTML5 was first released in public-facing form on 22 January 2008, with a major update and "W3C Recommendation" status in October 2014. Its goals were to improve the language with support for the latest multimedia and other new features; to keep the language both easily readable by humans and consistently understood by computers and devices such as web browsers, parsers, etc., without XHTML's rigidity; and to remain backward-compatible with older software. HTML5 is intended to subsume not only HTML 4, but also XHTML 1 and DOM Level 2 HTML.

HTML5 includes detailed processing models to encourage more interoperable implementations; it extends, improves and rationalizes the markup available for documents, and introduces markup and application programming interfaces (APIs) for complex web applications. For the same reasons, HTML5 is also a candidate for cross-platform mobile applications, because it includes features designed with low-powered devices in mind.

Many new syntactic features are included. To natively include and handle multimedia and graphical content, the new , and elements were added, and support for scalable vector graphics (SVG) content and MathML for mathematical formulas. To enrich the semantic content of documents, new page structure elements such as

,

,

,

,

,

,

, and

are added. New attributes are introduced, some elements and attributes have been removed, and others such as , , and have been changed, redefined, or standardized.

The APIs and Document Object Model (DOM) are now fundamental parts of the HTML5 specification and HTML5 also better defines the processing for any invalid documents.

History

The Web Hypertext Application Technology Working Group (WHATWG) began work on the new standard in 2004. At that time, HTML 4.01 had not been updated since 2000, and the World Wide Web Consortium (W3C) was focusing future developments on XHTML 2.0. In 2009, the W3C allowed the XHTML 2.0 Working Group's charter to expire and decided not to renew it.

The Mozilla Foundation and Opera Software presented a position paper at a World Wide Web Consortium (W3C) workshop in June 2004, focusing on developing technologies that are backward-compatible with existing browsers, including an initial draft specification of Web Forms 2.0. The workshop concluded with a vote—8 for, 14 against—for continuing work on HTML. Immediately after the workshop, WHATWG was formed to start work based upon that position paper, and a second draft, Web Applications 1.0, was also announced. The two specifications were later merged to form HTML5. The HTML5 specification was adopted as the starting point of the work of the new HTML working group of the W3C in 2007. 

WHATWG's Ian Hickson (Google) and David Hyatt (Apple) produced W3C's first public working draft of the specification on 22 January 2008.

"Thoughts on Flash"

While some features of HTML5 are often compared to Adobe Flash, the two technologies are very different. Both include features for playing audio and video within web pages, and for using Scalable Vector Graphics. However, HTML5 on its own cannot be used for animation or interactivity – it must be supplemented with CSS3 or JavaScript. There are many Flash capabilities that have no direct counterpart in HTML5 (see Comparison of HTML5 and Flash). HTML5's interactive capabilities became a topic of mainstream media attention around April 2010 after Apple Inc.'s then-CEO Steve Jobs issued a public letter titled "Thoughts on Flash" in which he concluded that "Flash is no longer necessary to watch video or consume any kind of web content" and that "new open standards created in the mobile era, such as HTML5, will win". This sparked a debate in web development circles suggesting that, while HTML5 provides enhanced functionality, developers must consider the varying browser support of the different parts of the standard as well as other functionality differences between HTML5 and Flash. In early November 2011, Adobe announced that it would discontinue development of Flash for mobile devices and reorient its efforts in developing tools using HTML5. On 25 July 2017, Adobe announced that both the distribution and support of Flash will cease by the end of 2020.

Last call, candidacy, and recommendation stages

On 14 February 2011, the W3C extended the charter of its HTML Working Group with clear milestones for HTML5. In May 2011, the working group advanced HTML5 to "Last Call", an invitation to communities inside and outside W3C to confirm the technical soundness of the specification. The W3C developed a comprehensive test suite to achieve broad interoperability for the full specification by 2014, which was the target date for recommendation. In January 2011, the WHATWG renamed its "HTML5" specification HTML Living Standard. The W3C nevertheless continued its project to release HTML5.

In July 2012, WHATWG and W3C decided on a degree of separation. W3C will continue the HTML5 specification work, focusing on a single definitive standard, which is considered as a "snapshot" by WHATWG. The WHATWG organization continues its work with HTML5 as a "living standard". The concept of a living standard is that it is never complete and is always being updated and improved. New features can be added but functionality will not be removed.

In December 2012, W3C designated HTML5 as a Candidate Recommendation. The criterion for advancement to W3C Recommendation is "two 100% complete and fully interoperable implementations".

On 16 September 2014, W3C moved HTML5 to Proposed Recommendation. On 28 October 2014, HTML5 was released as a W3C Recommendation, bringing the specification process to completion. On 1 November 2016, HTML 5.1 was released as a W3C Recommendation. On 14 December 2017, HTML 5.2 was released as a W3C Recommendation.

Timeline

The combined timelines for HTML 5.0, HTML 5.1 and HTML 5.2:

Version	First draft	Candidate recommendation	Recommendation
HTML 5.0	2007	2012	2014
HTML 5.1	2012	2015	2016
HTML 5.2	2015	2017	2017
HTML 5.3	2017	N/A	N/A

 

W3C and WHATWG conflict

The W3C ceded authority over the HTML and DOM standards to WHATWG on 28 May 2019, recognizing that having 2 standards is harmful. The HTML Living Standard is now authoritative. However, W3C will still participate in the development process of HTML.

Before the ceding of authority, W3C and WHATWG had been characterized as both working together on the development of HTML5, and yet also at cross purposes ever since the July 2012 split, creating WHATWG. The W3C standard was snapshot-based and static, while the WHATWG is a continually updated "living standard". The relationship had been described as "fragile", even a "rift", and characterized by "squabbling".

In at least one case, namely the permissible content of the <cite> element, the two specifications directly contradicted each other (as of July 2018), with the W3C definition being permissive and reflecting traditional use of the element since its introduction, but WHATWG limiting it to a single defined type of content (the title of the work cited). This is actually at odds with WHATWG's stated goals of ensuring backward compatibility and not losing prior functionality.

The "Introduction" section in the WHATWG spec (edited by Ian "Hixie" Hickson) is critical of W3C, e.g. "Note: Although we have asked them to stop doing so, the W3C also republishes some parts of this specification as separate documents." In its "History" subsection it portrays W3C as resistant to Hickson's and WHATWG's original HTML 5 plans, then jumping on the bandwagon belatedly (though Hickson was in control of the W3C HTML 5 spec, too). Regardless, it indicates a major philosophical divide between the organizations:

For a number of years, both groups then worked together. In 2011, however, the groups came to the conclusion that they had different goals: the W3C wanted to publish a "finished" version of "HTML5", while the WHATWG wanted to continue working on a Living Standard for HTML, continuously maintaining the specification rather than freezing it in a state with known problems, and adding new features as needed to evolve the platform.
Since then, the WHATWG has been working on this specification (amongst others), and the W3C has been copying fixes made by the WHATWG into their fork of the document (which also has other changes).

The two entities signed an agreement to work together on a single version of HTML on 28 May 2019.

Differences between the two standards

In addition to the contradiction in the <cite> element mentioned above, other differences between the two standards include at least the following, as of September 2018:

Content or Features Unique to W3C or WHATWG Standard

	W3C	WHATWG
Site pagination		Single page version (allows global search of contents)
Chapters		§5 Microdata §9 Communication §10 Web workers §11 Web storage
Global attributes	: class, id	: autocapitalize, enterkeyhint, inputmode, is, itemid, itemprop, itemref, itemscope, itemtype, nonce
Chapter Elements of HTML		§4.13 Custom elements
Elements	, is in section Grouping content.	, , is in section Sections.
§	§4.2.5.4. Other pragma directives, based on deprecated WHATWG procedure.
§ Sections		§ 4.3.11.2 Sample outlines § 4.3.11.3 Exposing outlines to users
Structured data	Recommends RDFa (code examples, separate specs, no special attributes).	Recommends Microdata (code examples, spec chapter, special attributes).

The following table provides data from the Mozilla Development Network on compatibility with major browsers, as of September 2018, of HTML elements unique to one of the standards:

Element	Standard	Compatibility	Note
	W3C	All browsers, except Edge
	W3C	None, except Firefox
	WHATWG	All browsers	"[Since] the HTML outline algorithm is not implemented in any browsers ... the semantics are in practice only theoretical."
	WHATWG	Full support only in Edge and Firefox desktop. Partial support in Firefox mobile. Supported in Opera with user opt-in. Not supported in other browsers.	Experimental technology
	WHATWG	All browsers, except Edge and IE	Experimental technology

Features and APIs

The W3C proposed a greater reliance on modularity as a key part of the plan to make faster progress, meaning identifying specific features, either proposed or already existing in the spec, and advancing them as separate specifications. Some technologies that were originally defined in HTML 5 itself are now defined in separate specifications:

• HTML Working Group – HTML Canvas 2D Context;
• Web Apps Working Group – Web Messaging, Web workers, Web storage, WebSocket, Server-sent events, Web Components (this was not part of HTML 5, though); the Web Applications Working Group was closed in October 2015 and its deliverables transferred to the Web Platform Working Group (WPWG).
• IETF HyBi Working Group – WebSocket Protocol;
• WebRTC Working Group – WebRTC;
• Web Media Text Tracks Community Group – WebVTT.

After the standardization of the HTML 5 specification in October 2014, the core vocabulary and features are being extended in four ways. Likewise, some features that were removed from the original HTML 5 specification have been standardized separately as modules, such as Microdata and Canvas. Technical specifications introduced as HTML 5 extensions such as Polyglot markup have also been standardized as modules. Some W3C specifications that were originally separate specifications have been adapted as HTML 5 extensions or features, such as SVG. Some features that might have slowed down the standardization of HTML 5 will be standardized as upcoming specifications, instead. HTML 5.1 was finalized in 2016, and it is currently on the standardization track at the W3C.

Features

Markup

HTML 5 introduces elements and attributes that reflect typical usage on modern websites. Some of them are semantic replacements for common uses of generic block (

) and inline () elements, for example

(website navigation block),

(usually referring to bottom of web page or to last lines of HTML code), or and instead of . Some deprecated elements from HTML 4.01 have been dropped, including purely presentational elements such as and , whose effects have long been superseded by the more capable Cascading Style Sheets. There is also a renewed emphasis on the importance of DOM scripting in Web behavior. 

The HTML 5 syntax is no longer based on SGML despite the similarity of its markup. It has, however, been designed to be backward-compatible with common parsing of older versions of HTML. It comes with a new introductory line that looks like an SGML document type declaration, , which triggers the standards-compliant rendering mode. Since 5 January 2009, HTML 5 also includes Web Forms 2.0, a previously separate WHATWG specification.

New APIs

HTML5 related APIs

 

In addition to specifying markup, HTML 5 specifies scripting application programming interfaces (APIs) that can be used with JavaScript. Existing Document Object Model (DOM) interfaces are extended and de facto features documented. There are also new APIs, such as:

• Canvas;
• Timed Media Playback;
• Offline;
• Editable content;
• Drag and drop;
• History;
• MIME type and protocol handler registration;
• Microdata;
• Web Messaging;
• Web Storage – a key-value pair storage framework that provides behaviour similar to cookies but with larger storage capacity and improved API.

Not all of the above technologies are included in the W3C HTML 5 specification, though they are in the WHATWG HTML specification. Some related technologies, which are not part of either the W3C HTML 5 or the WHATWG HTML specification, are as follows. The W3C publishes specifications for these separately:

• Geolocation;
• IndexedDB – an indexed hierarchical key-value store (formerly WebSimpleDB);
• File – an API intended to handle file uploads and file manipulation;^[107]
• Directories and System – an API intended to satisfy client-side-storage use cases not well served by databases;
• File Writer – an API for writing to files from web applications;
• Web Audio – a high-level JavaScript API for processing and synthesizing audio in web applications;
• ClassList.
• Web cryptography API
• WebRTC
• Web SQL Database – a local SQL Database (no longer maintained);

HTML 5 cannot provide animation within web pages. Additional JavaScript or CSS3 is necessary for animating HTML elements. Animation is also possible using JavaScript and HTML 4, and within SVG elements through SMIL, although browser support of the latter remains uneven as of 2011. 

XHTML 5 (XML-serialized HTML 5)

XML documents must be served with an XML Internet media type (often called "MIME type") such as application/xhtml+xml or application/xml, and must conform to strict, well-formed syntax of XML. XHTML 5 is simply XML-serialized HTML 5 data (that is, HTML 5 constrained to XHTML's strict requirements, e.g., not having any unclosed tags), sent with one of XML media types. HTML that has been written to conform to both the HTML and XHTML specifications  and which will therefore produce the same DOM tree whether parsed as HTML or XML is known as polyglot markup.

Error handling

HTML 5 is designed so that old browsers can safely ignore new HTML 5 constructs. In contrast to HTML 4.01, the HTML 5 specification gives detailed rules for lexing and parsing, with the intent that compliant browsers will produce the same results when parsing incorrect syntax. Although HTML 5 now defines a consistent behavior for "tag soup" documents, those documents are not regarded as conforming to the HTML 5 standard.

Popularity

According to a report released on 30 September 2011, 34 of the world's top 100 Web sites were using HTML 5 – the adoption led by search engines and social networks. Another report released in August 2013 has shown that 153 of the Fortune 500 U.S. companies implemented HTML5 on their corporate websites.

Since 2014, HTML 5 is at least partially supported by most popular layout engines.

Differences from HTML 4.01 and XHTML 1.x

The following is a cursory list of differences and some specific examples.

• New parsing rules: oriented towards flexible parsing and compatibility; not based on SGML
• Ability to use inline SVG and MathML in text/html
• New elements: article, aside, audio, bdi, canvas, command, data, datalist, details, embed, figcaption, figure, footer, header, keygen, mark, meter, nav, output, progress, rp, rt, ruby, section, source, summary, time, track, video, wbr
• New types of form controls: dates and times, email, url, search, number, range, tel, color
• New attributes: charset (on meta), async (on script)
• Global attributes (that can be applied for every element): id, tabindex, hidden, data-* (custom data attributes)
• Deprecated elements will be dropped altogether: acronym, applet, basefont, big, center, dir, font, frame, frameset, isindex, noframes, strike, tt

W3C Working Group publishes "HTML5 differences from HTML 4", which provides a complete outline of additions, removals and changes between HTML 5 and HTML 4. 

Logo

The W3C HTML5 logo

 

On 18 January 2011, the W3C introduced a logo to represent the use of or interest in HTML 5. Unlike other badges previously issued by the W3C, it does not imply validity or conformance to a certain standard. As of 1 April 2011, this logo is official.

When initially presenting it to the public, the W3C announced the HTML 5 logo as a "general-purpose visual identity for a broad set of open web technologies, including HTML 5, CSS, SVG, WOFF, and others". Some web standard advocates, including The Web Standards Project, criticized that definition of "HTML5" as an umbrella term, pointing out the blurring of terminology and the potential for miscommunication. Three days later, the W3C responded to community feedback and changed the logo's definition, dropping the enumeration of related technologies. The W3C then said the logo "represents HTML5, the cornerstone for modern Web applications".

Digital rights management

Industry players including the BBC, Google, Microsoft, Apple Inc. have been lobbying for the inclusion of Encrypted Media Extensions (EME), a form of digital rights management (DRM), into the HTML 5 standard. As of the end of 2012 and the beginning of 2013, 27 organisations including the Free Software Foundation have started a campaign against including digital rights management in the HTML 5 standard. However, in late September 2013, the W3C HTML Working Group decided that Encrypted Media Extensions, a form of DRM, was "in scope" and will potentially be included in the HTML 5.1 standard. WHATWG's "HTML Living Standard" continued to be developed without DRM-enabled proposals.

Manu Sporny, a member of the W3C, said that EME will not solve the problem it's supposed to address. Opponents point out that EME itself is just an architecture for a DRM plug-in mechanism.

The initial enablers for DRM in HTML 5 were Google and Microsoft. Supporters also include Adobe. On 14 May 2014, Mozilla announced plans to support EME in Firefox, the last major browser to avoid DRM. Calling it "a difficult and uncomfortable step", Andreas Gal of Mozilla explained that future versions of Firefox would remain open source but ship with a sandbox designed to run a content decryption module developed by Adobe. While promising to "work on alternative solutions", Mozilla's Executive Chair Mitchell Baker stated that a refusal to implement EME would have accomplished little more than convincing many users to switch browsers. This decision was condemned by Cory Doctorow and the Free Software Foundation.