Live data from Hacker News

We finally learned to center a div, then browsers added sidebars

seg6.space

81–90 of 172 posts

Re: We finally learned to center a div, then browsers added sidebars

#82
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.

Re: We finally learned to center a div, then browsers added sidebars

#83

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.

> 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. windows.

This is industry standard. I wish I was being sarcastic.

Re: We finally learned to center a div, then browsers added sidebars

#84
post #78

Earlier quoted context omitted.

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.

Re: We finally learned to center a div, then browsers added sidebars

#85
post #67

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!

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.

> wrapping text at 55-75 characters per line

What happened to 80 ? Ok, 75 is "close enough", but 55 ?

Re: We finally learned to center a div, then browsers added sidebars

#86
post #76

Earlier quoted context omitted.

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.

Re: We finally learned to center a div, then browsers added sidebars

#87
post #41

Earlier quoted context omitted.

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.

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

And running to counter earth rotation...

Re: We finally learned to center a div, then browsers added sidebars

#88
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.

Re: We finally learned to center a div, then browsers added sidebars

#89
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.

Re: We finally learned to center a div, then browsers added sidebars

#90
post #85

Earlier quoted context omitted.

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.

> wrapping text at 55-75 characters per line What happened to 80 ? Ok, 75 is "close enough", but 55 ?

80 is a terminal standard, 55-75 is UX.
Post reply on HN