Html we lost

Hi, Habr! I present to you the translation of the article "The HTML we never had" by Sergei Kucherov.

This year marks 30 years since Berners-Lee began developing the HTML language. Since then, we have come a long way, starting with admiration for the new technology, and ending with the treatment of Internet addiction and censorship. What kind of trouble did not bring us the Internet, hacked passwords, identity theft, computer viruses, worms, and now even extortion viruses. Have you ever wondered why the Network is still so unstable and vulnerable? Somewhere on this long journey, we turned the wrong way? Let's figure it out.

HTML 1.0, published in 1993, included a total of 13 elements (counting only those that have survived to the present day):

a, address, base, dd, dir, dl, dt, h1..h6, li, p, plaintext, title, ul 

The most important of them, of course, is “anchor” (a). It is he who defines the functionality that is responsible for the first two letters in the heading of the standard — hypertext. Without anchors (or links), HTML would be just another text markup language. It is this ability to send a user to any document in the world using a universal resource locator (URL), and created this amazing phenomenon called the World Wide Web. Two years later, several more useful elements were added to HTML: html , head , body , and also elements for creating forms, tables, and images.

The last element played probably the most significant role in the history of the Internet. By giving the browser the ability to display not only text, but also pictures, we made the new technology attractive not only for a small group of scientists and enthusiasts, but also for millions of ordinary users. We can safely say that this innovation even prompted the industry to increase the speed of the Internet and its accessibility for the mass user. However, there is another feature of this HTML element that has historical significance. Look here:

 <img src="http://ibm.com/ibm-logo.gif" /> 

Since you cannot embed a binary image in a text file (at least at that time), the img element is provided with an attribute that indicates where the browser can find the desired file. This simple idea was the key to a great invention.

The key that we never turned.

HTML 2.0 was published in November 1995. Everyone was delighted with the new features, and probably that is why no one had an idea to suggest: why don't we allow all other HTML elements to also use this attribute? Imagine this:

 <h1 src="/website/info/title"> </h1> 

This code means that the content of the header must be downloaded from this URL. Maybe it doesn't make sense for such a small element, but what about a div or article ?

 <article src="/parts/article/blog1298" /> 

Now does that make sense? I know that in 1993 the speed of the Internet was not as high as it is now. New features have already taken most of the existing bandwidth, and the HTTP protocol was not up to par. However, there was no reason not to allow this possibility in the standard.

Now you will probably think, and what effect could this attribute have on the future of the WWW? By itself, perhaps not so great. But if we add another opportunity to it, the result could differ dramatically from what we have now. When the browser displays the page, it translates the HTML code into the Document Object Model (DOM) located in memory. This model remains unchanged until the browser receives a request to replace it with another HTML document. Even in 1993, software was not so primitive. That year, when Netscape Navigator replaced the Mosaic browser, the Lotus 123 program was already ten years old, and VisiCalc even more. The idea of ​​calculating the state of a document as a function of data entered by the user was already well known and quite simple to implement. Unfortunately, no one decided to apply it to browsers. Imagine what would have happened if in HTML 2.0 there appeared such an opportunity:

 <div id="name">George</div> <h1>Welcome, $name</h1> 

If you can refer to the contents of other cells in a spreadsheet, then the HTML document might allow the use of variables that refer to the values ​​of other elements. For example, the above code will be displayed as the title Welcome, George . Even more useful variables could bring in the URL:

 <article src="http://server.com/blog/$name"></article> 

The above code will download the contents of the article from the URL http://server.com/blog/George . And if the value of the name element changes, the browser will update the contents of this one element only. Like now, the server is responsible for the logic and HTML code generation. In this case, there is no need to use AJAX and JavaScipt. This new, still not proposed by anyone function, would allow to easily implement a search box with dynamic prompts:

 <input list="find" type="text" id="term" /> <datalist id="find" src="http://server.com/search/$term" /> 

Obviously, it is much safer to evaluate expressions than to execute embedded program code, the consequences of which are difficult to predict. To make HTML even more compatible with spreadsheets, you need to add the ability to use functions:

 @CONCATENATE(first,", ",last); 

No need for javascript, shadow dom and other expensive and extremely insecure features. The browser automatically calculates changes in the DOM based on user input. Today we call it reactive programming. It's a shame that it took us 26 years to figure this out. Is it too late to try to implement it now?

You can assume that the latest versions of HTML5 + CSS3 + JS are enough for modern needs. I do not think so. We are still struggling with creating even a simple user interface, and are forced to use intricate JS libraries, like Angular. What about web components? Can they make web programming faster, easier and safer? Maybe. Or maybe not. All I know is that components are extremely easy to implement on top of the HTML standard that we never had. Let me introduce you to the define element:

 <head> <define tag=“login” src=“http://server.com/components/login”> <define tag=“footer” src=“http://server.com/components/footer”> </head> <body> <login toremember="yes" /> ... <footer /> </body> 

That's all. The resource downloaded to the address specified in the component URL is a regular HTML file. It may contain variables, functions, and links to other components. Such web components can be easily used not only on a single web site, but also as a standard library on the Internet. The HTTP / 2 protocol introduces many useful features that will allow the new HTML to work in full force. JavaScript can be left, but in most cases it will simply not be needed. When was the last time you had to use a macro in a spreadsheet?