Ask HN: What feature would you want the web to “force” next, after HTTPS?

I settled on hiding the fixed headers and other objects upon scroll down. (They can be brought back by scrolling up.) https://iwalton.com/wiki/#NoFixed

It would be nice if there was browser support, maybe something like tricking the page into thinking the viewport is as long as the page itself.

There's a tremendous amount of complexity and cost attached to the fact that browsers look up the IP address of the hostname and then connect to port 80.

First, it's true that you can specify another port in the URL, but nobody does that because it's ugly and hard to remember. If you want to be able to send people to your website, you need to be able to tell people what the url is - "Just go to example.com". The minute you start saying "example.com colon, eight zero eight zero" you're screwed. With a SRV record in DNS, example.com could map to an arbitrary IP address and port, which would give us much more flexibility in deploying web sites.

If you want a bare http://example.com to work, you need to create an apex record for the domain. That can't be a CNAME that maps to another hostname, it has to be an A record that maps to an IP address. This means you can't put multiple websites on a single server with a single IP address, you have to have an IP address for each site. IPv4 addresses are already scarce, this just makes it worse.

Also, port 80 is a privileged port in unix (which does the lion's share of web hosting). That means you have to run web servers as root. That, in turn, defeats the unix security model, and requires hosting providers to either lock down their servers and give limited access to users (cPanel anyone?) or give customers root access to virtualized operating systems, which imposes a tremendous amount of overhead.

Virtual operating systems also impose a bunch of complexity at the networking level, with a pool of IP addresses get dynamically assigned to VMs as they come and go, DNS changes (with all the TTL issues that go along with that), switch configuration etc.

These problems are all solvable and indeed solved, by really clever modern technology. The point is that it's all unnecessary. If browsers did SRV lookups, we could still be hosting like it's 1999, and putting all the tremendous progress we've made in the last 20 years into making it cheaper, faster, easier and more secure to build and run a web site. People that support the "open web" as opposed to "just make a Facebook page" should advocate for SRV support in HTTP.

This doesn't actually have to be "forced" on users of the web - it'd have to be forced on browser implementors, hosting providers and web site operators. If the transition was handled well, users wouldn't even notice.

The thing is, if it is a massive pain for average users, then that is an own-goal. Look at SSH: there is no certification chain there. All you do is generate a keypair and then (here's the awkward bit) magic the pubkey over to the server.

It would be easy enough for a website to make pubkey installation a seamless part of the sign-on workflow.

Compare C++ standardization. Most people are using two year old compilers. While the newest compilers do implement draft features, these features are almost all standardized in the next ~3 years. The standards are clearly versioned and you can put newer compilers into modes to check against older standards if your code needs to compiler on multiple compilers. Features are never removed.

By contrast, on the web, everybody is running brand spanking new browsers. Experimental technologies are sometimes implemented before full draft standards are even written. Many or most drafts that are written never become standards. If they do become standards, it's often a decade or more away. Alternatively the living standards of what browsers actually support aren't versioned. It's not possible to put a browser into JavaScript 99 mode - the easiest way to check your code for conformance is to automate your test cases across a variety of browsers. And, features are sometimes removed because they are deemed security or privacy concerns, so conforming to an old standard is not sufficient to ensure proper functionality under modern browsers.