Broken links on "Install Docker" page

File: engine/installation/index.md, CC @MistyHacks

The page Install Docker has several broken links. For instance, its link

CentOS

links to:

https://docs.docker.com/engine/installation/linux/centos.md

which yields a 404 error. The correct link would be to:

https://docs.docker.com/engine/installation/linux/centos/

Likewise for the other OSes listed.

[JimGalasyn]

Hi @sampablokuper, thanks for the feedback! You probably don't have JS enabled. There's a JS script that turns the md links into the correct links. Please enable JS and try again.

@JimGalasyn wrote:

Hi @sampablokuper, thanks for the feedback!

Welcome!

You probably don't have JS enabled.

Correct.

There's a JS script that turns the md links into the correct links.

Why not just use the correct links in the first place?

Please enable JS and try again.

No, that would be a bad idea. Instead of asking your website visitors to put themselves at risk so that you can retain completely unnecessary JavaScript, you should get rid of that extraneous JavaScript (or at least not require it for basic functionality like links) and allow your website visitors to keep themselves safe.

[johndmulhausen]

Sorry, but our site requires javascript.

@johndmulhausen, wow, that response sucked :(

@johndmulhausen, I even opened a PR that fixes this issue without requiring JavaScript. AFAICT, you wouldn't even have to do any work except merging the PR.

[johndmulhausen]

Sorry you feel that way @sampablokuper but we aren't going to remove the JavaScript dependency. Everything from search, to navigation, to version selection, the entire glossary section, page redirection, link resolution, autocompletion, and more, all require JavaScript, and that is not going to change. That's a hard fact, and ends the discussion here.

We merged the PR, and we love PRs, and if it fixes the issue for you, that's great. But it was only an issue for people who were using our site in an unsupported way and were there not a PR, we wouldn't have acted. I want to be clear about that if you find future issues with JavaScript and site compatibility.

@johndmulhausen wrote:

Everything from search, to navigation, to version selection, the entire glossary section, page redirection, link resolution, autocompletion, and more, all require JavaScript, and that is not going to change. That's a hard fact, and ends the discussion here.

Wow, that response sucks even more. Here's why:

• Your website is (thankfully) built by a server-side static site generator, not by a client-side framework. As such, it should not impose any demands on the client beyond support for HTTP(S) and HTML.
• The only dynamic item on your list is autocompletion. Requiring JavaScript for that: fair enough, as those who don't use JavaScript can easily live without autocompletion (i.e. such a site would perform graceful degradation aka progressive enhancement).
• Requiring JavaScript for static content is indefensible and, for some people, inaccessible. (You might as well require people to climb greased steps just to enter a building. Sure, most people can probably manage it, but it puts them at risk; and some people won't manage it at all.)
• Speaking as though your decision is beyond reproach is even less excusable. (You might as well say: "Climbing the greased steps is required. If you slip on the greased steps, that's your fault.")

I hope you will reconsider your decision, and also your way of discussing it.

I had been planning to use Docker, but your responses have made me feel that it is not the product of a welcoming and inclusive community, and I will be looking for alternatives.

[johndmulhausen]

I am sorry we have such a philosophical difference of opinion re: JavaScript, but it is the choice we have made. I'm not saying it's above reproach, I am saying that the work required to remove JS as the solution for all of these things is not something we are prioritizing. I don't think being firm about that decision and open about that with you is endemic of a problem with inclusivity, it simply means that we have chosen to use JavaScript.

Our docs are open source, and if you're interested in de-JS-ing some of the solutions we have implemented, you are welcome to. As a feature request that requires labor from us, we are declining that at this time, as the percentage of users who disable JavaScript is, by estimates, 0.2%.

@johndmulhausen wrote:

I am sorry we have such a philosophical difference of opinion re: JavaScript, but it is the choice we have made. ... I don't think being firm about that decision and open about that with you is endemic of a problem with inclusivity, it simply means that we have chosen to use JavaScript. ... As a feature request that requires labor from us, we are declining that at this time.

This part of your reply is disappointing, again, for the reasons already explained in my earlier comments. All the more so given that every bug report I have filed to your project has been accompanied by a patch: clearly, I am not asking you to remedy the situation all by yourself, nor to do it all in one go.

Also, the issues are practical rather than "philosophical". They have a concrete impact on usability and security.

I'm not saying it's above reproach, I am saying that the work required to remove JS as the solution for all of these things is not something we are prioritizing. ... Our docs are open source, and if you're interested in de-JS-ing some of the solutions we have implemented, you are welcome to.

This part, however, is much more reasonable. Thank you for this part.

If this (rather than your earlier comments) is indicative of your likely future responses, then I will continue to consider Docker for personal or professional projects.