HTML5 for web designers. Part 2: The HTML5 Model

HTML5 for web designers

1. Brief history of markup language
2. HTML5 model
3. Multimedia
4. Forms 2.0
5. Semantics
6. HTML5 and modern conditions

The Great French Revolution was a time of radical political and social transformation. They also touched upon time as such: at a certain period of their existence, the French Republic lived according to a new system - there were 10 hours, one hundred minutes each, per day. Obviously, she was much more logical and “more correct” than the usual sixties.

However, she was a complete failure. No one used it.

The same can be said about XHTML 2. W3C only once again proved what the lesson of post-revolutionary France taught us: to change people's habits on the orders is very, very difficult.
')

Principles of the model

With the goal of avoiding the mistakes of the past, the WHATWG primarily identified a set of principles that should follow the process of working on HTML5. One of the key: "Maintain what already exists." This is another reason why for HTML5 there is no clear date of entry into action.

While XHTML 2 intended to score on everything that came before it, and start a new way, HTML5 is an add-on for existing specifications. Much of HTML 4.01 is preserved and maintained.

Some of the other principles are: “Do not reinvent the wheel” and “Pave the lightly trodden paths”. The latter means that if there is some widespread and popular way for web designers to solve a particular problem or problem — even if it’s not the best — it should be taken into account and added to the specification. You can also say: "Do not repair what is not broken."

Many of these principles may be familiar to you if you have previously dealt with microformats . In the HTML5 environment, the same pragmatic approach is adopted without too much exalting the theory.

This philosophy is formulated in principle about the “Order of the importance of the components,” which says: “In resolving any conflict, you need to think first of all about users, then about coders, then about implementers, then about the authors of specifications, then about theoretical purity and correctness "".

Ian Hickson many times drew attention to the fact that browser developers ("implementers") can greatly influence what goes into HTML5, and what does not. If a browser refuses to include support for a specific feature, it makes no sense to add it to the specification, otherwise it will simply not be related to reality. In this regard, according to the order of importance of the components , we, web designers, have even more influence. If we consider part of the specification unnecessary or incorrect and will not use it, it will also cease to be related to reality and will require revision.

Without extremes

Developing HTML5 involves constant internal tension and contradiction. On the one hand, the specification must be sufficiently functional and powerful to become a reliable platform for creating web applications. On the other hand, HTML5 should be able to maintain the already existing content of the network, even if there is a complete mess in the code there by the current. If the specification deviates too much in one direction, the fate of XHTML2 awaits it. If to another, the <font> tag and the tables as a means of marking will again become the cornerstone, because with their help, in the end, a huge number of existing web pages have been built.

Because it is so important to adhere to a clear and balanced balance of things that requires a pragmatic and cold-blooded approach.

Error processing

The HTML5 specification does not just tell browsers how to display the standards-compliant layout — for the first time in the history of this language, it also defines the ways in which they should work with a bad layout.

So far, the browser developers themselves have decided how they will handle the errors. In most cases, they simply followed the path followed by the most popular browser, which is largely a waste of time. Instead of adding support for new features, they copied their competitors' approaches to processing incorrect code.

The decision to introduce standards for this procedure in HTML5 is very ambitious. Even if the set of tags and attributes in this version was no different from the fact that in HTML 4.01, the development of a single set of error handling rules by the 2012th year would have been like Sisyphean work.

These rules, however, will be of little interest to web designers (after all, we all write valid, well-structured code, right?), But they are extremely important for browser developers. While all past specifications were written only for coders, HTML5 is written for coders and implementers. Keep this in mind if you decide to familiarize yourself with it directly - this explains why it is so dimensionlessly large and includes so many details and nuances that it is more like the notes of some trainspotter who is interested in recounting the contents of the personal collection of brands during a simultaneous game in chess with three opponents.

Spit it out, Doc (tayp)

A doctype (doctype, Document Type Declaration) is the traditional way to specify the type of markup language that is used on this page.

This is what the doctype for HTML 4.01 looks like:

 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3c.org/TR/html4/strict.dtd"> 

So for XHTML 1.0:

 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict //EN" "http://www.w3c.org/TR/xthml1/DTD/xhtml1-strict.dtd"> 

It is completely unreadable for a person, but, whatever one may say, such a way is simply to say “This page is written in HTML 4.01” or “This page is written in XHTML 1.0” in its own way.

We can assume that for HTML5 there should be something like that with the number five stuck somewhere. Oddly enough, no:

 <!DOCTYPE html> 

Finally it will be possible to learn by heart.

But, damn, how is that? There is no version number indicated, so how do we denote subsequent HTML incarnations? When I first saw this new kind of doctype, I thought, “What the hell, they really want to say that this is the final version of the markup language, after which nothing will ever be necessary?”

In fact, the idea is simple and very pragmatic. The goal of HTML5 is to support existing HTML 4.01 and XHTML 1.0 pages, and this doctype will suffice. New versions of HTML, in turn, will have to support HTML5, which is why it is completely meaningless to include the serial number in it constantly.

