mobi / gosheets Goto Github PK

A linter would not only help us write code consistently, but also help us catch errors with compilation that we might not notice otherwise.

We should install a sass linter and configure it with appropriate defaults for our project. We might even be able to get away with using the default configuration that is provided.

It looks like sass-lint might be a good option.

Currently, our grid assumes that everything that is a direct descendent of a .grid-column should take up 100% the width of said column. This assumption leads to misleading results, especially when working with forms.

.go-column {
  flex: 1 1 auto;
  padding: 0 $column-gutter $column-gutter--double;

  > *:not(.go-container) {
    width: 100%;
  }
}

I think we should either remove this style or we should introduce a mechanism to control it.

We need to add a MIT license for the project. We will also need to update our package.json to reflect those changes as well.

Documentation on node module licenses can be found here: https://docs.npmjs.com/files/package.json#license

Here is a nice reference that lists the differences between various licenses: https://choosealicense.com/licenses/

We could further isolate our typographic styles using a combination of :not and the [class] attribute selector.

What if we applied the following to all of our typographic element selectors?

Example

h1:not([class]),
.go-heading-1 {
  font-family: $heading-font-stack;
  font-size: 6rem;
  font-weight: $weight-light;
  letter-spacing: -1.5pt;
  margin-bottom: .25rem;
}

The above example will only apply in two instances.

1. A <h1> element without a class
2. Any element where the .go-heading-1 is applied

This should be helpful when applying our styles to existing codebases.

Note: The h1:not([class]) will have a higher specificity than the standard h1 which will make it take precedence over any styles applied directly to the h1 selector.

We have gotten some consistent feedback on our table styles.

The header kind of looks like the first row as it follows the same pattern as the 3rd row.

-Some User

Feedback I'm getting is - it could cause some heartburn because its kind of hard to tell the difference between the headers and the table.

-Some Other User

I've been talking to a lot of people and everyone's been saying that with the green header bars gone that it's difficult to see the "page breaks". Would it be possible to slightly increase the size of the header text or something to help distinguish the headers too?
-A User

We could probably take a look at this in subsequent iterations.

It would be really nice if we could get some baseline automated testing at least just to ensure that out main sass file can compile successfully.

If we had a linter it would help us avoid some of this, but I think we would all feel better if we knew that what we were writing doesn't bring down anyone else's software.

I've done a bit of research. we might be able to integrate some really basic sass compilation into Travis CI or some similar tool.

Something like this would even be enough for now, though, I would maybe want to see if we could get this done with node rather than ruby. https://mattandre.ws/2014/01/testing-sass-travis-ci/

We used tried to apply a gradient to background-color which doesn't work.

background-color: $ui-color-negative-gradient;

should be:

background-image: $ui-color-negative-gradient;

As a result our error modifier does not apply the appropriate background.

The default font size for buttons is a little too big. I'm thinking it should be:

font-size: 0.875rem;
letter-spacing: 0.015rem;