Rendered at 22:30:16 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
JoshTriplett 23 hours 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.
account42 15 hours ago [-]
> 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 :|
moffkalast 9 hours ago [-]
Gotta pump those fingerprinting datapoints up.
seg6 22 hours ago [-]
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.
Borealid 21 hours ago [-]
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.
chazzalpha 5 hours ago [-]
A solution in search of a problem, as it were
heisenbit 16 hours ago [-]
Unless you have e.g. a kiosk with physical buttons below the screen an the labels on the screen.
weego 16 hours ago [-]
Kiosks by definition don't alow users to modify the ui. they run in kiosk mode
coldtea 15 hours ago [-]
You'd be surprised
coldtea 13 hours ago [-]
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!
TeMPOraL 10 hours ago [-]
> 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.
JoshTriplett 6 hours ago [-]
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.
crote 8 hours ago [-]
Of course, but "physical buttons have to match up with website elements" isn't relevant in either case.
JoshTriplett 21 hours ago [-]
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.
hulitu 18 hours ago [-]
> 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".
LiamPowell 18 hours ago [-]
> 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.
JoshTriplett 4 hours ago [-]
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.
hinkley 1 hours ago [-]
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.
bryanrasmussen 9 hours ago [-]
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.
LiamPowell 5 hours ago [-]
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?
kqp 21 hours ago [-]
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.
hulitu 18 hours ago [-]
> 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
wat10000 22 hours ago [-]
The author should not intend that, and if they do, my browser should do its best to put a stop to it.
shijie 21 hours ago [-]
I'm fairly certain you just replied to the author
9 hours ago [-]
alterom 21 hours ago [-]
I hope the author gets the point then.
wat10000 20 hours ago [-]
The author referred to themselves in the third person, so I did the same.
21 hours ago [-]
hahn-kev 11 hours ago [-]
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.
brazzy 10 hours ago [-]
[dead]
kccqzy 23 hours ago [-]
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.
seba_dos1 23 hours ago [-]
Same. Thank heavens the website doesn't know the position of the browser's window in respect to the screen it's on.
sheept 20 hours ago [-]
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]
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.
gmueckl 18 hours ago [-]
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.
happymellon 17 hours ago [-]
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.
gmueckl 15 hours ago [-]
Then continue to enjoy your broken popup menus and combo box drop downs, for starters.
seba_dos1 11 hours ago [-]
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.
tredre3 3 hours ago [-]
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.
kyusan0 59 minutes ago [-]
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.
gmueckl 7 hours ago [-]
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).
happymellon 13 hours ago [-]
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.
casey2 5 hours ago [-]
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
account42 15 hours ago [-]
The its only fair that complex applications don't care about how well they work under your snowflake WM either.
happymellon 13 hours ago [-]
Complex applications work fine.
AlienRobot 10 hours ago [-]
You are literally replying to a thread that has an example of a game where the position of the window matters.
krick 23 hours ago [-]
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.
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.
jagged-chisel 23 hours ago [-]
Wait, I have to hold my phone how in order to see the div? ಠ_ಠ
blamarvt 23 hours ago [-]
I assume you have to be facing the server...
dotancohen 13 hours ago [-]
This might actually be useful as some people do their maintenance facing either Jerusalem or Mecca.
alterom 21 hours ago [-]
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
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.
(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...)
p1mrx 21 hours ago [-]
So the content falls down at 10 m/s^2 unless you're falling alongside it.
happymellon 17 hours ago [-]
And running to counter earth rotation...
fluoridation 20 hours ago [-]
But the problem is, you can never quite catch up to it without a rocket.
valleyer 19 hours ago [-]
No, you can also take your clothes off and throw them upward with sufficient force.
dotancohen 13 hours ago [-]
I think that I saw somebody take your advice about five hours ago at the beach.
LocalH 19 hours ago [-]
Stop giving them ideas! :(
1bpp 21 hours ago [-]
position: hyperfixed;
kazinator 21 hours ago [-]
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.
hulitu 18 hours ago [-]
Thank god there was no Google then. They would have put the knobs on the screen.
silon42 16 hours ago [-]
It's also an extra information leak.
seg6 23 hours ago [-]
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.
stevage 22 hours ago [-]
> 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.
nottorp 16 hours ago [-]
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.
dotancohen 12 hours ago [-]
I used Tree Style Tabs until recently, and never experienced this. Also now with the native vertical tabs I've never seen this.
nottorp 11 hours ago [-]
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.
danillonunes 21 hours ago [-]
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.
hennell 10 hours ago [-]
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.
scubbo 22 hours ago [-]
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.
wizzwizz4 22 hours ago [-]
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.
seg6 22 hours ago [-]
Fair enough, that criticism resonates. I've decided to keep this behaviour only in the extension and have reverted it from the blog. Thanks!
retrochameleon 20 hours ago [-]
Thank goodness
LocalH 19 hours ago [-]
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?
1718627440 7 hours ago [-]
So the website also wants to my monitor, and chair position and the angle from which I am looking? Got it.
nkrisc 22 hours ago [-]
Joke’s on you: my browser window isn’t centered.
sebastiennight 20 hours ago [-]
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
nkrisc 12 hours ago [-]
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.
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.
Telaneo 12 hours ago [-]
The sidebar reduces the size of the viewport, and the viewport is what you're centring within. This is obvious and sensible behaviour from Firefox. Please don't centre based on screen res or whatever. Basing your centre position on anything other than the viewport is user-hostile behaviour.
yreg 12 hours ago [-]
Perhaps bad design, but user-hostile is a bit of a stretch.
i386 12 hours ago [-]
Its an entire misunderstanding of how the layout system works.
ipsod 9 hours ago [-]
It's user-hostile enough to make users hostile toward your site, for sure. It's not annoying, it's enraging.
crote 8 hours ago [-]
It causes annoying flickering when you resize the window, as it is constantly fighting the browser.
stkdump 17 hours ago [-]
Funnily I can't reproduce the effect at all. I am using Firefox and with sidebar the content of the page centers on the remaining viewport width, like any other site does. I have also tested with Edge, same result. With Edge's auto collapse (i.e. non sticky vertical tabs), I get the described effect, but again this is like any other site. I was actually expecting quite bad results in Edge because it has some sidebars on the right and I thought this page compensates in the wrong direction then. Don't have Chrome installed to see if that does anything differently.
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.
fluoridation 23 hours ago [-]
I had no idea what this was talking about at first because I had JS blocked, so nothing special seemed to happen when I opened the bookmarks panel. This looks absolutely goofy. I don't know why you'd want the content potentially getting covered by unrelated UI elements.
busymom0 23 hours ago [-]
> This looks absolutely goofy. I don't know why you'd want the content potentially getting covered by unrelated UI elements.
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:
> I don't know why you'd want the content potentially getting covered by unrelated UI elements.
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.
krick 23 hours ago [-]
Screenshots would be helpful, because (you may be surprised to learn that) it is not entirely obvious which mode of behavior is supposed to be "wrong".
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.
seg6 22 hours ago [-]
I’ve added GIFs showing the intended behavior. The brief movement doesn’t bother me, opening or closing a sidebar already resizes the webview and causes pages to reflow in the browsers I use. Ending in the wrong state after repeatedly toggling it is a bug. And yeah, if you prefer viewport centering, there’s no reason you’d want to use the extension.
jdiff 19 hours ago [-]
Not trying to argue you out of your preference, but trying to understand it: Why would you want to be able to accidentally hide parts of the page by having a sidebar open, or extended too far? I don't understand why the page should pretend to take up the whole window and ignore that it does truly live in just a viewport. I get why aesthetically it might be pleasing, but isn't that pretty short-lived when faced with serious practical drawbacks?
crtasm 23 hours ago [-]
Meanwhile this website has learned how to break mouse scrolling.
crote 8 hours ago [-]
That's because they are using a fixed-height container element with an "overflow: scroll" on it, which is needed to get that little grey bar at the bottom to complete the "page of paper on grey background" feel.
Which of course completely ignores that a page of paper can't scroll, but I guess doing it in a way where the content is split over multiple "pages" underneath each other is too complicated for a basic website - and would be even more jarring to the average reader.
inventor7777 22 hours ago [-]
What do you mean? On macOS Safari I see a scroll bar that I can drag with my mouse if I wish.
crtasm 21 hours ago [-]
Scrolling the page with mousewheel/multitouch doesn't work unless the pointer is inside the white area
...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.
globular-toast 15 hours ago [-]
It's still broken. It seems to use JS to scroll when outside the white area, but this has a different effect from native browser scrolling. On my device the native scroll is smooth but the fake one is immediate and jumps further on each scroll.
PetitPrince 15 hours ago [-]
So this interpret the sidebar as a temporary UI element (like a popover window), but for me I'd rather interpret the sidebar as a constant element (like the sidebar of Windows Explorer). And indeed I'm using Firefox with Tree Style Tabs or Sidebery to have an explorer-like tree view of my browsing session; it makes more sense for me to have this as a permanent fixture.
With that in mind, I would think this kind of preference should be under the control of the browser, not of an individual website.
pixlmint 13 hours ago [-]
I think it' very debatable whether or not this should be a web page's behaviour.
ezwoodland 21 hours ago [-]
Websites should be thought of as VMS and shouldn't be trying to reverse engineer host state.
al_be_back 10 hours ago [-]
For some reason, this made me think of privacy & security issues: user fingerprinting, user-type detector (devtools open = dev/engineer) etc.
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.
drewbeck 21 hours ago [-]
You’ve effectively created a slide over sidebar. It’s an interesting hack to get there but IMO “should” properly be the domain of the browser.
alterom 20 hours ago [-]
See, I'm keeping my siidebar open most of the time, so I WANT it to cover the content that would otherwise be visible - said no one ever.
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.
duskdozer 14 hours ago [-]
The internet has become so imbalanced in favor of what the website owner wants to run on my machine. I've still not found a reliable way of modifying user-hostile React pages. I'm sure before long it will take custom builds to avoid custom CSS being blocked by anti-tamper measures.
pprotas 8 hours ago [-]
This is horrible, centering should take the sidebar width into account.
saghm 20 hours ago [-]
I'm confused about why this website is using less than half of my window for content. I understand wanting some margins, but a third of my window on each side seems pretty egregious. At least it's centered though!
thiht 7 hours ago [-]
Do you want them to add Subway Surfers in the sidebars? What would they display if there's nothing to display? This is such a weird criticism, do you think you want the text to use the full width? It would just be hard to read because of long lines, shorter lines are more comfortable
It's not like unused space results in some kind of waste, this is not paper, blank space is okay
saghm 7 hours ago [-]
> It would just be hard to read because of long lines, shorter lines are more comfortable
That's a pretty subjective view, and one at odds with literally every other website I can think of
kbelder 4 hours ago [-]
It's a subjective view that a huge number of UX designers absolutely believe is 100% factual, unfortunately.
saghm 4 hours ago [-]
I've never run into another website using so little of my horizontal space before though, so I'm struggling to understand why this one is an outlier for me based on that explanation alone.
woodrowbarlow 19 hours ago [-]
wrapping text at 55-75 characters per line is often recommended in digital typography by UX. research implies that an optimum length exists to maximize reading speed, and although it depends on many factors 55-75 is often parroted as a universal rule.
account42 14 hours ago [-]
If only UX worried more about user preferences instead of coming up with these dogmatic rules. We can already resize the browser window if we want shorter lines.
duskdozer 14 hours ago [-]
I'm sure there's something going back to newspapers on this (though they would of course, fill multiple columns), but I can't help but suspect a lot of these UX studies are just predetermined to justify things like extra space on the margins for ads, "related content" distractions, and such things.
saghm 7 hours ago [-]
I've definitely never seen a newspaper that left over half of the page blank.
duskdozer 7 hours ago [-]
I didn't say it so clearly but that's what I meant when I said they fill multiple columns. The columns themselves are narrow but there are many of them. I wouldn't mind the narrow widths as much, although this site is excessive, if there was a multi-column layout that filled the window. A lot of the annoyance is needing to scroll.
Telaneo 12 hours ago [-]
And here I am, comfortable with and prefering lines at or above 200 characters. Given how many other changes have been made in the name of UX that have been gone compleatly against what those letters stand for, I'll press X to doubt on that one.
To be fair, I read fairly quickly, so maybe this is true if you only read 100 words per minute or whatever.
tredre3 3 hours ago [-]
Short columns aren't (only) about overall reading speed, it's about comfort.
When you're done reading a line your eyes must move back to the start of the next line. With short lines you can still fully see the end of the previous line so it's easy to locate. It's a lot harder to do with long lines.
Telaneo 2 hours ago [-]
This doesn't reflect my own lived experience.
antimages 14 hours ago [-]
Incidentally, the same parrots love eating ants, which is why they're okay with the awful squished up and narrow images the same column width allows for.
hulitu 18 hours ago [-]
> wrapping text at 55-75 characters per line
What happened to 80 ?
Ok, 75 is "close enough", but 55 ?
cluckindan 16 hours ago [-]
80 is a terminal standard, 55-75 is UX.
inigyou 12 hours ago [-]
The right change is to change the browser so the sidebar becomes an overlay, if you want this.
kazinator 21 hours ago [-]
What's the substantial difference betweeen "browser added sidebar" and "the browser has allowed height and width of the window to be resized since the dawn of the web"?
butz 8 hours ago [-]
Next they are going to round of the corners of your website, either you like it or not.
git-nebulous 3 hours ago [-]
screw, marry, kill of the following <center>, <blink>, <marquee>
I'll go first:
- marquee
- center
- blink
now if you don't mind there are some clouds outside I need to shake my fist at
sbb_equals_ffs 11 hours ago [-]
> This is a fairly specific itch. I use one browser window tiled directly in front of me, usually with its sidebar open. When a site deliberately centers a narrow layout, I want it at the dead center of that window, not the space left over beside the sidebar.
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.
todotask2 15 hours ago [-]
Wouldn't the HTML Popover API be a simpler fit for the sidebar example? If it's an overlay rather than part of the document layout, popover seems to eliminate quite a bit of the positioning logic.
jszymborski 23 hours ago [-]
margin:0 auto is the (probably incorrect) incantation I have always reached for
sodapopcan 23 hours ago [-]
That's fine but it only centres horizontally. Usually when people talk about "the div centring problem" they mean x and y, dead centre (as this article is).
saghm 20 hours ago [-]
The article only seems to very briefly mention the vertical axis, with pretty much all of it focusing on interactions with the sidebar (which only affects the horizontal width).
antimages 14 hours ago [-]
I disagree that's what people mean by "Centering a div" and the hilariously repetitive corpus of programmerhumor jokes on the matter seem to disagree too.
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.
sodapopcan 6 minutes ago [-]
Oh really? I always assumed as I never thought horizontally centring was ever a huge problem. Vertical was the actual hard thing for a long time (which is something table cells could easily do since the beginning).
You caught me in that I didn't read the full article, but I read enough to see that it has this CSS which centres on both axes:
body {
display: grid;
min-height: 100dvh;
place-items: center;
}
Brajeshwar 18 hours ago [-]
One of my favorite interview questions was asking how many ways a developer can center a DIV or any block element in a container/browser with pre-defined height, or responsive heights. I have special soft corner heart for people who said TABLES.
gerdesj 22 hours ago [-]
I'm 55 years old. My eyes are not what they used to be and neither are my glasses. I also own a copy of "Usage and Abusage" but I'll pass on that. Click on story link. My laptop renders a page - OK its black text on a white background (thank you but I doubt its a deliberate boon) ...
... 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.
sherry-sherry 20 hours ago [-]
Longer lines of text are harder to read. There's a reason newspapers, books, articles, etc are all vertical and often have a similar amount of words per line. It's easier to follow, scan, and find your place.
I’ll accept that not everyone likes a portrait page on a landscape screen, that’s a matter of taste. But if you’re going to invoke Usage and Abusage, grammar, punctuation, and "basic decency", it would help to identify an actual error. And perhaps write "it’s" correctly while doing so. I’m also unclear what moral failing you think an A4 aspect ratio represents.
The demo page doesn't work as described in Firefox when I open my bookmarks or history sidebar. It displays a correction offset, but Firefox valiantly defeats this evil hack and makes sure that the box is still at the center of the viewport as the viewport shrinks. It doesn't work in Chromium either when I open devtools as a sidebar. Correction resets to "move pointer" when I do.
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.
assimpleaspossi 10 hours ago [-]
You have an out of place script element at the end.
LocalH 19 hours ago [-]
Nah, I'd rather not. I want sites to center within the viewport, not the browser window. I keep my tabs in a vertical sidebar, and I treat the viewport as "the browser". I want things that should be centered to be centered within that viewport.
nnevatie 11 hours ago [-]
Just because you can, doesn’t mean you should.
songhonglei1985 20 hours ago [-]
hah the pointer trick is clever. tbh ive been living with everything looking 5px off for years and just... accepted it. does this work with vertical tabs in firefox?
josefrichter 23 hours ago [-]
Centering a div? Impossible.
qingcharles 19 hours ago [-]
GPT-6 will solve this.
13 hours ago [-]
danielvaughn 20 hours ago [-]
Am I the only person that loathes sidebars in browsers? Maybe it's because I've been using a browser since 1996, but my brain is deeply set in the idea that the space below the chrome 110% belongs to user space.
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.
Dylan16807 18 hours ago [-]
Do you always have browsers maximized? If you're used to other windows next to the browser then I'd be surprised if you still find sidebars distracting.
proc0 18 hours ago [-]
Z-index has been invented.
SpyCoder77 22 hours ago [-]
There needs to be images on this
bmitc 16 hours ago [-]
And then people added unhidable chat bot icons and even windows that hide entire parts of the interface with no recourse.
seg6 22 hours ago [-]
A bit of context, since this is much less serious than it may have sounded:
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.
mohsinq227 9 hours ago [-]
[flagged]
singpolyma3 21 hours ago [-]
[dead]
mvhughes 21 hours ago [-]
[dead]
dyauspitr 22 hours ago [-]
Jokes on you, I never learned and now LLMs just know how to do it instead.
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.
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.
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.
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.
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?
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
[0]: demo: https://mdn.github.io/dom-examples/screenleft-screentop/
[1]: https://romanbaiocco.github.io/browser-ball-reloaded/
My tiling window manager doesn't care what your snowflake app thinks it wants, and I don't either.
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.
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.
I'm trying to think of any that try to fight the interface quite as much as this.
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
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...)
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.
Guess they think like the OP.
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?
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.
https://www.w3schools.com/jsref/tryit.asp?filename=tryjsref_...
https://developer.mozilla.org/en-US/docs/Web/API/Window/move...
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.
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.
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.
Which of course completely ignores that a page of paper can't scroll, but I guess doing it in a way where the content is split over multiple "pages" underneath each other is too complicated for a basic website - and would be even more jarring to the average reader.
...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.
With that in mind, I would think this kind of preference should be under the control of the browser, not of an individual website.
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.
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.
It's not like unused space results in some kind of waste, this is not paper, blank space is okay
That's a pretty subjective view, and one at odds with literally every other website I can think of
To be fair, I read fairly quickly, so maybe this is true if you only read 100 words per minute or whatever.
When you're done reading a line your eyes must move back to the start of the next line. With short lines you can still fully see the end of the previous line so it's easy to locate. It's a lot harder to do with long lines.
What happened to 80 ? Ok, 75 is "close enough", but 55 ?
I'll go first: - marquee - center - blink
now if you don't mind there are some clouds outside I need to shake my fist at
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.
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.
You caught me in that I didn't read the full article, but I read enough to see that it has this CSS which centres on both axes:
... 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.
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.
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.