In general, the doctypes themselves are not so important. Let's say you wrote a page with a doctype from HTML 4.01, and then you took and added elements from another specification - let it be HTML 3.2, let HTML5, not the essence. The browser still does not go anywhere and will process them as best they can. Browsers support elements and features, not doctypes.

The latter were designed primarily for validators, not for browsers. The only case when they pay attention to the doctype is when you need to decide which rendering method to use - internal individual or consistent with the standards.

So the only purpose of the doctype for HTML5 is to make sure that the browser will process the code following it, following the standard. But for validation, its presence or absence does not matter.

There is no need to complicate

HTML5 has simplified not only the doctype.

If you want to mark the encoding for your page, the best way to do this is to make sure that the server gives the correct value to the Content-Type. To be completely sure, you can use the <meta> tag. So it was before:

 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> 

So this is in HTML5:

 <meta charset="UTF-8"> 

As in the case with the doctype, there is nothing superfluous here - just what will be enough for the browser to understand what it is about.

The <script> tag can also be allowed to lose weight. Often, the type parameter is added to it with the value text / javascript :

 <script type="text/javascript" src="file.js"></script> 

Browsers do not need it. They already understand that the code is written in JavaScript - the most popular scripting language on the web (yes, to hide: the only scripting language):

 <script src="file.js"></script> 

Similarly, there is no point in the type parameter with a text / css value when you attach a style sheet. You can simply write:

 <link rel="stylesheet" href="file.css"> 

Syntax: do as you used to

Some programming languages, such as Python, are very demanding on the design of the code: even the use of spaces in certain situations is necessary to comply with the rules. Other languages, say JavaScript, do not pay attention to formatting - the same beating of the beginning of a line with spaces will not affect the code in any way.

If you want to kindle a fierce holivar and thus organize a fun evening program for yourself, fill the room with programmers and say the words “are spaces in the code”. Do not forget popcorn.

This question lies at the root of a deep philosophical dilemma: should the language be forced to follow a certain style of code design, or can the coders themselves be allowed to decide how they write it?

In the markup for web pages, spaces and indents are not significant. You can add each new element from a new line, do tabbing, insert empty lines - browsers and validators do not care. However, many other liberties are not allowed everywhere.

Before XHTML 1.0, it didn’t matter if you wrote the names of tags in upper or lower case. It didn’t matter whether the quotes were parameter values ​​or not. For many elements it didn’t even matter whether you added a closing tag or not.

XHTML 1.0 follows XML syntax: tags are always lowercase, parameter values ​​are only in quotes, all container elements are necessarily closed. And singles too - there should be a slash before the closing bracket (<br> → <br />).

In HTML5, you decide for yourself: upper case is lower case, quotes are without quotes, closed or not. As you like best.

I have been using the XHTML 1.0 doctype for many years, and I like the fact that it requires you to follow clear rules to get an organized and valid code. Now, using HTML5, I can continue to do as I want and used to.

I understand why many people do not like this frivolity of HTML5. Some people think that it throws us back in the times of the bad practices of the sloppy code, and moreover, they think that HTML5 encourages this style of markup. I do not think so, but I see a cause for concern. It is as if a programming language with syntactically important spaces between lines suddenly became less demanding.

Personally, I calmly relate to such freedom of choice in HTML5, as I have already got used to follow the style of the code I am writing on my own. It would be great, however, to have for this language such a tool, which in the programming world is called “lint-tool”, a program that analyzes markup and indicates common and potentially “dangerous” code design practices, as well as inconsistencies in the style of writing it. . This is somewhat different from the validator, which the code will check, starting only from the doctype. The first who will be able to develop a service that combines both, will definitely deserve the honor and respect of the global community of web designers.

We don't say that here.

In previous versions of HTML, as soon as a certain element or parameter was excluded from the specification, it went through a “withdrawal” process. Web designers were advised to stop using the seized items, not to send them postcards on the websites and not to mention them at all in a decent company.

In HTML5, there are no elements or parameters that have been removed , only obsolete instead.

No, this is not a politically correct version of the name for the same concept - there is an important difference between a withdrawn and an obsolete one in this case.

Since HTML5 has set itself the task of being backward compatible with previous versions, the specification must recognize previously used elements, even if HTML5 no longer includes them. This leads to a somewhat ambiguous situation, when the specification simultaneously says “coders, do not use these elements” and “browsers, here’s how these elements need to be rendered ...”. If any item were removed , it would not be mentioned in the specification at all. But since it is simply deprecated , it is included for browsers.

If you just do not develop your own browser, for you there is no difference between the withdrawn and obsolete elements - you just do not use them and do not invite to visit.

But if you still persist in applying them, your page in terms of standards compliance will be inconsistent . Browsers will display it without problems, but knowledgeable people will not approve this practice.

Separation will be without sorrow

Recognized as obsolete tags: frame , frameset and noframes . They will not be missed.

