I use a single browser instance in a tiled window manager, occupying a fixed window directly in front of me, usually with a sidebar open. When a site intentionally centers a fixed-width container, the sidebar leaves that container visibly off the dead center of my screen. I happen to dislike that. This is a personal aesthetic preference for my particular setup, not a claim that viewport centering is generally wrong.
The intended behavior does not remove content or replace responsive layout. The sidebar still narrows the webview and the page reflows normally, the correction only repositions the container that was already meant to be centered, so its center remains in the same physical place. If content ends up covered, offscreen, or stuck in the wrong state, that’s a bug.
I don’t particularly mind the brief movement while toggling a sidebar, since the browsers I use already visibly resize and reflow pages while doing so.
I’m considering reverting the behavior on the blog and keeping it extension only. I’ve also added GIFs to the post showing the intended effect.
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.
That's my reaction to almost all new web APIs :|
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.
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.
Note I like the default behavior of browsers to center on the viewport as opposed to the window treating sidebars as overlays over the page. Whenever pages do that with their own gadgets I hate it, because they often don't move their content out of the way and it makes it unreadable unless scrolled out of the range of these gadgets, which often isn't possible at all. And even when it is, it effectively reduces the total usable screen to a fraction.
Whenever I'm bothered enough (happens mostly on mobile), I use a kill sticky bookmarklet to fix that.
Detecting the difference between window.innerWidth (viewport) and window.outterWidth (window with bar etc) in JS, can be powerful to the browser user via an Extension. However, not so if the site/page uses (e.g a JS Lib).
Personally, i like the viewport vs window separation that the browser provides. I don't want an Element to not budge or care about my sidebar/window dressings, thank you very much.
Here in Canada, the mobile website for anything related to Indian immigration (Indian passport, visa etc) is done via this absolutely goofy website with multiple levels of UI elements and popups covering the content. Have a look on mobile:
https://www.blsindia-canada.com/ottawa-jurisdiction/index.ph...
Well, if Google and Firefox does it, it must be good. Ah, yes, I forgot Microsoft with its helpfull transient "We just introduced new bugs. < remind me later > windows.
This is industry standard. I wish I was being sarcastic.
...appears it's been fixed since my original comment. There's still no scrollbar in the expected place on the side of my browser window though.
Anyway, I wouldn't say it currently behaves nicely (like something I would like to reuse anywhere whatsoever). Tested on Firefox opening Bookmarks on the left. First off, there is this ugly flicker, as browser first renders the "wrong" version, then your JS "fixes" it. Second, there is some concurrency problem, as by opening and closing Bookmarks repeatedly I somehow managed to render both versions: centered to viewport and covered by sidebar.
And, yeah, as others have said, I also think that allowing sidebar to cover your webpage content is absolutely bogus and don't foresee myself wanting this behavior, ever. But that's up to you.
With that in mind, I would think this kind of preference should be under the control of the browser, not of an individual website.
I still don't understand the need for this. I mean, it's hn, so "I wanted to" is a perfectly acceptable reason, but when you resize and move the browser window, you don't expect the content to remain where it was. The browser window is not a literal window that shows you what's behind your screen. If the sidebar should behave like an overlay, then that's something that the browser should manage, not each website. From the blogpost I can see that this preference is highly subjective, so it being a browser-wide setting makes much more sense.
But yay, it's centered relative to the window now! God forbid the user tiles their windows, because it breaks the aesthetic the website author intended.
To be fair, I read fairly quickly, so maybe this is true if you only read 100 words per minute or whatever.
What happened to 80 ? Ok, 75 is "close enough", but 55 ?
I've tried a few browsers with vertical tabs, and my brain keeps seeing them as part of the page itself. It's a very distracting and uncomfortable experience.
And in either case, I don't think the article fully agrees either, since the thesis of it relates to a strictly horizontal element. If the article doesn't intend to disagree, then it was just a framing device they used in the writing that has some distractions regarding the vertical component unfortunately attached.
... why on earth is the offering a "page" ie emulating a printed page? In portrait!
I'll accept that most people are not fixated about grammar, punctuation or basic decency: that's fine.
However a "page" in portrait that looks awful on a landscape screen is unpleasant. You can easily request my viewing parameters and adjust accordingly. It's even worse when you are dispensing advice about www page layouts.
Some more on this below:
Optimal Line Length in Reading — A Literature Review (https://journals.uc.edu/index.php/vl/article/view/5765)
Practical Typography — Line Length (https://practicaltypography.com/line-length.html)
I could appreciate the hack from an engineering perspective if it actually worked, but from a user perspective, this is just another example of overambitious anti-designers going out of their way to replace whatever simple, sane and predictable defaults a browser provides out of the box with something incredibly dumb. Browsing has become a rather paranoid activity of constantly second guessing what bespoke bullshit the website authors might have attached to operations that otherwise have previously established sane behaviors provided by the browser by default.
[0]: demo: https://mdn.github.io/dom-examples/screenleft-screentop/
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.
The same way the vertical centering counts the viewport height only, not the url bar and the tab bar.
Anyone got a Tampermonkey script or tiny extension to re-override this to make such sites actually center in the viewport, like I prefer?
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
PS: if you switch from the touchpad to a wireless mouse, we'll move the div accordingly
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.
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".
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.
Guess they think like the OP.
My tiling window manager doesn't care what your snowflake app thinks it wants, and I don't either.
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!
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.
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.
I'm trying to think of any that try to fight the interface quite as much as this.
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
(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...)