Prior to this commit, at <979px, the .container in a .navbar has
`width: auto`, but a normal .container has width 724px, which causes
the two to drift out of sync.
This fixes that.
(Arguably, it's weird for us to waste ~200px scrunching
this down to 724px at this ratio, but we can solve that
as a separate issue later.)
(imported from commit 1f431ca1e2168db75821ea0be43941d29fd3e6b8)
We always want the navbar to stick at the top, no matter what
the screen size, and we want it to consistently look the same
height, etc. regardless of our page width.
This is possibly also accomplished via position: absolute !important
and other overrides in our own CSS, but this actually seems
slightly cleaner in a way.
(imported from commit 340fafb49bcbc1088a816897d320e252c4615d19)
Some time between the 2.0.4 and the 2.1.0 upgrade, Bootstrap broke in
a way such that clicking on a dropdown did not cause it to close.
Here's the bug thread about it:
https://github.com/twitter/bootstrap/issues/4497
I've implemented this workaround discussed there, though the bug is
fixed in 2.1.1, so when we upgrade this will go away (which is why I
only reluctantly tag it 'third', since the diff will not need to be
carried forward.)
(imported from commit f8d9cf65b33306a426d864c9b503bb3446614111)
...from 1200 to 1180 pixels.
The monitor I use for Humbug is exactly 1200px wide. With the scrollbar I come
in just under the original Bootstrap threshold, so I get a scrunched-up nav
sidebar next to a bunch of empty space.
It's annoying to do this in our own CSS because we basically have to duplicate
the whole @media block to make everything fit together.
I don't love editing third-party files like this, but if it gets reverted by a
later update, the consequences are minimal. If we have important hacks like
this (or just a lot of them), we should decide on a better way to manage them.
For now I have just tagged the commit subject with "[third]".
(imported from commit ef3022b7eb0fdfc8862083bdbb1fb805fbeba2c7)