We finally learned to center a div, then browsers added sidebars
seg6.space185 points by seg6 2 days ago
185 points by seg6 2 days ago
The net result of what this site is doing seems to result in one of two effects when I open the sidebar, randomly:
1) the sidebar covers the content, while the content has blank space to the right, or
2) the content moves off the right edge of the screen, leaving a large blank space to its left.
Both of these are wrong. If I have a sidebar open, the site is now narrower, stop trying to be clever.
My immediate reaction to this is why is the browser giving the site this information, and could we stop.
> 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 :|
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.
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.
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.
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.
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?
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.
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.
This might be some kind of a weird requirement for a piece of art, but I would literally never expect a website to center a div according to the browser window instead of the viewport. It just looks wrong and feels wrong.
Same. Thank heavens the website doesn't know the position of the browser's window in respect to the screen it's on.
There's several web APIs for browser window positioning, like screenX/Y[0] (which is what OP uses), which allows for those classic pop-up based browser games from over a decade ago, like Browser Ball.[1]
[0]: demo: https://mdn.github.io/dom-examples/screenleft-screentop/
For this to work, the browser itself would have to know where its window is placed on the screen. Not all platforms provide such information.
While providing this information to websites without user permission is probably a longstanding mistake of web browsers, windowing systems withholding proper on-screen positioning from native applications is a bug in that system - a bad one.
Why? The window and its position shouldn't matter to the app.
My tiling window manager doesn't care what your snowflake app thinks it wants, and I don't either.
Then continue to enjoy your broken popup menus and combo box drop downs, for starters.
Are these broken popup menus and combo box dropdowns with us in the room right now?
Yes, some things in some complex applications can break, but there are solutions and, practically, these particular things you listed simply aren't among those that break.
GNOME Files (nautilus) made the file property dialog a modal because they really want it to be centered relative to the file browser window and wayland didn't let them position or obtain coordinates.
The result is that you can't open open two file property dialogs at once (to compare sizes or dates or any other meta data, it's a common thing one might want to do).
Hopefully you'd agree that Wayland should allow apps to position windows relative to their own windows, at the very least.