CNC. The obvious is the incredible
I think no one needs to tell what a CNC is. On the Internet, there are enough evangelical fetishists who advocate human comprehension in urlahs.
If you wish, you can familiarize yourself with the basic idea , for example, on Wikipedia.
I will try to clarify and somewhat rethink this idea.
')
What is a file extension? This is, roughly speaking, a short alias to the mime type of this file. For example, if the file has a gif extension, then we expect the contents of the file to be image / gif, if html is text / html, js is text / javascript, etc.
And usually the result corresponds to the expectation. But there are exceptions:
vkontakte.ru/newsfeed.php
ru.msn.com/iat/us_ru.aspx
www.opennet.ru/cgi-bin/opennet/man.cgi
What do we see in the request? php, aspx and cgi. And what do we get in response? Correct, text / html.
Why so? It is clear why. On the server it is really php, aspx and cgi. html it only looks “outside”. Nothing, of course, prevents you from showing these files outside with a different, correct extension. But this is not usually done. Because it is believed that this is not a problem - the user doesn’t care (at least we are used to thinking that way), but for the developer and the admin it’s easier.
Whether this issue is considered a worthy solution is an open question. But at least we can say that
Extensions to html files on the web usually do not just do not carry any useful information to the user, but are directly misleading.
What is a folder? It is, if simply, a way to group files. What is a folder in the context of the site? The answer is not as obvious as it may seem at first glance.
Yes, from the web server side it is still a way to group files. But is this for the user? No not like this. And that's why.
Let me say (relying mainly on personal experience with non-geek users) that the user does not perceive the site as part of the file system, as a collection of disparate files and folders. A site for a user is a collection of linked pages. Yes, of course, the page continues to be a file. In the context of HTTP, the html file is unremarkable; it is exactly the same file as png or js. And HTTP does not know anything about any pages.
For a user who knows nothing about TCP / IP, HTTP and HTML, the difference is huge. A page is a kind of magic substance, with pictures, buttons, references. A file is just a file. It can be downloaded, put next to other files and it will not differ from them. There, too, of course, has its own magic, but it has no relation to the Internet (read, the web). The page exists only while the browser is open. Yes, it can also be downloaded, but then all the special magic of the Internet will disappear - the links will no longer click, the buttons will be pressed and look, it will most likely be completely different from the one on the Internet. In general, this will be a dead page.
So the page is not a file. A page is a page.
But if the file is no longer a file, then what is a folder? There are no files, and there are folders? In the same folder, you can look and see the files there. And here it is impossible. And if you try, you will see not its contents, but another page. So what is this folder? And this is not a folder. This is the page.
That is, for the user there is no difference between the request to the file and the request to the folder, if as a result he sees the page.
And if there is no difference, then why distinguish them? No need to distinguish them, you must abandon extensions, and requests with a slash at the end and without it to make each other synonymous.
/news.php - not clear (besides, not true, because the answer is not php, but html)
/ news - much better
/ news / - that's good too
The last option is used by Google, Habr and Lebedev Studio. What kind of hints :)
A page is not a file or a folder, a page is a page.
Request parameters are the main enemy of human clarity. Actually, the CNC is designed, first of all, to save the user from the parameters in URLs. Whenever possible
Here I have nothing special to add. Yes, ugly. Yes, unreadable. Yes, we must get rid of.
But, unfortunately, this is not always possible. I would like to completely abandon them, but it will not work. In complex grids, for example, without parameters in any way.
/catalogue.php?sect=11&kind=6 - Ugly
/ catalog / 11/16 / - a little better (example from Wikipedia)
/ catalog / light / bulbs / - already not bad (this example is now also on Wikipedia)
Parameters - the main enemy of human clarity.
There is one more important point, which, for some reason, is usually omitted, arguing about CNC, is the language of urla. Natural language (usually English).
Take the example of the (almost) perfect implementation of CNC, the site of the Art. Lebedev Studio (by the way, I only found out when writing this article that they refused to have extensions for html files, they were recently, moreover, not some php or py, but honest html):
www.artlebedev.ru/everything/optimus
Wonderful url. But, nevertheless, something is wrong in it, do not you find it? Something barely cuts the eye. What?
But parts of the address do not quite correspond to the names of sections / pages. The section "Our All" is represented in the url with the word everything, and the page about the Optimus keyboard - with the word optimus.
Site language is exclusively Russian. That is, to use the site, I must own Russian and only Russian. Urly, meanwhile, all English. That is, in order to use the site it is enough for me to know Russian, and in order to use the facilities of the CNC, I also need English. Moreover, I need it only for this, not for anything more.
Weird exception, you do not find?
All titles are duplicated in a foreign language, in relation to the site content. For what purpose? It's comfortable. Not. Obviously? Not.
Why not write / all / optimus /? Or even / all / Optimus /.
So does Wikipedia, as well as all the projects of the Wikimedia Foundation and some other services based on Mediawiki.
Yes, Cyrillic in urlah has obvious problems. Problems with sending such links by mail or instant messengers. Problems with quoting such links in blogs and forums. Yes, there are problems, but they are few and it seems that this is not a very high price for beautiful, clear, obvious URLs that help in navigation?
Ps. I deliberately omitted all the nuances of implementing such URLs in order to focus on theory. Implementation, if desired, can be discussed as a separate topic. There is a desire? :)
Pps. Tell me where it is better to shift the topic, I did not invent anything better than Web standards.
If you wish, you can familiarize yourself with the basic idea , for example, on Wikipedia.
I will try to clarify and somewhat rethink this idea.
')
Extensions
What is a file extension? This is, roughly speaking, a short alias to the mime type of this file. For example, if the file has a gif extension, then we expect the contents of the file to be image / gif, if html is text / html, js is text / javascript, etc.
And usually the result corresponds to the expectation. But there are exceptions:
vkontakte.ru/newsfeed.php
ru.msn.com/iat/us_ru.aspx
www.opennet.ru/cgi-bin/opennet/man.cgi
What do we see in the request? php, aspx and cgi. And what do we get in response? Correct, text / html.
Why so? It is clear why. On the server it is really php, aspx and cgi. html it only looks “outside”. Nothing, of course, prevents you from showing these files outside with a different, correct extension. But this is not usually done. Because it is believed that this is not a problem - the user doesn’t care (at least we are used to thinking that way), but for the developer and the admin it’s easier.
Whether this issue is considered a worthy solution is an open question. But at least we can say that
Extensions to html files on the web usually do not just do not carry any useful information to the user, but are directly misleading.
Folders, files and pages
What is a folder? It is, if simply, a way to group files. What is a folder in the context of the site? The answer is not as obvious as it may seem at first glance.
Yes, from the web server side it is still a way to group files. But is this for the user? No not like this. And that's why.
Let me say (relying mainly on personal experience with non-geek users) that the user does not perceive the site as part of the file system, as a collection of disparate files and folders. A site for a user is a collection of linked pages. Yes, of course, the page continues to be a file. In the context of HTTP, the html file is unremarkable; it is exactly the same file as png or js. And HTTP does not know anything about any pages.
For a user who knows nothing about TCP / IP, HTTP and HTML, the difference is huge. A page is a kind of magic substance, with pictures, buttons, references. A file is just a file. It can be downloaded, put next to other files and it will not differ from them. There, too, of course, has its own magic, but it has no relation to the Internet (read, the web). The page exists only while the browser is open. Yes, it can also be downloaded, but then all the special magic of the Internet will disappear - the links will no longer click, the buttons will be pressed and look, it will most likely be completely different from the one on the Internet. In general, this will be a dead page.
So the page is not a file. A page is a page.
But if the file is no longer a file, then what is a folder? There are no files, and there are folders? In the same folder, you can look and see the files there. And here it is impossible. And if you try, you will see not its contents, but another page. So what is this folder? And this is not a folder. This is the page.
That is, for the user there is no difference between the request to the file and the request to the folder, if as a result he sees the page.
And if there is no difference, then why distinguish them? No need to distinguish them, you must abandon extensions, and requests with a slash at the end and without it to make each other synonymous.
/news.php - not clear (besides, not true, because the answer is not php, but html)
/ news - much better
/ news / - that's good too
The last option is used by Google, Habr and Lebedev Studio. What kind of hints :)
A page is not a file or a folder, a page is a page.
Options
Request parameters are the main enemy of human clarity. Actually, the CNC is designed, first of all, to save the user from the parameters in URLs. Whenever possible
Here I have nothing special to add. Yes, ugly. Yes, unreadable. Yes, we must get rid of.
But, unfortunately, this is not always possible. I would like to completely abandon them, but it will not work. In complex grids, for example, without parameters in any way.
/catalogue.php?sect=11&kind=6 - Ugly
/ catalog / 11/16 / - a little better (example from Wikipedia)
/ catalog / light / bulbs / - already not bad (this example is now also on Wikipedia)
Parameters - the main enemy of human clarity.
Tongue
There is one more important point, which, for some reason, is usually omitted, arguing about CNC, is the language of urla. Natural language (usually English).
Take the example of the (almost) perfect implementation of CNC, the site of the Art. Lebedev Studio (by the way, I only found out when writing this article that they refused to have extensions for html files, they were recently, moreover, not some php or py, but honest html):
www.artlebedev.ru/everything/optimus
Wonderful url. But, nevertheless, something is wrong in it, do not you find it? Something barely cuts the eye. What?
But parts of the address do not quite correspond to the names of sections / pages. The section "Our All" is represented in the url with the word everything, and the page about the Optimus keyboard - with the word optimus.
Site language is exclusively Russian. That is, to use the site, I must own Russian and only Russian. Urly, meanwhile, all English. That is, in order to use the site it is enough for me to know Russian, and in order to use the facilities of the CNC, I also need English. Moreover, I need it only for this, not for anything more.
Weird exception, you do not find?
All titles are duplicated in a foreign language, in relation to the site content. For what purpose? It's comfortable. Not. Obviously? Not.
Why not write / all / optimus /? Or even / all / Optimus /.
So does Wikipedia, as well as all the projects of the Wikimedia Foundation and some other services based on Mediawiki.
Yes, Cyrillic in urlah has obvious problems. Problems with sending such links by mail or instant messengers. Problems with quoting such links in blogs and forums. Yes, there are problems, but they are few and it seems that this is not a very high price for beautiful, clear, obvious URLs that help in navigation?
Ps. I deliberately omitted all the nuances of implementing such URLs in order to focus on theory. Implementation, if desired, can be discussed as a separate topic. There is a desire? :)
Pps. Tell me where it is better to shift the topic, I did not invent anything better than Web standards.
Source: https://habr.com/ru/post/86154/
All Articles