d4d6991643
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.
We are now able to set the background color for `Unfocused` tabs.
We were relying on the control being placed atop a white background.
When we moved to using the control atop a non-whitebackground,
it showed that the `Unfocused` tabs had a transparent backround.
All of our designs show `Unfocused` tabs with a white backround.
See https://github.com/NoRedInk/noredink-ui/pull/14 for more information.
|
||
|---|---|---|
| src/Nri | ||
| styleguide-app | ||
| tests | ||
| .gitignore | ||
| .travis.yml | ||
| elm-package.json | ||
| LICENSE | ||
| Makefile | ||
| package-lock.json | ||
| package.json | ||
| README.md | ||
noredink-ui
UI widgets we use.
Versioning policy
We try to avoid breaking changes and the associated major version bumps in this package. The reason for that is to avoid the following scenario:
|
x 4.6.0: Adding RadioButton widget
|
x 5.0.0: Breaking change in the TextArea widget
|
x 5.0.1: Styling fix in the Checkbox widget
|
Suppose you just released version 5.0.1, a small styling fix in the checkbox widget, for a story you're working on. If the project you're working in currently pulls in noredink-ui at version 4.x, then getting to your styling fix means pulling in a new major version of noredink-ui. This breaks all TextArea widgets across the project, so those will need to be fixed before you can do anything else, potentially a big effort.
To prevent these big Yaks from suddenly showing up in seemingly trivial tasks we prefer to avoid breaking changes in the package. Instead when we need to make a breaking change in a widget, we create a new module for it Nri.Ui.MyWidget.VX.
We should change this process if we feel it's not working for us!
Examples
This repo contains an app showcasing all of these UI widgets.
To see them locally:
make styleguide-app/elm.js
Open styleguide-app/index.html in your browser.
Alternatively, you may use elm-reactor. Please be aware that you'll need to globally install fonts (in particular, Muli) if you go this route.
Tests
Run tests with
make test
CI (Travis)
Travis will run make ci to verify everything looks good.
You can run this locally to catch errors before you push!