[hn_throwaway_99]

> I'd expect the zoom to be associated with the site.

That's what the GP comment said happened: the zoom level was the one associated with what they previously had set on HN, and they expected it to be the opposite, the default zoom level for the browser.

[taeric]

But the site didn't load. My browser's not loading page did.

Is easier to see as broken by thinking of "how could I set it so that my browser's error page has a default zoom?"

[derefr]

But your browser's connection-failure page is considered to come from the HTTP Origin of the site. It's like when browsers receive a specific HTTP status-code (e.g. 500) with no body, so they render a default HTML error document.

In both cases, those are the browser supplying a resource representation, while still technically being on the resource specified in the navigation bar. The thing you're seeing is an overridden representation of the server's response. (Which, in this case, just happened to be "no response.")

It's almost exactly the same as how the server sending a 304 gets the browser to load the document from cache. The server's actual response was a 304; but the browser's representation of that response is the cached HTML DOM it had laying around from the last 2xx resource-representation it received "about" the same resource.

[taeric]

I mean, I get the argument. But it falls easily, from my pov. If the styling is for all content from the target site, 304 still works logically. If the argument is "all content in the browser", it fails as it depends on the address.

And I can see the argument for either. If I increase my terminal's font and run a curl, the response is scaled up. That makes sense, I scaled up my terminal.

To that end, it is odd that scalling up is per document origin. I'm assuming that is configurable?

[ncallaway]

I would consider the browser's built-in page for "I couldn't load news.ycombinator.com" to be a separate site from "news.ycombinator.com".