Agreed, both outcomes are bugs and neither is intended. The idea is simply that, content the site author intended to be horizontally centered stays literally centered on my screen when browser UI changes the viewport.

This is a nonsensical goal.

If I drag a browser window to the right, making it cover the right-hand half of my monitor, it serves no useful purpose for "centered" content to migrate to the left edge of the window (the physical midpoint of the screen).

Centered means centered within the virtual viewport, not the physical screen.

Unless you have e.g. a kiosk with physical buttons below the screen an the labels on the screen.

Kiosks by definition don't alow users to modify the ui. they run in kiosk mode

You'd be surprised

That's somehow controversial?

There are kiosks used for public browsing, where the user has access to full browser app window and can change elements.

There are also ways to get around kiosk mode restrictions, or at least there were for Windows in kiosk mode back in the day. We used it to get browsing access or to just mess with the kiosk. The fun!

> There are also ways to get around kiosk mode restrictions, or at least there were for Windows in kiosk mode back in the day. We used it to get browsing access or to just mess with the kiosk. The fun!

And that's probably by far the most value those kiosks ever provided to society - the chance of overriding whatever malicious, socially harmful marketing bullshit purpose they overtly served, and do something fun or useful with them instead.

Alas, opportunities like this are disappearing, as security maximalists are running the show in our industry these days.

Of course, but "physical buttons have to match up with website elements" isn't relevant in either case.

A kiosk used for arbitrary public web browsing won't have expectations of physical buttons on the outside of the kiosk that line up with elements on the screen, which is what this branch of the thread brought up.

A solution in search of a problem, as it were

That results in the first outcome: the content is centered on the screen, which puts it under the sidebar, while there's perfectly good space being ignored off to the right of it.

It's a cute trick, please don't use it, this is one of many reasons why. If I have a sidebar open, it's because that space is not yours to care about.

> If I have a sidebar open, it's because that space is not yours to care about.

Drawing UI is hard. Firefox likes to draw the websites underneat the scrollbar. Google likes to draw system nabigation buttons over the window with all kind of funny interractions. That's what happenes when you train people "on the job".

> Firefox likes to draw the websites underneat the scrollbar.

This was a choice that they actively made. It's not hard by default, they just chose to do something stupid because they think it looks pretty.

The way I read the parent commenter it almost seems like they feel that Google's decision was the really stupid one. Maybe neither one is that great.

I also agree it's stupid when google puts UI over the webpage, but at least in that case they're not going out of their way to do it over an existing alternative.

For anyone not aware of how bad google is getting about this: Did you know that "sign in with Google" panel that appears in the top right corner of websites is actually part of Chrome rather than the website?

I genuinely like the trend towards invisible scrollbars that only become larger if you want to drag them with the mouse, and that don't affect layout. This seems like a win for having more screen real-estate, both for the whole window and for smaller scrollable elements where the scrollbar might otherwise be a noticeable fraction of the element's size.

You can also get layout glitches if you screw up your math where the scroll bar disappears and reappears in a tight loop. This is a dodge for that. The viewport doesn’t resize when the content gets longer and you either run never into > 1024 || > 1024, or you hit it on first paint and it gets solved at design time.

Think about users who don’t maximize the window, for whom centering to the screen, not viewport, would just be broken. It’s right to center to the viewport, and right that you’re able to turn that into centering to the screen by maximizing. The issue, I think, is that you don’t like that the sidebar changes the viewport, and really want a popup menu. I think your browser might duplicate sidebar functionality in configurable toolbar button popups, have you tried that? Failing that, I think the right solution to this problem might be a browser extension.

> Think about users who don’t maximize the window, for whom centering to the screen, not viewport, would just be broken.

This in blasphemy. Never, ever, think about the user. Users are idiots anyway. The apps shall be used for their intended purposes. All windows shall be maximized ( because we say so). /s

The author should not intend that, and if they do, my browser should do its best to put a stop to it.

I'm fairly certain you just replied to the author

I hope the author gets the point then.

The author referred to themselves in the third person, so I did the same.

That is only really possible if the window is full screen. By that logic it feels like if the user changes the window size you would want the div to stay in the center even then.

> My immediate reaction to this is why is the browser giving the site this information, and could we stop.

That's my reaction to almost all new web APIs :|

Gotta pump those fingerprinting datapoints up.