You often need to base your styles on the height of the viewport, for example if you need to pin an element to the bottom of the screen, or if you need an overlay to fill up the entire screen.

You can do this in CSS with a dimension called "vh" and "vw" (viewport height and viewport width). If you're using JS, you can use "window.innerHeight" and a few other methods.

The problem is that in virtually every browser, this screen space is respected as the space that belongs to the developer. It would be extremely inconvenient if the "vh" value didn't take into account the browsers own UI. Because then you'd need to adjust your style value to account for that height. Well, iOS Safari does exactly that, and it's been a major source of frustration for web developers for years.

It's hostile to users because it degrades the experience. I honestly don't know why they do it, but my more cynical side says that they don't mind sacrificing UX on the mobile web because it competes with their app store.

The more realistic explanation is that the toolbar takes up space and every pixel has value on smaller screens. Moving the toolbar out of the way when the user is not likely to be using tools makes sense when understanding the web from the perspective of someone reading articles.

This behaviour is hostile to developers, not users. A more cynical commenter might suggest that you're the one engaging in user-hostile behaviour with hovering elements and overlays.

(1) the browser is an application platform so devs are users as well, (2) making it harder to develop good UX by not following the spec _does_ make the experience worse for end users, and (3) "hovering elements and overlays" were just a couple of examples - there are tons of reasons why devs need to reliably know where the boundary of the fucking screen is.