is bad.

The <base> , with which the browser is given a base path for resolving relative links, is harmful and should not be used in a good layout. Instead, there is a fairly strict and flexible method for specifying the paths to resources.
Due to the spreading mode on CNC, web technologists began to encounter the following problem more often - files (for example, CSS or images), located on the server literally in the next folder with layout templates, now cannot be addressed by relative paths. When automatically creating pages on very extensive sites, there is practically no way to automatically change the relative paths to resources depending on the address of the page being viewed, and the usual relative paths stop working.

What is he talking about?

Browser browsing address example.com/blog/record1 example.com/blog/record1 , will try to resolve the ../css/blog.css link to example.com/blog/css/blog.css example.com/blog/css/blog.css . Perhaps this is not so bad, but in a situation where the address will be something like example.com/blog/tags/test example.com/blog/tags/test , the same link resolves to example.com/blog/tags/css/blog.css example.com/blog/tags/css/blog.css . Obviously, although the presence of the same file at several URLs can be realized, this is clearly not worth doing. Even if the css folder is in the same place as the layout templates, the problem of relative addressing will not go anywhere.

As in such cases usually come

Web programmers and technologists around the world remembered in this difficult situation about the tag <base> . According to specification:

The BASE element allows authors to explicitly specify the base URI of the document.
If the BASE element is specified, it must be present in the HEAD section of the HTML document, before elements refer to external resources. The path information specified in the BASE element affects only the URI in the document that contains this element.

The solution seems ingeniously simple: by specifying base href="http://example.com/templates/" in the element, we will force the browser to resolve all the above relative URLs into links to actually existing files lying on the same place. Having got rid of the habit of traveling up the directory tree in our relative path, we will get rid of these problems completely.

What's wrong?

Here is just a brief list of problems that arise when using <base> for such purposes:

1. The site stops working from the rest of the domains - even if you try to browse www.example.com www.example.com browser will try to pull resources with example.com example.com ( without www ). For CSS and images this is not so scary, but with scripts (especially HTC for Internet Explorer), cookies, ActiveX, Flash (if it means interaction with the server), and also if the user accesses the https protocol, the user will have more or less serious Problems. Consider also the difficulties when transferring a site to another domain (or using its engine for another site).
2. <Base> also affects the relative addresses used in the links, which are now also resolved according to the base path. Even if you specify base href=" example.com example.com /" , there is a collision between domains, indicated in the first problem.
3. The problem of the psychological plan: the base path specified in projects with large branching, modular structure of templates or simply a large amount of code can confuse a “fresh” layout designer, unfamiliar with the project, but having the task to insert a couple of pictures on the page.
4. The most amazing problem: everybody's favorite IE browser, if there is a <base> and markup elements with the specified float CSS property (for example, <div style="float: left;"> !</div> ), in the document you are viewing, will allow the mouse to select text in such elements. What connection can be here is not clear, but true.
5. The same IE, when resolving paths used in CSS filters (for example, AlphaImageLoader), ignores the indication of the base path and tries to resolve relative links, as if there was no <base> . You will not notice this if you specify the site root as the base path, but with any other folder used in this quality, the standard "medicine" for PNG stops working.

So, we have in the end: as the base path it is better to use the root of the server, but this will create some problems in IE and serious problems for the work of the site with several domains. Having solved the problem with relative paths, we created a few more.
It seems to me that due to the above difficulties, it is better to refuse the <base> tag altogether. And to solve the main stated problem, use other methods of working with relative links.

“Semi-Absolute” Addressing

The fact is that if we just address resources from the server root, starting the path with the / character (“slash”), then we can do without <base> , while allowing the site to work from any domain and have some other benefits. I call this addressing, as opposed to the commonly used reference one, “semi-absolute” (because the protocol and domain are not specified, in contrast to the present absolute addressing).
That is, the CSS file specified in the problem example should be addressed as /templates/css/blog.css . Such a link will work with any domain (as well as a protocol and port), since the default browser will use the directory of the document being called as the base directory (that is, for example, example.com/blog/record1 example.com/blog/record1 - for the browser, this path looks like the directory from which it views the index document). Relative links starting with a slash will be preceded by the browser used by the protocol and all other parts of the URL, ending with the current domain (and the port, if specified). Thus, the problem of addressing resources is solved without unnecessary problems with domains.
At the same time, I call for a meticulous sequence: everywhere, including the url() constructs and filters in CSS and hyperlinks between documents, this notation should be used if it is about working within the same domain. This will allow some freedom in handling files (for example, share the CSS file in the images folder, or move it to a separate one), while maintaining strict code order and efficiency. Unfortunately, many IDEs used in web development do not have the appropriate settings for addressing resources, indulge too much relative addressing (especially with directory tree climbing), and even perceive existing files, but those indicated by the “semi-absolute” method, as non-existent resources. You should not depend on your tools, it is better to think with your head.
However, even with “semi-absolute” addressing, it is not without problems (and what did you think). In my practice, the problem arose with Flash - according to the statement of work, she did not just play a movie, but from time to time she contacted the server for some kind of flash business for a single file. The flash drive file should have been loaded from the “current directory”, addressing it as file.txt . Since the CNC engine was used, each page had its own catalog, and therefore, the flash drive did not work.
That time I solved the problem by asking the Flash technologist to address this file as /flash/file.txt . This resolved the problem on the server, however it ruined the life of the Flash technologist himself (when working in the local file system, such addressing is allowed in a way like C:/flash/file.txt ). Of course, there is a better solution.

We specify Flash its place

When implementing a Flash movie that needs to communicate with its server via http (for example, reading files through the web), you can specify the base directory specifically for each video being deployed without using <base> . To do this, you need to specify the base parameter in the flash insertion code with a value equal to the address of the desired directory in a “semi-absolute” form. That is, in my case, the implementation code of the flash drive looked like this:

<object …>
<param name="base" value="/flash/">
…
<embed base="/flash/" src="/flash/01.swf" …>
…
special thanks to the authors of Habrakhabr for the “convenient" means of publishing the code

In fact, I still set the base directory, but I did it only for one Flash-movie, without specifying the protocol and domain name (they will be substituted in the same way as when resolving "semi-absolute" links). For the next video, you can specify a different directory, or, if you are satisfied with working with the root directory of server webspace, you can simply specify “ / ”. The flash technologist can now always be sure of the position of the flash drive in the web server space and indicate the paths to the resources in a convenient way (not necessarily as “semi-absolute”).

PS

If someone else is not very clear, I urge to use such a method exclusively within the framework of my authority and on the basis of my own practice. That is why I published the topic in my personal blog, and not in the relevant collective ones.

If you do not trust me, or for some reason you have your own opinion on this, I suggest not to plant unnecessary discussions, but to express your opinion in your personal blog. Here, only my own IMHO is recorded, why <base> is harmful, and what to do in its absence.