Ability to select multiple theme-files

[waahto]

(Related to #91)

Typora is a tool for writing. Sometimes we need to write for this thing and sometimes for the other. For everybody who uses markdown, it's obvious that the writing experience matters. This is why we need the ability to select multiple css-files for the theme.

For example. If I were to write poetry, I'd have a autumnish bg image and curly headers. If I write something scientific, black on white with sans-serif does it great. If I write a scientific article on poetry, I might want to have the inspirational bg image but still maintain the font. So I might want to have three theme files to mix:

1. poetic-bg.css
2. cursive.css
3. helvetica.css

Instead of selecting the theme with radio-button style as it's done now, we should have a checkbox selection with the ability to move the selected files up and down on the list. I figure it would be quite easy to output this list into a master.css by having properly arranged list of @import x.css -lines.

[AlexPasternak]

Considering all the features this software could have, this seems like such a random edge case. I've never seen the ability to mix multiple themes in another tool. Not in TextMate, IntelliJ, Atom, etc. The theme is the theme.

[waahto]

"The theme being a theme" is redundant. If you want to change the background image you have to rewrite/copy-paste the whole CSS or fool around with @imports yourself. This brings bloat to the theme-menu. Multi-theme support wouldn't break any current functionality, would add no new ones but rather enhance what is currently there.

There's a bunch of md-editors out there and if Typora wants to compete in that market, it's vital to bring something new to the table. If somebody just wants to write technical documents or is satisfied with github theme, there are plenty of editors out there, most of them bug free. The beautiful edge of of Typora is the ability to use custom CSS and this could be sharper still.

[abnerlee]

I have thinked before how to allow users to tweak themes more easily. My suggestion is to allow users to override theme/base css files, by providing a css file with ".user.css" suffix.

For example -> css in base.user.css will be applied to all themes, github.user.css will be applied to Github theme, so, user can do normal modifications (like change font, font size, background color) without copy/paste the whole theme file.

@waahto what do you think about this solution?

[waahto]

I'll assume that the workspace of Typora is a single HTML file. I would have the CSS structure something like this:

<link href="style.css" rel="stylesheet" media="all" type="text/css" />

A single file that is linked from the document. Inside of it, we have more simpleness:

/* style.css */
@import "base.css";
@import "themes/forest.css";

Style.css would simply be a container which is designed so that the user has no need to directly edit that. Rather, it's edited by Typora when the user changes it's theme from forest to sea;

/* style.css */
@import "base.css";
@import "themes/sea.css";

The actual files in the themes folder are the ones that the user should have full control over. Both the default themes and the ones made by user should be mixed there. The directory structure should look like this:

Typora/
    lib/
    docs/
    style.css
    base.css
    themes/
        forest.css
        sea.css
        slab.css
        cursive.css
        web.css
        book.css
        scifi.css
        bg/
            forest.jpg
            sea.png
            interstellar.jpg

The important part here is that not all of the css files do all the things that a full theme might do. For example, let's say that forest.css and sea.css only have a few lines, like so:

body {
    background: "bg/forest.jpg" #396;
    color: #fff
}

Then we have slab.css and cursive.css which only define font property. Respectively web.css and book.css further define margins, line-heights and stuff like that. The trick is that now you can use the container css that we talked about like this:

/* style.css */
@import "base.css";
@import "scifi.css";
@import "forest.css";
@import "slab.css";
@import "web.css";

Because CSS works like so that what ever comes last has the effect, our theme files slowly override whatever there is that is defined in base.css. We also have a file scifi.css after base.css. This might be a fully developed theme that works as a starting point. Here the user has decided to change some of the aspects and selected a different background, font and so on while keeping the basic layout of scifi.css.

This is what the selection dialogue might look like inside Typora. User could also grab and drag the themes on top or below each other and it would directly affect the order of imports in style.css.

Now, how does this sound like? I don't believe that there's anything too complicated going on here and I can't find any other downsides either. Rather, this approach would add a tremendous layer of flexibility to the customisation. For me, the possibility to use custom CSS is the key why I use Typora and why I've recommend to all my my fellow writers and bloggers. The thing we care about most is the inspirational experience of putting our thoughts down.

[AlexPasternak]

There's a bunch of md-editors out there and if Typora wants to compete in that market, it's vital to bring something new to the table

Yeah, that something new is called rich preview, and pretty much no one else is doing it, except for Classeur (and not as well). That's why I'm here, using this tool. My question remains: can you name a single editor that allows for multi-theme selection? I use a lot of IDEs and editors, and have never seen one.

[waahto]

I haven't seen this feature either. That's why I'm suggesting it. If I understand you right, you don't seem as fascinated about this possibility as I do :) Would you consider this as a bad feature or would you have a suggestion for a better way to have this functionality?

I currently have around twenty themes that I've made. Most of them just switch the background image and set some colors. Some of them do more. Each theme uses multiple css files, this being the basic structure:

/* hero.css */
@import "waahto/skeletor.css";
@import "waahto/light.css";
@import "waahto/slab.css";

