CSS and stuff

Let's talk about our CSS.

Michelle Bu

★TXJS

`!important`

has a modal.js, modal.template, and a corresponding modal.css

has a few lines in create_new_account_view.css

.some_specific_view { .some_specific_section { background-color: pink; ... } ... }

5 minutes in the life of a developer who needs to add some CSS to the existing dashboard.

"I need to add an explanation to this field."

"Let me look for a similar thingy."

"Cool, now inspect element."

"`git grep 'div:last-child p'`" - nothing

"Alright I'll just take the last one and make it look as close as possible."

"Donezo!"

1. Determination

(MVP)

1 year and 10 engineers later...

2. Development

(remember: poop is append-only.)

1 year and 20 engineers later...

3. Denial

6 months and 40 engineers later...

4. Despair

Every time I fix a bug something breaks. Our CSS is growing at a rate of 3 poops per week and there's nothing I can do about it because everything is hopeless.

So let's break down how our existing dashboard's CSS managed to spiral downhill. It's not that in stage 1 we made bad decisions. I think those decisions were 100% the right decisions, and were perfect for our size and expertise and timeline at that time. The way our CSS was handled optimized for fast development and simplicity.

But as the organization grew, our CSS needs started to change. Not every engineer that joined was good at or cared about CSS, or had the context to know exactly how every view in our codebase worked or was used.

Regardless, I believe that if we can start over and talk more about how we write CSS, we could avoid some of these problems. You wouldn't write Javascript without tests or a linter, right? Or generally tolerate poop in other parts of your codebase, so why allow it in CSS?

So, what were the problems?

No tests

"It's almost impossible to test CSS." *

* sorta

No conventions

.potato { span { ... } }

div.potato > span

div.potato span

.potato-inner

.potato_inner

#potato_inner

No CSS reuse

transfers_list_view.css

Yup

sublist_subscriptions_list_item.css

Nope

Why does it matter?

This causes:

- Too much cruft built up to even tackle the non-MVP problems: mobile readiness, accessibility. Cycle of more and more poop buildup.

- Progressively more sluggish to build new things.

- Unhappiness when working :(. and disdain/shame for the codebase, which is unhealthy for the team

The first time around, no one will debate that we made the right decisinos at the time, given the tools available. It's just that a lot of our tools and decisions didn't optimize for future happiness.

So let's start over. This time, let's add CSS to the conversation. Since we built the first iteration of our dashboard three years ago, a lot has changed, and a lot more tools are now available to help us solve our problems, and let us think of CSS as a first class citizen like the other tools that we use.

No CSS reuse

Boot

Documentation

No conventions

.namespace-

ComponentName

(-descendant)

(--descriptor)

.bs-

BigNumber

-delimiter

--comma

rework

Tools make conventions easier.

rework-stripe-conformance

Tools make conventions easier.

rework-namespace

.namespace-

ComponentName

-descendant

--descriptor

Tools make developers happier.

rework-inherit

Checkbox

Radio button

We also pulled in rework-inherit, a plugin that lets us use very simple, very limited inheritance.

One common way to style checkboxes and radio buttons is to hide the native input element, then style an empty label element to look like a checkbox or radio button. Except one's squarish and the other is circlish. And then there's a second label element that would be the actual label of the checkbox or radio button.

On the left is only a part of the checkbox component, which has a few descendants--a hidden input element, the label that we style to look like a checkbox, and the actual label of the checkbox. On the right is us reusing the checkbox code for the coreesponding three radio button elements. This sort of simple inheritance makes our lives a lot easier, while not being too overloaded and allowing more complex relationships.

Tools make developers happier.

kfcss

Abstraction!

€5 678 ,99 €5.678,99

{{bs-big-number number=5678.99 country="DE"}}

You're probably making fun of how ugly our class names are. It does, after all, get quite verbose, especially when you're starting to worry about accessibility and user experience and updating the markup of your components from time to time--one thing to keep in mind is that markup is VERY closely tied to your CSS. When you change one, you also need to change the other, so it should also be properly abstracted.
there was a bit of controversy when we first introduced these components, around both the long classnames and the verboseness o fhte markup, but the reality is you hopefully will only be writing HTML by hand ONCE. (In fact, if you did write them by hand in more than one place, whenever your components change, you'll need to change them in every single place.) you likely want to abstract them away with templates. In our case we're using Handlebars, but all templating languages work fine. but when focussed on writing CSS components and markup that makes sense (instead of just being the simplest possible thing), these classes make it a lot easier to think about how to structure your CSS.

This is not groundbreaking, but abstracting away components make deleting code easier and upgrading markup for css. no more direct coupling of css to your templates.

Abstraction!

No tests

rework-pseudo-classes

grunt-huxley

.modal-dialog-view div.modal div.modal-content-form div:last-child p

.bs-Fieldset-explanation

Thanks! :)

@michelle on Github

@hazelcough on Twitter

Resources:

rework (preprocessor)
SUIT CSS (style guide)
rework-suit-conformance (conformance checks)
rework-pseudo-classes (testing)
Huxley (testing)
grunt-huxley (testing)

Let's talk about our CSS.

Michelle Bu

★TXJS

!important

5 minutes in the life of a developer who needs to add some CSS to the existing dashboard.

"I need to add an explanation to this field."

"Let me look for a similar thingy."

"Cool, now inspect element."

"git grep 'div:last-child p'" - nothing

"Alright I'll just take the last one and make it look as close as possible."

"Donezo!"

1. Determination

(MVP)

1 year and 10 engineers later...

2. Development

(remember: poop is append-only.)

1 year and 20 engineers later...

3. Denial

6 months and 40 engineers later...

4. Despair

No tests

"It's almost impossible to test CSS." *

* sorta

No conventions

.potato { span { ... } }

div.potato > span

div.potato span

.potato-inner

.potato_inner

#potato_inner

No CSS reuse

transfers_list_view.css

Yup

sublist_subscriptions_list_item.css

Nope

Why does it matter?

No CSS reuse

Boot

Documentation

No conventions

.namespace-

ComponentName

(-descendant)

(--descriptor)

.bs-

BigNumber

-delimiter

--comma

rework

rework

rework

Tools make conventions easier.

rework-stripe-conformance

Tools make conventions easier.

rework-namespace

.namespace-

ComponentName

-descendant

--descriptor

Tools make developers happier.

rework-inherit

Checkbox

Radio button

Tools make developers happier.

Tools make developers happier.

kfcss

Abstraction!

Abstraction!

No tests

rework-pseudo-classes

grunt-huxley

.modal-dialog-view div.modal div.modal-content-form div:last-child p

.bs-Fieldset-explanation

Thanks! :)

@michelle on Github

@hazelcough on Twitter

Resources:

`!important`

"`git grep 'div:last-child p'`" - nothing

`.potato { span { ... } }`

`div.potato > span`

`div.potato span`

`.potato-inner`

`.potato_inner`

`#potato_inner`

`transfers_list_view.css`

`sublist_subscriptions_list_item.css`

`.namespace-`

`ComponentName`

`(-descendant)`

`(--descriptor)`

`.bs-`

`BigNumber`

`-delimiter`

`--comma`

`.namespace-`

`ComponentName`

`-descendant`

`--descriptor`

`.modal-dialog-view div.modal div.modal-content-form div:last-child p`

`.bs-Fieldset-explanation`