Travis can't determine what node_modules will be if it doesn't exist
yet, so it fails and has to retry. No need for that, so we'll just put
it where we know it will be.
The `initial` `background-color` is `transparent`.
We got away with not setting the background color before
as we were always using segmented controls on top of white backgrounds.
We now want to use a segmented control atop a non-white background,
so we have to explicitly set the `background-color`.
tl;dr; Use a class for each variant instead of overriding one variant.
Before, we relied on CSS specificity in an unclear way.
The `Focused` class was applying properly because it was ordered later
than the `Tab` class in the stylesheet.
The ordering that is important is the ordering in `styles` value.
Since `elm-css` generates the stylesheet in the order of the lists,
the `Focused` rule would be generated after the `Tab` rule.
Meaning the `Focused` rule would take precedence over the `Tab` rule
if an element had both classes as it was defined later in the stylesheet.
There are some concerns with this approach:
1. It's not readily apparent that the ordering in `styles` is important.
It is pretty easy to change the ordering of the list
and have it break the styling.
2. We rely on `elm-css` to generate the stylesheet in a specific order.
If it changes the order of rules it generates,
we're almost surely going to break the styling.
3. Altering styles for tabs that are not focused is even less intuitive.
Since the specificity is the same,
you might not know why a given rule applies (or doesn't apply).
Rather, we can eschew the specificity/precedence issues
by applying a different class to each tab.
The stuff that is the same can stay on the `Tab` class,
and the stuff that differs can be on different classes.
On the monolith we have a base css file somewhere that adds this
property by default. In this package we don't (and even if we did, we
couldn't bundle it with the elm code), so this commit adds the property
manually on a div that needs it.