The acronym tag is obsolete , which will finally put an end to the holivar and controversies that have lasted for years. Do not mourn him, just use the abbr tag instead. And yes, I know the difference between abbreviation and acronym: acronyms are abbreviations that are spelled out as a word, and not by letter (for example, NATO). Not every abbreviation is an acronym, but every acronym is an abbreviation, so one tag is enough.

The font , big, and center elements are also outdated, and, in fact, it happened a long time ago - even with the advent of CSS, where similar effects can be assigned faster and easier. For the same reasons, there are no more bgcolor , cellspasing , cellpadding and valign parameters with us. Use CSS instead.

Not all, however, of the design elements were written into obsolete. Some were sent to retraining courses and got a second chance.

Substitution of concepts

The big element is obsolete, but small is not. Such inconsistency is justified by the fact that the value of the latter has been revised. It is no longer a physical “make the text smaller”, but a semantic “small print”. Well, you understand - the terms of use, footnotes for "stars" and so on.

It is clear that in 9 cases out of 10 this “small print” will be really small; the point is that the role of the element is now more semantic than the design.

Element b used to mean simply “bold text”. Now it is “a text that is stylistically distinguished from the mainstream, but does not carry additional semantic significance.” When semantic significance is still present, it is more likely that strong will do.

Also, the element i now does not mean "italic". This is “spoken by another intonation or with a different mood.” Again, without much meaning or emphasis. To emphasize significance, use the em element.

These changes may sound like just a play on words. And there is. But behind this there is a specific task - to ensure the independence of HTML5 from the devices on which it is processed. When you say “bold” or “italics,” these concepts only make sense visually — when text is displayed on screen or paper. But it is also necessary to think about devices that display information in a non-visual format, for example, intended to be read from the screen to help blind people. Plus, the described changes in the definitions encourage us to better understand and apply the rules of semantics, and not just visual design.

... end of quotation

The value of the cite element was also slightly changed. If earlier it meant “link to source”, now it is “source header”. Very often, when quoting a source, there will be just the title of a book, a film or anything that we refer to. However, it can also be the name of a person. In HTML5, however, using personal names inside the cite element is contrary to the specification.

This is explained as follows: browsers make the contents of the <cite> tag italic. Work titles are usually in italics. Names of people are not italicized. Therefore, the cite element should not be used to refer to a specific person.

In my opinion, this is simply wrong. I understand that HTML5 should pay attention to the features of the browsers, but in this case it is like a horse driving a jockey.

Fortunately, no validator will be able to determine what is inside the <cite> tag , so nothing prevents web designers from being guided by common sense here and putting there what is considered necessary.

<a> on steroids

While all previous rethinking of the meaning of elements is based solely on the substitution of concepts and the play on words, there is one element that has received really noticeable changes.

Without a doubt, the a element is the most important in all HTML. It is he who turns the text into hypertext and makes possible the existence of a world wide web as such.

Before that, it was always just a string element. That is, if you want to link the heading and the next paragraph with the text at the same time, you will have to use a twice.

 <h2> <a href="/about"> About Me </a> </ h2>
 <p> <a href="/about"> Find Out What I Live </a> </ p>

In HTML5, these multiple elements can be wrapped into one <a> tag:

 <a href="/about">
	 <h2> About Me </ h2>
	 <p> Find out what I live </ p>
 </a>

The only restriction: you can not push inside <a> another one <a> .

In fact, of course, this could have been done before, and browsers supported this practice, but until recently it was not legalized. If you think about it, it looks, however, somewhat strange - it is not browsers that implement the capabilities of the new specification, but the specification documents the capabilities of the browsers.

New toys: API for JavaScript

If you need style documentation, you go and read the specification for CSS. If you need markup documentation, you take the HTML specification. But where to go if you need to learn about js js api such as document.write , innerHTML and window.history ? The JavaScript specification is dedicated to programming, you will not find any of the browser APIs there.

So far, browsers have developed their own JS APIs, sometimes looking over their shoulders to see how competitors are doing there. HTML5 will finally document these APIs and set a common standard.

It may seem strange that the specification of the markup language will include documentation on JavaScript, but do not forget that HTML5 started with the project Web Apps 1.0, and JS is an integral component of web applications.

Entire sections of the specification are devoted to the new API, designed to develop these. UndoManager allows you to monitor the sequence of changes in the document. There is a section affecting working with web applications offline, using cache manifest . Drag-n-Drop is also described in detail.

As always, if there are already existing implementations somewhere, the specification relies on them rather than reinventing the bicycle. For example, the API for drag-n-drop in Internet Explorer has existed for a long time and served as the basis for what is included in HTML5. It is worth noting, however, that the Microsoft APIs, to put it mildly, are quite problematic, and sometimes reinventing a bicycle can be justified, especially if all you have is a bicycle with square wheels, no saddle and half a steering wheel.

HTML5 APIs are very powerful things that open up great possibilities. But they are not my path, I would prefer to leave this topic for more advanced developers who will tell about it better than me. In addition, it is worthy of a separate book.

In the meantime, we have lots of exciting things in HTML5 itself. And the excitement about them begins with the next chapter.