Screenshot: https://i.imgur.com/VwFtgQh.png
https://www.onegraph.com/docs/subscriptions.html (it'll load in at the top of the page)
(As an aside, I keep HN at 150% and old reddit at 120% - those are the only 2 sites I have permanently zoomed)
But, if said destination resource is very slow to hit TTFB, you switch to a different tab, then back to the loading tab, you'll see the current page at the destination page's zoom settings.
My guess is that the interstitial system that injects error pages, Safe Browsing warnings, etc, doesn't hit the code path that says "we loaded a new (regular) page, go find its zoom settings".
Demo/PoC:
1. Run $anything that will serve a webpage on an arbitrary port - even an error page or directory listing. eg, python3 -m http.server, php -S 0:8000, etc.
2. Open the resource you just set up in a new tab, zoom in or out as preferred (eg, to a crazy level), copy the URL (for convenience), then close the tab.
3. Stop the server in (1), then run `nc -lp 8000` (or netcat, ncat, or $anything that will listen but never respond).
4. Open a new tab, navigate to a valid website (eg here :), example.com, etc), then once it's loaded, paste the URL you copied. With the page spinning and waiting for netcat (et al), navigate away from the tab, then back to it again.
Think I noticed this for the first time a couple years ago. Seems harmless enough.
Granted, I am probably importing old thoughts of it being a sort of user provided style sheet.
You could say that Chrome is designed to tie the zoom level to the viewport but I wouldn't count on this behavior springing up from an underlying design and implementation rather than it being a design choice for the user experience.
That is, consider your network is down. You try to go to an address. It doesn't load, so you try another address, the page changes; but it is the same content.
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.
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?"
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.
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?
Judging from the responses, this is actually a lot more popular than I assumed.
Which begs the question: Does anyone feel the default font is just perfect and wouldn't want it to be bigger even by a tiny bit?
I think it's perfect. What is your screen DPI (or rather angular pixel size from your normal viewing position) and is your browser set up to do any scaling based on that? Maybe it should be.
I really dislike the trend of giant fonts and whitespace.
I'm targeting WCAG 2.0. Keep an eye out for the "Show HN" coming soon!
(And pretty much all browsers have a zoom function for exactly this, it feels like a totally separate frontend would be more hassle to use than just ctrl + scroll wheel once)
Two of my hypotheses are:
(1) some designers are working on huge screens themselves, and don't test enough in usual resolutions
(2) it's easier to achieve good visual composition by doing a lot of whitespace (to the expense of hiding things below fold or in triggerable containers)
HN is readable - just - but it's definitely on the small side.
The complete lack of some sort of horizontal constraint doesn't help either. 200 character lines are no bueno for reading.
It worked much better to just tell it to output 1080p and let my television scale it... less graphics memory too. I still need to scale HN up relative to other sites in order to read it though.
If I compare the text of your comment to the text of an article on npr.org it seems like about the same as the difference between 9pt and 12pt, and they are using a serif font that seems to be a lot easier to read.
It's a style choice I guess? It seems like it would work best on a large 1080p display, so maybe that's just what the person who designed the layout was using.
Zoom doesn't fix line lengths of 1500 characters and terrible color contrast.
The link to the site guidelines is 7pt with a contrast that fails WCAG 2.0. No wonder no one reads them.
That depends on your browsers zoom implementation. Firefox is able to zoom the text/element sizes while keeping the page width the same on HN.
EDIT: People who disagree, care to explain? I zoomed in, so why would I expect it to zoom out just because its a different page? What am I missing?