Styling / CSS revamp

[teampolyglot]

Some inspiration for look and feel:

Dashboard

Another version for dashboard: https://www.figma.com/file/Ou2MO24kZLBHfXcMSYHe4B/LearnAwesome?node-id=352%3A0

Browser extension:

An ideal way to do this in a future-proof way might be to support user-selectable themes. This will also help with supporting dark modes.

Fundamentally, we need to decouple the content from styling and CSS frameworks completely. It should be possible to build one theme with Bootstrap, and another with Tailwind CSS etc. Customizable styles will improve UX and may make it easier for users to migrate from GoodReads etc.

[teampolyglot]

One potential approach would be to let the users store theme preference in database and apply a different CSS:

 <%= stylesheet_link_tag current_user.stylesheet_preference || 'bootstrap', media: 'all', 'data-turbolinks-track': 'reload' %>

This might not be sufficient, because both Bootstrap and Tailwind rely on adding classes in the markup. To get different markup, we could use ActionPack variants: https://geekhmer.github.io/blog/2015/02/23/actionpack-variants-on-rails/

In controller: request.variant = current_user.stylesheet_preference then have a index+tailwind.html.erb and index+bootstrap.html.erb file

[teampolyglot]

I've been implementing a Tailwind version for every template and partial. So, if a file exists in app/views folder with the name show.html.erb, I am renaming it to show.html+bootstrap.erb and then creating a tailwind layout for the same with the name show.html+tailwind.erb. When all the layouts are converted, we can make Tailwind as the default in app/models/user.rb#theme_variant

There is a command-line tool called tailwindo that converts bootstrap code to Tailwind. But it doesn't seem to help a lot with layout etc, so manual work is still needed.

[DamnedScholar]

Supporting both Bootstrap and Tailwind for theming might be unmaintainable. For a site that has its own JS framework and might not always do things the BS way, BS is probably a little heavy-handed both in terms of what components should look like structure-wise and how interactive components should work. What happens if someone writes a theme that requires jQuery? Are all users going to have to download jQuery or is that going to also be behind a conditional? What happens if jQuery-based functionality interferes with the way a component works? Anything you can do in BS, you can also do in TW with a JS library attached (Alpine, in this case), and TW is easier to pick up in general (if you know CSS, you basically already know Tailwind, whereas Bootstrap is a bunch of component names that don't mean anything until you see them displayed).

To support theming, you won't want to give people direct access to markup anyway unless you take measures to ensure that people can't do weird stuff (like add <script> tags to external JS). In this case, Tailwind comes out ahead since every Tailwind class string is a semantically meaningful layout instruction. A BS theme would have to override properties for the pre-defined classes (like you always have to do with BS), while a Tailwind theme can start with an unstyled component and add any custom styles dynamically. A Tailwind theming engine could also be aware of what people shouldn't be able to do (e.g. overriding the site logo with a dirty picture url() or making text too light for its background) and provide suggestions about what properties are good to customize for a particular component ("this component has text in it and/or has font styles on the default, so you should pay attention to font styles").

If you want to encourage theme submission, a component sandbox where users can go in and tweak styles for specific items, save their tweaks, and share links to their custom themes would be better than giving random Internet people access to stylesheets or markup. That's not tough to do with Tailwind, but would be difficult with Bootstrap since you'd have to validate user input to make sure it has quotes and semicolons in the right place. With TW, a WYSIWYG sandbox could even have dropdowns for common/mutually exclusive choice points, like font, background color, border, etc. Then people don't even have to know CSS to use it, they just have to click into the component interface and make selections on a form that can update the output instantly and doesn't have any side-effects because utility classes don't affect anything outside of the element you're looking at.

With Tailwind, you could have every component's styles work like an internationalized app: referencing a string from an external data file controlled by a config variable. Bootstrap can't do that except for very limited cases like btn-primary/btn-success.

tl;dr: Bootstrap is fine for doing things Bootstrap is good at. It's great for theming if all you want to theme is the pre-defined Sass variables. If you're looking for layout customization or accessibility to web tech novices, Tailwind is a little bit worse in its raw form (since the number of TW options is so massive), but the predictability and simplicity of Tailwind makes it easier to support in code systems and swap styles without worrying about side-effects from stray CSS or jQuery, and the app doesn't have to parse or validate CSS at all since you can derive everything in TW from the config file and generate custom configs in JS. TW will provide fewer dev headaches and can be skinned to be substantially more accessible than BS to a newbie.

[teampolyglot]

• We won't support arbitrary, untrusted themes for sure. Themes will have to be contributed via pull requests and reviewed before merging.
• I strongly agree with dropping Bootstrap completely due to maintenance effort. Tailwind CSS has worked out well, and now I feel more confident with it.

This is the repo where I keep Tailwind build script, plugins etc: https://github.com/learn-awesome/tailwindbuild This can be integrated in Rails asset pipeline itself.