WIP: test(css): Proof of concept for possible approach to using custom CSS class names

[jsit]

DO NOT MERGE

I've been thinking a lot about the future of CSS on this project, if it's ever going to go beyond Bootstrap classes. Here's a proof of concept that handles a small but common component, the Paginator.

Goal

The goal here is to gradually move away from Bootstrap class names to custom class names, while still using the styles that Bootstrap provides, with the possible ultimate goal of remove Bootstrap as a dependency entirely. Bootstrap doesn't provide an off-ramp as far as I can tell, and most articles either say "Don't use Bootstrap" or show someone rewriting an entire codebase.

Benefits

1. Reusability

Right now, every time we want to make a component that looks like another component that uses, say, four Bootstrap class names to get its styles, that new component needs to use all four of those classes. If a class is added to the original component for some small change, a developer will have to know to find every similar-looking component and update those class names as well.

2. Custom theming

Greasemonkey-style plugins and, more importantly, use stylesheets (for people with vision or mental impairments, for instance) have a really hard time latching on to collections of multiple classnames on a single component, so customizability is very difficult with Bootstrap classes only.

Approach

1. Use @extend on Bootstrap classes for complex styles

This is the shortest route to getting off of Bootstrap classes in the HTML, but it adds some well-documented overhead to the compiled CSS (see below). But for something like .btn, Bootstrap unfortunately doesn't provide any mixins.

2. Use Bootstrap Sass vars

This is possible for smaller utility classes, like margins and colors, and is more "future-proof," as vars like $spacer can be easily copied into a custom codebase

3. Use BEM

BEM is a common naming methodology that works well for complex projects with a lot of people touching the same codebase.

4. One component at a time

Rather than throwing hundreds of CSS classes at the codebase and hoping that something is eventually done with them, doing this on a component-by-component basis will allow any shortcomings to surface earlier to allow for better course-correction. Lessons will be learned as components are rewritten, lessons in terms of naming, file structure, @extends and vars, etc.

Obstacles

1. Style inconsistencies

One of the benefits of Bootstrap is that it provides a fully consistent UI; there's no easy way to just put an arbitrary 17px margin on something, for instance, and this can be a good thing.

Moving to separate stylesheets will invite the temptation to add these arbitrary values, which could quickly result in a lot of UI inconsistencies.

2. Bloat

Using @extend a lot can seriously bloat a stylesheet, but gzip can crunch this down pretty efficiently.

[dankxiaobong]

The approach is really good. Getting rid of utility classes á la my-2 avoids tying the presentation to the markup.

The changes in #1421 are a good step forward, but it's not going far enough imo and should follow your POC.

Would your proposal also allow to flatten/getting rid of row-col-divs from the markup? Right now there's a lot of nesting (e.g. the markup of post-listing where username, community, MomentTime are clustered together into createdLine, with ton of d-block-col-rows etc.). Making it flat(er) makes it really flexible and readable. What do you think?
e.g.

post-listing
   post-listing__thumbnail
   post-listing__post-title
   post-listing__username
   post-listing__community
   post-listing__comments
   post-listing__timestamp
   post-listing__etc.

Also, what approach should we do to make main.css more readable?