Candidate: http://{fqdn}.ipns.localhost
Test URL: http://docs.ipfs.io.ipns.localhost:8080/ipns/docs.ipfs.io
Result:

• Linux 👎 (Works on a box with unbound, does not resolve on stock Debian)
• Windows: ?
• Mac: ?

There are some occult tricks for browsers on mac and windows; you can do some automagic with this https://en.wikipedia.org/wiki/Proxy_auto-config

I found it via https://github.com/KishanBagaria/frwrd

[..] you can do some automagic with this https://en.wikipedia.org/wiki/Proxy_auto-config

Changing proxy setting globally is not a good idea, however Firefox provides browser.proxy API with a very interesting property:

use the proxy.onRequest event listener to intercept web requests, and return an object that describes whether and how to proxy them.

This would enable us to use PAC-like processing only for IPFS requests.
(Right now we just redirect them)

Linux -1 (Works on a box with unbound, does not resolve on stock Debian)

Seems like that it also depends on myhostname plugin for /etc/nsswtich.conf, which is not installed by default in Debian. With this plugin installed and activated, the test URL actually redirects to http://{local_gateway}/ipns/docs.ipfs.io/ when IPFS integrations and DNSLink support is enabled in IPFS Companion, and just open as is when IPFS integrations disabled in add-on.

From man nss-myhostname:

The hostnames "localhost" and "localhost.localdomain" (as well as any hostname ending in ".localhost" or ".localhost.localdomain") are resolved to the IP addresses 127.0.0.1 and ::1.

I think switching from 127.0.0.1 to ::1 where possible is the best we can do right now, given cross-platform constraints.

Having local gateway at ::1 looks less intimidating:

For now, this can be enabled manually via:

$ ipfs config --json Addresses.Gateway '["/ip4/127.0.0.1/tcp/8080","/ip6/::1/tcp/8080"]'

A proposal to extend default Addresses.Gateway with /ip6/::1/tcp/8080 is at ipfs/kubo#5905

Update: there may be a way to support http://<cidv1b32>.ipfs.localhost on every platform supporting HTTP Proxies – see proposal in ipfs/kubo#5982

Notes on Secure Context and .ipfs.localhost – ipfs/ipfs-companion#667 (comment)

The ".dweb" Special-Use Domain Name: arewedistributedyet/arewedistributedyet#34

Interesting development:
As of 2019-10 localhost (hostname) is a secure context in both Firefox and Chrome.

Caveat: Firefox does not include subdomains (foo.bar.localhost is not a secure context), but I posted our use case in related bug to match behavior from Chrome:
https://bugzilla.mozilla.org/show_bug.cgi?id=1433933#c6

