Allow for a custom css configuration file for the reader mode

[ekianjo]

Hi, I love the integration of the reader mode - I was wondering if you could allow for a specific css file that could be an optional config file where we could customize how the reader mode looks?

[JoshuaCrewe]

Wallabag has this feature and it can be quite useful. It is a nice way to let people do their own styling and not have to deal with requests for style changes. Not sure how many of those this project gets though!

[Monirzadeh]

@ekianjo @JoshuaCrewe
I test that, and we can do that easily (but not clean yet)
some consideration for this feature:

1. It will be widely, not per user. (is it important?)
2. Should be modifiable in UI, or it is enough just copy custom.css to /css?

What do you think?

Note to future me:

• it should not be affect e-book CSS (not tested yet but if affect that I prefer not add this feature)
• what should we do if CSS code is not valid?(my first test show browser ignore that, but do we need validation mechanism?)

[fmartingr]

I'd say that this should be a per-user feature configurable in the UI. Users can have a textbox where they add custom CSS styles that are injected into the pages. Unsure how wallabag handles this, but that's the base on how I see this happening.

Security wise, we need to cleanup anything non-css from the user input to avoid any kind of stored xss or things like that.

@JoshuaCrewe can you provide examples on custom styling you found useful in the past?

[Monirzadeh]

In general, wallabag handle that this way

1. link custom.css in content.html in last link
2. user can edit that CSS to overrate default CSS.

I'm done that in one of my local branch and work fine.
Problem get a little complicated when you should do that per-user
If we need per-user, so somehow we should make content.html different for each user. Or call a variable inside that that link to user specific CSS.

[JoshuaCrewe]

@fmartingr I can indeed. The changes I made were very minimal. Things like :

• Making it use a system font
• I like bolder titles
• A few spacing tweaks
• A smaller line length on smaller screens
• Getting rid of the box shadows

This was all on the reader view. I think I intended to do the archive page but haven't got round to it yet.

This is a before and after. It is basically all the stuff that isn't worth opening a PR for because it is so minor and subjective but all the reasons self hosting is worth it:

[Monirzadeh]

@JoshuaCrewe can i have css to check that on other language?

[JoshuaCrewe]

@Monirzadeh Absolutely.

body {
  background-color: #fff !important;
  font-family: system-ui, -apple-system,
    /* Firefox supports this but not yet `system-ui` */ "Segoe UI", Roboto,
    Helvetica, Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji"; /* 2 */
}

#article {
  box-shadow: none !important;
}

#article > header > h1 {
  margin: 6rem 0 3rem;
  font-weight: 800;
  text-align: center;
}

#article aside .tools {
  justify-content: center;
}

#article aside .tools .stats {
  display: flex;
  flex-wrap: wrap;
  justify-content: center;
}

@media (max-width: 800px) {
  #article article {
    width: 70%;
    margin: 0 auto;
  }
}

.dark-theme #article {
  box-shadow: none;
}

.dark-theme body,
.dark-theme main #content,
.dark-theme #article,
.dark-theme .card,
.dark-theme .card-panel,
.dark-theme .card .card-reveal,
.dark-theme .card-stacked .preview:not(.preview--default),
.dark-theme .card .preview:not(.preview--default),
.dark-theme .collapsible-header,
.dark-theme .collection,
.dark-theme .dropdown-content,
.dark-theme .nav-panel-add,
.dark-theme .nav-panel-search,
.dark-theme .side-nav,
.dark-theme .side-nav .collapsible-body,
.dark-theme .side-nav.fixed .collapsible-body,
.dark-theme .tabs {
  background-color: #101010;
}

[Monirzadeh]

@fmartingr
I do more investigation on how shiori settings and user account works (for separate user custom CSS). As I see, shiori don't have real separate account at all.
Settings store in browser level with cookies. The user actually shares the same database (user can't have their own bookmarks).
We can separate custom CSS for each user with some tricks, but it not something clean and right way to do.

For example, if you change a setting in user1 and login with user2 on the same browser, they change settings of each other.
If I change Create archive by default on my working machine and at the end I log in with my home machine, I don't have my settings.
Settings not attach to the user, it attaches to the browser.

So I think if we have this feature and may other improvement, we should first change current account logic. Store some settings (not all of them) on database. Then start to add this feature.

Have real account, have lots of benefit.
If I want to do some improvement on account system, should I wait until #497 done?
What do you think?

[fmartingr]

Please, let's wait until we have the new API in place. Multi-user support is something we should aim for too, but some considerations need to be made to not break the current usage for people that use shiori as a bookmark silo for multiple people. Once we move into that direction having per-user database settings will be pretty easy to implement, but let refactor one step at a time (even though the new API PR is going to be huge)