HO-HO-HO! The holiday comes to us! Always coca-co ... HTML5!
A snowball fell and somehow imperceptibly a festive, pre-Christmas mood came. In order to somehow support the festive spirit, we decided to make a small surprise from the publisher and to please our readers with Mark Pilgrim’s free e-book “ HTML5. Developer's Guide ”(DIVE INTO HTML5). The original book is also in the free version on the Internet.

Before you download the entire book, we invite you to get acquainted with the first chapter:

Chapter 1. How did we get here?

Let's get started

Recently, I read a statement by a single developer for the Mozilla platform, which talks about the tension that always accompanies the development of standards:
')

Specification and software implementation must go the way of careful joint development. After all, on the one hand, I don’t want the implementation to appear before the final version of the standard comes out, otherwise the developers will take into account the features of a particular program, that is, only a fragment of the specification will work. On the other hand, I don’t want to state a complete standard before the release of at least one implementation, otherwise it will have to do without feedback, in particular, the opinions of the creators of the programs will not be taken into account. Contradiction is inevitable. It remains for us to solve the problem by trial and error.

While I'm going to tell you how HTML5 came about, remember these words.

MIME types

The book you hold in your hands is about HTML5, not the previous versions of the HTML standard, and certainly not XHTML. But in order to clearly trace the history of HTML5 and see the reasons for its appearance, you first need to master some technical details, in particular, to get an idea of ​​MIME types.

Each time your browser tries to load a page, the server sends a number of headers to the client’s program before sending the code of the page itself to the client program. The user usually does not see these headers, although some programs for web developers provide the ability to display them. The headings are important as long as they tell the browser how to perceive the code that the page is following. The most informative title is called Content-Type and looks like this:

Content-Type: text/html

The text/html value is called the content type, or the MIME type of the loaded page. Only this header defines what the content of the individual resource is and, therefore, how this resource should be displayed on the screen. The images have their own MIME types ( image/jpeg - for JPEG images, image/png - for PNG format, etc.). Javascript files, CSS style sheets and, in general, everything that is on the Web is provided with native MIME types.

In fact, everything is a little more complicated than described above. The earliest web servers, by which I mean web servers of 1993 and the next few years, did not send Content-Type headers, because they were only invented in 1994. For the sake of compatibility, in the name of which, by the way, from 1993 to this day, a lot of things have been and are being done, some popular browsers, under certain conditions, ignore the Content-Type headers. This is called content sniffing. But the general rule is that any piece of web content, whether it’s an HTML page, an image, a script, a video, a PDF document, or something else under its own URL, is sent to the client program with prior notification of the MIME type in the Content-Type header. Content-Type . Well remember this information, as it is still useful.

A big digression on how standards appear

Where did the tag come from? I do not think that at least you sometimes asked such a question. Obviously, someone created it. Such things do not come from nowhere. Of all the elements and attributes of HTML that you used at different times, absolutely everybody was once created by someone. This someone thought up how the element or attribute should work and formulated his thoughts in writing. This kind of people, no doubt, smarter than you and me, but they are also ordinary people.

If the standard was developed openly, you can go back in time and see how the idea of ​​a particular specification item was born. Discussions are conducted in mailing lists, and their archives usually have a search interface. To answer the question about the tag, I decided to study e-archeology a bit and plunged into the thickness of the times when the World Wide Web Consortium (W3C) did not exist yet, and all the web servers of the world could be counted on fingers. This is about the early days of the Internet.

On February 25, 1993, Marc Andreessen wrote :

I propose a new optional HTML tag:

IMG

If it must be required, the argument SRC = "url". The tag refers to a bitmap file (bitmap or pixmap). The browser will request this file on the web, recognize it as an image and insert it into the text according to the place
tag in the page code.
Usage example:


(A closing tag is not required.)

Like any other content, this tag can be embedded inside the anchor. Then the image will become sensitive to activation, like a regular text link. Browsers should be given the freedom to choose the graphic formats that will be supported in them. For example, Xbm and Xpm seem to me a good choice. If the browser
does not know how to display this format, even if it does what developers would like to provide for this case (for example, a raster image will be displayed in X Mosaic, replacing the desired image).

This functionality will be implemented in X Mosaic. We are working on it and are going to use it at least within the development team. Of course, I will be happy with your suggestions on what should be the mechanism for supporting images in HTML. If you have a better idea than mine, please share. I know that the variety of graphic formats makes the situation extremely vague, but I do not see an alternative. One can only say: “Let the browser work as it can” - and wait for the time when the ideal solution will be offered (maybe, someday, with the help of MIME types).

