Not just iOS safari. I believe Firefox on Android is also the same.

Can't believe showing user either controls or address bar at the bottom is consider "user-hostile".

It's just... vexing to have "viewport" units in the spec, but then the user agents are just drawing stuff on top of the "viewport" but not changing its reported size, so now we need additional "real viewport size" units...

Yes exactly, we’re adding features specifically to the language to accommodate vendors who aren’t respecting the spec. Feels very backwards.

Having controls at the bottom isn't user hostile, it's the fact that it obstructs the space allotted for developers. This makes it much harder to develop mobile sites - in my experience a very large minority of sites fuck it up, and it makes the mobile browser feel like a worse experience.

Does the viewport reflect reality on desktop when e.g. http login controls cover part of the page, or another window is covering part of it?

Yep, and it always has. It's super reliable on desktop.

Like, you drag a window over your browser, and the viewport values change? I'd not have expected that, and I don't think I've ever noticed that behavior. How does it account for all of those sorts of things (browser-provided login prompts, or browser settings windows, or certificate-info pop-downs, or non-browser windows being dragged on top of part of the browser window) not necessarily resulting in a viewable area describable as a rectangle?

Sorry I should have been more specific. The viewport is merely the window of the browser itself where the website is rendered. The calculations given to devs reflects that area, and it does change if the user resizes their browser. But it doesn’t change if something is displayed on top.

It’s true that some temporary browser elements will display on top of the viewport, but these are things like alerts where it makes sense.

To have a permanent fixture that takes up space and then have the viewport lie to devs about the actual dimensions is really frustrating.

The Opera mobile app used to have an appearing/disppearing navigation bar too, as I recall. It's a handy standard to have.

I've seen much hate for the iPhone notch, but "user-hostile" is a first.

(I assume you are talking about the notch, because Safari doesn't have a toolbar that obstructs the page)

I think he meant the bottom address/controls bar.

Yep, but that doesn't obstruct the page.

Except for a version from 2 years ago that never even made it out of beta ;)

It does before user scroll down the page a little. That's what he called dynamic viewport being added to spec. It was to address issue of incorrect viewport height (100vh) when the toolbar is visible. So units such as svh, lvh, and dvh are added.

Ah gotcha.

But that has been the default behaviour in any mobile browser since forever. I don't know why he would blame Apple for this.

(Though I don't know how it used to interact with vh)

Yeah this is what I was referring to, thanks.

What Safari behavior are you complaining about, exactly? ("obstructing the browser UI with a toolbar" doesn't make any sense to me)

And why is it user-hostile?

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.