5 ms·

I've been writing CSS since 2009 and though it's always been a love/hate relationship, I didn't feel this way until last week. Not sure how new this is, but "dy

I've been writing CSS since 2009 and though it's always been a love/hate relationship, I didn't feel this way until last week. Not sure how new this is, but "dynamic viewports" are now a thing in CSS. The "dynamic viewport" is the area not obstructed by the browser UI. Literally the only reason I can see for this to exist is because iOS Safari obstructs the browser UI with its stupid toolbar. So we're building new additions to the language purely because Apple builds user-hostile features for their mobile web browser. Lovely. </rant>

SebastianKra 3y ago
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)
- deleted 3y ago
  [deleted]
- imauser 3y ago
  I think he meant the bottom address/controls bar.
  - SebastianKra 3y ago
    Yep, but that doesn't obstruct the page. Except for a version from 2 years ago that never even made it out of beta ;)
    - imauser 3y ago
      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.
      - SebastianKra 3y ago
        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)
      - danielvaughn 3y ago
        Yeah this is what I was referring to, thanks.
imauser 3y ago
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".
- zerocrates 3y ago
  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...
  - danielvaughn 3y ago
    Yes exactly, we’re adding features specifically to the language to accommodate vendors who aren’t respecting the spec. Feels very backwards.
- danielvaughn 3y ago
  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.
  - bamfly 3y ago
    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?
    - danielvaughn 3y ago
      Yep, and it always has. It's super reliable on desktop.
      - bamfly 3y ago
post-it 3y ago
The Opera mobile app used to have an appearing/disppearing navigation bar too, as I recall. It's a handy standard to have.
marcellus23 3y ago
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?
- danielvaughn 3y ago
  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 makes developing for the mobile web fairly difficult, and thus 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.
  - manicdee 3y ago
    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.
    - danielvaughn 3y ago
      (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.

SebastianKra 3y ago

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)

deleted 3y ago
[deleted]
imauser 3y ago
I think he meant the bottom address/controls bar.
- SebastianKra 3y ago
  Yep, but that doesn't obstruct the page. Except for a version from 2 years ago that never even made it out of beta ;)
  - imauser 3y ago
    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.
    - SebastianKra 3y ago
      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)
    - danielvaughn 3y ago
      Yeah this is what I was referring to, thanks.

imauser 3y ago

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".

zerocrates 3y ago
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...
- danielvaughn 3y ago
  Yes exactly, we’re adding features specifically to the language to accommodate vendors who aren’t respecting the spec. Feels very backwards.
danielvaughn 3y ago
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.
- bamfly 3y ago
  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?
  - danielvaughn 3y ago
    Yep, and it always has. It's super reliable on desktop.
    - bamfly 3y ago

post-it 3y ago

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

marcellus23 3y ago

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?

danielvaughn 3y ago
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 makes developing for the mobile web fairly difficult, and thus 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.
- manicdee 3y ago
  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.
  - danielvaughn 3y ago
    (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.