There is also a discussion to skip DNS lookup for *.localhost (https://bugzilla.mozilla.org/show_bug.cgi?id=1220810) and hardcode it to loopback, which would make it work on all platforms, regardless of local DNS setup.

This makes *.localhost nearly ready for use (waiting for Firefox to match Chrome).
I updated the first post in this issue to reflect current status.

Demo

Loaded http://en.wikipedia-on-ipfs.org.ipfs.localhost:8080/ipns/en.wikipedia-on-ipfs.org/wiki/ today and Chrome marks it as secure context:

Firefox 69	Chrome 78
isSecureContext: false	isSecureContext: true

Quick update (in the context of https://github.com/ipfs/go-ipfs/issues/7527):

Since go-ipfs 0.5, when user runs local IPFS node, they can load websites and content via subdomains like this:

http://bafybeiemxf5abjwjbikoz4mc3a3dla6ual3jsgpdr4cjr3oz3evfyavhwq.ipfs.localhost:8080/wiki/
http://bafybeid6grcjmnvsdaeklremt2lcqk7jevbjtwrerzgq46nzxfgn5isrne.ipfs.localhost:8080/images/ipfs-logo.svg

There are two known problems with *.localhost at the moment:

1. If browser vendor does not hardcode localhost to point at loopback, then it is resolved by OS DNS resolver, and on some platforms that can produce error. Fix here is to implement section 6.3.3 from https://tools.ietf.org/html/rfc6761#section-6.3 (Chromium-based browsers already do this)

2. Content at *.localhost should be marked as Secure Context. Right now some vendors such as Firefox handle localhost and *.localhost differently, partially due to legacy code, partially due to my previous point.

Implementing "let localhost be localhost" (6.3.3 from rfc6761) would ensure localhost can resolve on every platform and can be marked as secure context – very likely solving both issues.

Vendors are mostly ok with this change:

• Firefox/Gecko already is tracking this as part of https://bugzilla.mozilla.org/show_bug.cgi?id=1220810.
• Safari/Webkit:
  • https://bugs.webkit.org/show_bug.cgi?id=171934
  • https://bugs.webkit.org/show_bug.cgi?id=160504

Unfortunately the movement on Safari and Firefox fronts to resolve it turned out to be slower than we expected. Looking into ways we can accelerate that.

Good news: Chromium officially locked *.localhost to loopback as per https://tools.ietf.org/html/draft-ietf-dnsop-let-localhost-be-localhost-02 🥳

Details from https://bugs.chromium.org/p/chromium/issues/detail?id=589141#c15:

We addressed this in https://bugs.chromium.org/p/chromium/issues/detail?id=691930 but didn't close this bug. There, we locked *.localhost to loopback as per https://tools.ietf.org/html/draft-ietf-dnsop-let-localhost-be-localhost-02 (see https://source.chromium.org/chromium/chromium/src/+/master:net/dns/host_resolver_manager.cc;drc=25292af6cee762330490f47e79e09a071dc4b5a9;l=3091). This means that we also consider *.localhost secure (see https://source.chromium.org/chromium/chromium/src/+/master:services/network/public/cpp/is_potentially_trustworthy.cc;drc=c70af83bc44f6829277cdc3621e7015d6e0d7530;l=228).

This increases likelihood of other vendors to follow.

https://bugzilla.mozilla.org/show_bug.cgi?id=1220810#c89

merges to mozilla-central - can't trust them until 24hrs old ;)

Some updates and reading for anyone interested in following *.localhost space :-)

The best support can be found in Chromium (no need for HTTP proxy, local DNS resolver is ignored)
Firefox will soon catch up thanks to our partnership with Igalia, we are also reaching out to Webkit to follow.

• Chromium
  • Intent to Implement and Ship: Treat http://localhost as a secure context.
• Firefox
  • Intent to prototype & ship: Treat localhost addresses as "Potentially Trustworthy"
  • "Hardcode localhost to loopback" patch landed last week, sounds like it is here to stay 🥳
    https://bugzilla.mozilla.org/show_bug.cgi?id=1220810 → https://phabricator.services.mozilla.com/D92716
    • some remaining fixes need to land before its 100% hardcoded. Work tracked in:
      https://bugzilla.mozilla.org/show_bug.cgi?id=1673364 → https://phabricator.services.mozilla.com/D94726
  • Tests to ensure localhost and *.localhost can actually not be overridden by non-local IP:
    https://bugzilla.mozilla.org/show_bug.cgi?id=1673315 → https://phabricator.services.mozilla.com/D94712
  • Create a WPT test to verify handling of locahost and *.locahost
    https://bugzilla.mozilla.org/show_bug.cgi?id=1672323
• Webkit (Apple)
  • Localhost subdomains don't work
    https://bugs.webkit.org/show_bug.cgi?id=160504
  • Content from loopback addresses (e.g. 127.0.0.1) should not be considered mixed content
    https://bugs.webkit.org/show_bug.cgi?id=171934

I get this error: I can access it from chrome but not my Golang program:

"http://zzz.ipfs.localhost:8080/1": dial tcp: lookup zzz.ipfs.localhost: no such host

This was resolved in ipfs/kubo#6096

We went with *.ipfs.localhost and *.ipns.localhost, as it works nearly everywhere: thanks to collaboration with Igalia we now have secure context on subdomains (window.isSecureContext) n both Chromium-based browsers (Edge, Chrome, Brave, Opera), and Firefox.

• Webkit/Safari issues are actually a problem with macOS DNS resolver – tracked in localhost subdomains do not work on Safari (macOS) #206
• Some linux distributions may require additional configuration – tracked in gateway subdomains: *.localhost not found kubo#7290