doc: fix misaligned columns on Firefox/Linux

[silverwind]

13em and 234px are equivalent here. By using the same unit as is used to specify the width of the TOC, we can work around a presumed Firefox layout bug, see nodejs/help#32.

[therebelrobot]

+1

[jmarca]

For what it's worth, as I commented on the nodejs/help#32 thread, if I change the body font size style from 62.5% to 100% it looks fine. To be explicit, I changed:

body {
  font-family: "Lato", "Lucida Grande", "Lucida Sans Unicode", "Lucida Sans", Verdana, Tahoma, sans-serif;
  font-size: 62.5%;
  margin: 0;
  padding: 0;
  color: #3a3a3a;
  background: #fcfefa;
}

to

body {
  font-family: "Lato", "Lucida Grande", "Lucida Sans Unicode", "Lucida Sans", Verdana, Tahoma, sans-serif;
  font-size: 100%;
  margin: 0;
  padding: 0;
  color: #3a3a3a;
  background: #fcfefa;
}

then 13em looks fine:

[silverwind]

Still pretty sure we're dealing with a browser bug here. We arrive at 18px font size through:

body { font-size: 62.5% } /* 10px */
#content { font-size: 1.8em } /* 18px */

Setting body to 100% would make the text way too large, at 28.8px 😉.

[jmarca]

Okay, you are right, not a bug! I restarted firefox with a new profile and the page renders fine. Must be some sort of cruft crept in over the years.

Sorry for the noise, thanks for helping me fix my firefox setup, I guess...

[silverwind]

@jmarca thanks for confirming. I still think this patch is good to have either way.

[silverwind]

Anyone able to rubberstamp a LGTM here? It's a bit unfortunate that this CSS isn't on the website repo.

[Fishrock123]

Rubber-stamp LGTM if it works. It'd be good to test the built docs on a bunch of browsers though since we only update the docs site with releases.

[silverwind]

Yeah, it was confirmed working by the user, I think it's good to use the same unit for the same distance to avoid weird browser bugs like this. Will land shortly.

[silverwind]

Landed in 8b75030. I'll remember to test the docs in more browsers, thanks.