You are getting the mobile view somehow. The playground and "Featured video" section should be on the right.

Please mention your browser version and your system details also.

@andybons @katiehockman

The top bar takes up twice the space, so perhaps some CSS is slightly broken and makes the site content not fit horizontally?

Recentish Firefox on Linux. I have font sizes set to not-default but that doesn't seem to matter. It does look like the individual containers are all set to a width of 430px, and are in a container of 831.3px or so. So it looks like they shouldn't fit side-by-side, and I'm not at all sure why the entire thing's being shoved into 830px on a ~1600px wide display.

Hmm:

.HomeSection {
    flex: 0 0 430px;

If I make that second number a bit smaller, suddenly I get two (tiny) columns.

So, looking further:

#page > .container,
.Header-nav,
.Footer {
  max-width: 59.38rem;
}

This seems to be what's producing the 831px width for the whole page. If I increase it a little bit, I do indeed get two columns -- but the columns are still really narrow. I'm not sure why the HomeContainer things are getting a size specified in px at all, let alone one so apparently small.

For what it's worth, I get two columns on Firefox 67.0.4 on Linux.

Update: My font default size is 14; if I increase it to 16, I get two columns, but the columns are still tiny.

So I think there's actually three different issues biting me here.

1. The width of the overall container is computed in different units from the widths of the sub-containers. This causes erratic behavior.
2. The widths of the sub-containers are in px, which are almost certainly the wrong unit -- they won't scale with font size, and large font sizes will make them even worse.
3. The widths of the sub-containers just seem really tiny to begin with. I usually assume that 700px or so is the smallest thing that will be wide enough to read comfortably.

I'm not sure I want a two-column display; on the other hand, the contents of the columns are pretty tiny, so maybe that works for this. But it's about half the width of, say, this github comments thread, at least for me.

If px are being used instead of rems then that's a bug. If you adjust the flex value to be

flex: 0 0 26.875rem

Using the dev tools does that help?

Also, what is the exact version (user agent string) of your browser? Thanks.

That does in fact get me the two (very narrow) columns.

Huh. So I went to look at the playground container:

.Playground-inputContainer {
  border-top-left-radius: 0.3125rem;
  border-top-right-radius: 0.3125rem;
  overflow: hidden;
  height: 10.63rem;
}

Well that explains why the input container is so short: It's specified explicitly as being so short, apparently? (But I'm not sure whether any of these style values might have been generated later by scripts as opposed to initially hardcoded.)

I'm not sure what height should be, but it seems like it would make sense to try to specify it in lines, or have it figure out its height from its content, or something?

I don't see a trivial way to find my user agent string, it's "Firefox Developer Edition 68.0b14 (64-bit)", running on Linux.

My default preference, for desktop browsing, would be to have the page use at least Most of the screen. It looks like around 115rem is the point at which increasing the width stops making the display wider, but since there's nothing outside the container, it's not as though I need margins for much.

@seebs
https://www.google.com/search?client=firefox-b-d&q=what%27s+my+user+agent

Cute!

Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0

That is fascinating, and it is now really weird to me that it's not included in About.

Change https://golang.org/cl/185597 mentions this issue: content/static: update homepage column widths to use rem units

The width of the columns on the homepage and height of the playground input are correct according to our designer's spec. We will take this feedback into account as we iterate more, but let's consider the primary issue closed (I'm redeploying golang.org now with the fix).

I concur. Thanks! It may not look like what I most want, but it now definitely looks the way it's intended to.