This quotation must be clarified. Xbm and Xpm are popular graphic formats on UNIX systems; Mosaic is one of the first browsers. His version, which worked on UNIX systems, was called X Mosaic. When Marc sent this letter to the discussion list in early 1993, he had not yet founded the company Mosaic Communications Corporation, which subsequently brought him fame, and had not yet begun work on the future company's flagship product — the Mosaic Netscape browser (the company and program were later renamed Netscape Corporation and Netscape Navigator respectively).

Speaking of MIME-types "maybe someday," Mark refers to the content negotiation mechanism provided by the HTTP protocol. Thanks to this mechanism, the client browser program tells the server (in this case, the web server) what types of resources it can process (for example, image/jpeg ), and the server can send back content in a format convenient for the client. As of February 1993, only the very first version of the HTTP protocol (1991) was implemented in software, in which the client could not transmit information about the supported image types to the server. Hence the problem that Mark faced. A few hours later, Tony Johnson replied:

In my Midas 2 .0 (the program is still in the internal use of SLAC, but already ready for an open release) a similar solution is applied. The tag is differently named, and it has another argument NAME = "name", but the functionality is exactly the same as that of the proposed IMG tag. Example:



NAME , «» . , , , , . , , .

( , ) . , -, , IMG SRC, IMAGE SOURCE . ICON — , , . ,
, ICON .
Midas is another early browser, a contemporary of X Mosaic. It was cross-platform and worked on both UNIX and VMS. The abbreviation SLAC stands for Stanford Linear Accelerator Center (Stanford Linear Accelerator (Electron) Research Center). Now this center has received the status of a national laboratory. SLAC engineers launched the first web server in the United States, which was actually the first outside of Europe. In February 1993, SLAC was considered the Network's long-liver (it worked for a year and three months!) With five web pages on the server.

Here is the continuation of the letter to Tony:

Since we are talking about new tags, I’ll tell you about another similar tag, the support of which I intend to implement in Midas 2 .0. His scheme is as follows:



, . , — -. HTTP2, .
Under the name HTTP2, the base HTTP appears in the 1992 edition. In early 1993, a significant part of it did not have software implementation. The draft, known as HTTP2, has been standardized as HTTP 1.0 after some refinement. The HTTP 1.0 standard already includes headers, requests for negotiating content, that is, the very “maybe someday” came pretty soon.

Tony ends his letter like this:

I considered the following alternative:

<A HREF="..." INCLUDE>.

I do not want to add new functionality to the tag . , INCLUDE . , INCLUDE, (« . » ) , INCLUDE. . , INCLUDE . , INCLUDE, (« . » ) , INCLUDE.
This proposal was not implemented, although the idea of ​​a replacement text in case there is no image is very attractive and is not mentioned in the tag construction proposed by Mark. Many years later, the idea was implemented in the attribute (after which everything was spoiled by Netscape, which mistakenly displayed the text of the deputy in the form of a tooltip).

A few hours after Tony’s posting, Tim Berners-Lee replied to him and Mark:

I thought that the pictures can be represented as The meaning of the reference relationship is:

EMBED - embed content in a given place in the document for display;
PRESENT - display content if the source document is available.

It is worth noting that various combinations of attributes are possible. If the browser does not support any one of them, there will be no failure. It is clear that in order to create icons that are sensitive to user choice in this way, you need to put one anchor into the other. But to be honest, I wouldn’t like to introduce a special tag.

This sentence has not been implemented, but the rel attribute still exists (see the section “HEAD Element” in Chapter 3).
Jim Davis added:

It would be nice to be able to specify the type of content, for example, like this:



However, I certainly hope to live to the time when the type of content will be strictly determined by the file extension.

This proposal was not implemented either, although later Netscape began to support embedding arbitrary multimedia objects using a tag .

(Jay C. Weber) :
.

(Jay C. Weber) :


Displaying graphics in browsers is my old dream. But is it really necessary to create a personal tag for each type of multimedia information? More recently, everyone was looking forward to the emergence of the MIME-type mechanism. What happened now?

Mark Andressen replied:

This is not an alternative to the upcoming use of MIME types as a standard document handling mechanism. This is a simple implementation of functionality that is needed independently of MIME.

Jay Weber countered:

Forget about MIME types for a while, they distract from the essence. I, in fact, do not agree with your approach to the support of embedded images, because you can expect that next week someone will offer a new tag for sound files. Meanwhile, the use of a single embedding method for all media types would have to be paid with a not so expensive coin.

Experience shows that Jay’s concern was well-founded. True, more than a week has passed, but tags appeared in HTML5