Same. Thank heavens the website doesn't know the position of the browser's window in respect to the screen it's on.

Actually, they do, sort of. At least, if you use GLSL shaders. I remember some demo project using it in a way that made it appear that the website "sees" another window with the same website, which blew my mind when I saw it first. Cannot recall the name or anything else to locate it.

My guess is that you’re remembering this demo: https://xcancel.com/_nonfigurativ_/status/172732259457002734...

Yep, that's right.

The ability from this demo is Chromium-specific, needs extra permissions and has nothing to do with GLSL: https://developer.mozilla.org/en-US/docs/Web/API/Window_Mana...

Wait until they realize that on mobile they can use accelerometer data to keep the element in the same position in space across translations of the device.

Wait, I have to hold my phone how in order to see the div? ಠ_ಠ

The same way Steve Jobs said to hold the iPhone.

I assume you have to be facing the server...

I mean, this could have applications, if you need to be facing a certain direction to read the content.

While the Silicon Valley is merely a figurative Mecca for all things tech, Apple could require people to be facing Cupertino if you want to watch a WWDC stream :D

Aww, looks like the magnetometer web API was abandoned: https://developer.mozilla.org/en-US/docs/Web/API/Magnetomete...

This might actually be useful as some people do their maintenance facing either Jerusalem or Mecca.

It's easy, you just need to hold your phone such that your eyes are pointed directly at the ads as they scroll up and down the screen. Thank you for consuming content.

position: hyperfixed;

So the content falls down at 10 m/s^2 unless you're falling alongside it.

But the problem is, you can never quite catch up to it without a rocket.

No, you can also take your clothes off and throw them upward with sufficient force.

I think that I saw somebody take your advice about five hours ago at the beach.

And running to counter earth rotation...

Translations? Not far enough, got to include rotations: https://developer.mozilla.org/en-US/docs/Web/API/Device_orie...

(And yes, CSS can rotate around all three axes, so you could make a div that resists rotating your device in addition to resisting translation...)

Stop giving them ideas! :(

I've actually kind of wanted something like that.

Sometimes there is no size setting that will get the text lines on a page to fit horizontally without making the text too small to read. Making it large enough to read means lots of left and right scrolling which is annoying.

A mode where moving the phone sideways scrolls the text at a matching rate so that the experience is similar to reading a page with a magnifying glass might be handy.

Most people would rather lines to be broken up and wrapped around than to have to walk around the room to read. Do you often find yourself reading photographs of stone tables or something?

Why would you have to walk? You would be moving the phone back and forth by less than the width of a page.

Wrapping is fine on some material, but when there are tables it can be very annoying.

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/

[1]: https://romanbaiocco.github.io/browser-ball-reloaded/

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.

All apps I use are well behaved and work to the relationship that the window they are given.

I'm trying to think of any that try to fight the interface quite as much as this.

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.

For example, the VS Code menu bar is broken because the drop-downs clip against the window frame, not the screen edges. The reason is different in this case, though (electron).

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.

With Dolphin file manager on Wayland this works for me as expected, a new window opens in the centre of the file browser window, no matter the size or position of the window. I didn't do any actual testing but I wonder what the difference is.

Making the pop-ups model has nothing to do with windows not knowing their position on screen.

It's a design choice.

It's not "my broken popup menus" since I'm not writing your app. This is some of the most basic portable software 101 I can't believe a real developer would complain about it.

If you do have that attitude there are a million other OOP style things to throw out for speed and correctness before virtual monitors and coordinating compositors

The its only fair that complex applications don't care about how well they work under your snowflake WM either.

Complex applications work fine.

You are literally replying to a thread that has an example of a game where the position of the window matters.

It was a cute stunt, and it's fine for it to stop working so that sites stop misbehaving.

The point of centering an element horizontally is to make sure that the content you’re viewing is directly in front of you. Browsers with a sidebar shift the content to the right, assuming the sidebar is on the left, which I’ve come to dislike! Others have expressed the same preference, hence this little snippet on my website.

> The point of centering an element horizontally is to make sure that the content you’re viewing is directly in front of you.

That's an awfully big assumption. For starters, you're assuming that the browser window itself is centered on the screen, and that the device is centered in front of the user.

I don't think this is the point of centering an element horizontally at all, and the result you have created here is not at all what I as a user want.

I use Firefox with a vertical tabs extension open all the time. Occasionally (rarely, mind) I run into sites that don't bring their full content into view unless I hide the tabs list.

Guess they think like the OP.

I used Tree Style Tabs until recently, and never experienced this. Also now with the native vertical tabs I've never seen this.

It almost never happens. And when it does it may be some other broken calculation. But I did run into sites that I can only guess did their layout based on the whole window and had stuff go under the tree style tab.

Joke’s on you: my browser window isn’t centered.

Ah but see, exploiting a Chromium API has let us know you've got this second screen on the side, so we're centering the div on your overall work space.

PS: if you switch from the touchpad to a wireless mouse, we'll move the div accordingly

1. Neither of my screen is to the side of the other.

2. The demo doesn't even work, the div stays centered in the viewport, not the program window when I open a side bar (Firefox).

3. Rarely does my browser even cover the center of my workspace, so it would be impossible to center anything in the center of my view without forcibly moving the program window from within the website.

Challenge accepted:

https://www.w3schools.com/jsref/tryit.asp?filename=tryjsref_...

https://developer.mozilla.org/en-US/docs/Web/API/Window/move...

As a rule, you should not add functionality to a website to compensate for browser misfeatures. People who want the browser to work differently can get a different browser: that's why we call them "user agents". Making the web all complicated like this mainly serves to make it harder for people to use alternative browsers, or for browsers to change their misfeatures without breaking compatibility.

Fair enough, that criticism resonates. I've decided to keep this behaviour only in the extension and have reverted it from the blog. Thanks!

Thank goodness

I salute your dedication to understanding and fixing a problem that bothers you - but I must add my voice to those who think that this is not a good design for general use. The viewport is the region within which content should be positioned, and thus within which they should be centred. By your logic, left-aligned content in a browser with a left sidebar should be deliberately covered.

This all sounds like a really elaborate way of not taking advantage of the fact that modern windowing operating systems don't require windows to be full screen, and allow you to position the sides of your browser window wherever you want them to be.

I don't usually use browsers sidebars, but when I do I mentally compensate for it. The viewport is in fact the part of the web page I expect to be the full width, and what things should be centered on.

The same way the vertical centering counts the viewport height only, not the url bar and the tab bar.

Stop worrying about what's happening outside the viewport. Your website has no right to care or even know what's happening outside the viewport.

Anyone got a Tampermonkey script or tiny extension to re-override this to make such sites actually center in the viewport, like I prefer?

The point of centering an element horizontally is to give equal space either side. Because you consider that to look best visually with your design. It has nothing to do with where it is in front of you, or anything other than placement in the space you have. Given a width for your content where should it sit. If you don't like the effect with a browser sidebar, don't limit the width with a browser sidebar.

So the website also wants to my monitor, and chair position and the angle from which I am looking? Got it.

Televisions used to have "sidebars", like a speaker on one side only, with some knobs co-located there also. Yet a test pattern would center in the picture tube, not the TV box.

Thank god there was no Google then. They would have put the knobs on the screen.

It's also an extra information leak.