content { background-image: url("waahto/ninja.jpg"); padding-left: 20%; }
#write  { background: rgba(40,60,75,0.6); }
h1      { text-shadow:  0.1em 0.1em 0.1em #000; }
h2,h3   { text-shadow: 0 0 0.1em #000; }

Here I just set a few peculiarities while doing most of the stuff in skeletor.css. It's, as I would put it, the root theme that all my other themes use.

/* skeletor.css */
#write {
    position: relative;
    width: 90%; /*  Only for narrow windows */
    padding: 2rem;
    overflow: auto;
}
@media screen and (min-width: 60em) { #write { width: 50rem; } }
/*  Overwrite core.css to make things fit to #write */
#write p, #write h1, #write h2, #write h3, #write h4, #write h5, #write h6, #write div, #write pre { width: auto; }
/* ...and so on */

The other two files, light.css and slab.css, set the color scheme and the type, respectively. Each of them is used by about five themes.

This is the most economical way that I've figured out. But it would be even better if there was a simple way to handle the @imports inside Typora and move them around. Oh, and this wouldn't prevent self-contained themes from working, of course.

[AlexPasternak]

I don't know about bad, but I would consider it a confusing feature. Themes usually a) specify the whole set of attributes, making multiple themes redundant because the last would win by overwriting everything b) are previewed either through an image or a live editor preview, which is harder to do when you have to mix it into another one.

I do agree that it might be interesting, because sometimes you say "this theme is great, if only the font were X", but that's why here it's plain CSS that you can just modify. When you mix multiple full themes, the result is probably not going to be what the user expects. I don't think this would be a key feature for someone choosing this as an editor, so if I were a dev, I would certainly consider this an edge case, and not spend my limited resources on it. No offense, because this is clearly important to you. Just my opinion. It's ultimately up to the dev to decide.

[rahuldave]

@waahto do you have a repo with one of your themes? I'm trying to mess around with https://github.com/edwardtufte/tufte-css to make it into a typora theme and would learn a lot from your organization. I havent found any canonical docs for how to make themes yet...

[waahto]

In mac, the theme files are at ~/Library/Application Support/abnerworks.Typora/themes

The way I've done my themes is that I have the actual theme file, which is basically just a set of @imports. They just set the color and the font. Then I have one core file which does most of the essential stuff.

I don't have a repo so you'll find the files attached. I've also pasted the core file as a text if you have any questions. Feel free to use as you like. Some overrides may break future functionality.

Typora-theme-by-Waahto.zip

/*  Core styles for a custom CSS themes to Typora by Waahto.
    Made for my personal use and demonstration purposes.
    Do what the fuck you want.
*/

body {
    font: 100 1rem "Merriweather";
    line-height: 1.7em;
}
content {
    width: 100%;
    overflow: auto;
    background-size: cover;
}
#write {
    position: relative;
    width: 90%; /*  Only for narrow windows */
    background: #fff;
    padding: 2rem;
    overflow: auto;
    margin: 0 !important;   /*  Overwrite base.css and enable js position control   */
}
@media screen and (min-width: 60em) { #write { width: 50rem; } }
/*  Overwrite core.css to make things fit to #write */
#write p, #write h1, #write h2, #write h3, #write h4, #write h5, #write h6, #write div, #write pre { width: auto; }
/***********************************************
Headers
************************************************/
h1 {
    font: 3.5rem "Bevan";
    text-align: center;
    margin: 5rem auto;
}
h2 {
    font: 900 3rem "Source Code Pro";
    text-align: center;
}
h3 {

}
h4 {

}
h5 {

}
h6 {

}

/***********************************************
Paragraphs
************************************************/
p {
    text-align: justify;
    margin-bottom: 2rem;
}
#write { white-space: normal; } /*  Override pre-wrap in base.css   */
/***********************************************
Customise list bullets and numbers
************************************************/
ul, ol {
    font: 500 0.9em "Roboto Slab";
    margin: 1.5rem 0 1.5rem 2rem;
    list-style: none;
}
li {
    position: relative;
    padding-left: 0.15rem;
}
li p {
    margin: 0;
    text-align: left;
}
ol { counter-reset: col; }
ol li:before { content: counter(col); counter-increment: col; font-size: 1.2rem; }
ul li:before { content: "::"; font-family: "Merriweather"; }
li:before {
    position: absolute;
    margin-left: -2.5rem;
    font-weight: 900;
    display: block;
    color: #e63;
    margin-right: 2rem;
    width: 2rem;
    text-align: right;
}

/***********************************************
Other block level elements
************************************************/
hr {
    border: 0.3rem solid rgba(255,255,255,0);
    border-radius: 0.1rem;
    width: 25%;
    margin: 5rem auto;
}
blockquote {
    margin-left: 3rem;
    padding: 2rem;
    background: rgba(125,125,125,0.15);
    font-size: 0.9em;
    border-radius: 0.4rem;
    position: relative;
}
blockquote:before {
    content: "“";
    font: 5em "Merriweather";
    color: rgba(125,125,125, 0.2);
    position: absolute;
    top: 0;
    left: -3.8rem;
}
/*  Yes, there are reasons why these aren't simply for pre  */
pre.md-fences { background: none; } /*  Remove trailing background from code blocks */
.CodeMirror-code { padding: 1rem; } /*  For code blocks */

.code-tooltip-content {
    border-radius: 0.3rem;
    box-shadow: 0.2rem 0.2rem 0.3rem #999;
    padding: 2rem 1rem;
}
.code-tooltip.md-hover-tip { background: inherit; } /*  Override base-control.css, use the one above    */

/*  Reformat footnote display   */
.footnotes { color: #fff; }
.md-def-name:before,
.md-def-name:after { position: relative; }
span.md-def-name {
    margin-right: 1rem;
    min-width: 0;
    padding: 0;
}

span.md-def-split { display: none; }

/***********************************************
Stylize toc-panel and make #write fit properly
************************************************/
.pin-outline #outline-dropmenu { padding-left: 1rem; }
.pin-outline .outline-active { display:block; margin-left: -1em; }
.outline-item:hover { border-color: transparent; }
.sidebar-content li { font: 900 1em "Roboto slab"; }
.pin-outline #write { margin-left: 0; max-width: calc(100% - 300px); }

[rahuldave]

Thanks!

[abnerlee]

No plan to implement the complicate selection dialog. For those who need this, use @import in base.user.css or related css file will achieve this.