Minimal-mistakes: Add support for additional right sidebar to take advantage of the empty space at the right (where TOC is typically placed)

[ohadschn]

I think it could be very handy to have the author profile on the left, and a custom navigation sidebar on the right (rather than having to choose one or the other as they compete on the same spot on the left sidebar). When there's no TOC (for example in the home page and taxonomy index pages) the right side space feels a bit wasted, and putting something like a list of recommended posts there would be perfect.

[mmistakes]

UI wise this sort of makes sense, but I'm not really sure how to bake it into the theme. There's too many conditions to contend with and if I open this one up for customization it could really make things complicated for both the maintainer and user.

[ohadschn]

What's the difference between TOC and this? Couldn't you have the same exact behavior as TOC, only with user-supplied entries/links (you could even lock it down to a single list of links if it makes it easier to handle)?

[mmistakes]

TOC is defined in a post via Kramdown's auto table of contents feature, where as the sidebar nav is done through YAML Front Matter.

What happens when someone defines a sidebar and a TOC?

[mmistakes]

There are layout considerations too. The way I'm injecting the TOC to the right now is a bit of a CSS hack. It get's complicated with the sidebar because that would live outside of the post, where as the TOC lives inside, so that could be a challenge to layout correctly.

They're essentially two different beasts. That's why I put it in the left sidebar where it's built similar to the author links.

[ohadschn]

What happens when someone defines a sidebar and a TOC?

As Bjarne Stroustrup would put it, "undefined behavior". Or, if you can identify such a case, simply pick one and only display that. Not all features must coexist, certainly if the alternative is simply not to have one of them...

Can you implement the same hack you did for the TOC for such a right-handed sidebar?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity.
If this is a bug and you can still reproduce this error on the master branch, please reply with any additional information you have about it in order to keep the issue open.
If this is a feature request, please consider whether it can be accomplished in another way. If it cannot, please elaborate on why it is core to this project and why you feel more than 80% of users would find this beneficial.
This issue will automatically be closed in 7 days if no further activity occurs. Thank you for all your contributions.

[ohadschn]

@mmistakes should I keep bumping this so the stale bot doesn't close it? Even if you don't plan on implementing it someone else might (I'm being hopeful I know :])...

[mmistakes]

You can if you want. I have it flagged as under consideration because I haven't been convinced it needs to be in the theme.

[mmistakes]

I'm designing for the majority, and this feels like an edge case i don't really want to support.

[ohadschn]

If we agree that the official WordPress "Twenty-x" themes are designed for the majority (presumably WordPress are data-driven), then the right sidebar is integral: https://wordpress.org/themes/twentyseventeen/.

[mmistakes]

Thing is since the original release of MM, the "sidebar" has been on the left and treated as ancillary author info.

I've never been a fan of the typical blog layout with a junk drawer on the right that holds content, ads, table of contents, etc. Which is why I designed MM to be content focused with the minimal of author info on the left and content centered to its right.

Over the years it has gotten bloated with "enhancements" to add every social network under the sun, support custom content, do navigation lists, etc. And adding a right sidebar to do the same fundamentally goes against my original intentions with the theme. Which one could argue is why the theme is popular in the first place.

I can feel it slipping into "designed by committee" territory and that's something I'm trying reign back in. Especially since I'm the sole maintainer, problem solver, designer, and developer. If it's a feature/enhancement I don't believe in 100% there's no chance of it living.

With all the custom stuff in the theme it can be extremely confusing to get up and running with, and hardly earns the name "minimal mistakes" in those cases.

[ohadschn]

Well, you have put yourself in a bind by supporting TOC on the exact same space, so now you can't say it's bloated :) No good deed...

Seriously though, I don't think a couple of "recommended" posts would be clutter, and it would be configurable anyway (just like navigation.yml, so maybe sidebar.yml). To my mind its purpose is different enough from the author sidebar to be justified.

[mmistakes]

TOC is a different beast. It previously was included in the main content window. I'm only using a CSS hack to push it out to the right since it looks better visually, and has less overlapping issues with block elements.

Recommended posts are pretty much the same thing as the "related" posts the theme currently supports. They appear below the posts. Too much of a distraction on the right.

There's plenty of themes out there that do the layout you want. MM can't possibly be all things to all people.

[mmistakes]

Seriously though, I don't think a couple of "recommended" posts would be clutter, and it would be configurable anyway.

Nothing stopping from you forking and creating your own theme that exhibits your aesthetic.

[ohadschn]

Last time I checked the only serious gem-based blog themes out there were MM and Minima. The latter was too minimalistic so IMHO MM really is the only serious choice out there (unless something drastic changed in the last 1-2 months). Congrats :)

As you probably already know I'm a big fan of gem upgrades which is why I'm not going to fork the theme, rather try and contribute / convince you. Emphasis on try :)

[mmistakes]

There are boatloads of gem themes

https://rubygems.org/search?utf8=✓&query=Jekyll+theme

[ohadschn]

Yeah and I probably went over all of them, if memory serves very few (if any) even came close to the level of maturity and features of MM. Again, congrats 💯

[ohadschn]

How would you recommend I go about hacking this on my site? Basically I'd like the least amount of overrides and the greatest degree of gem upgradability while adding a modified right sidebar that would probably end up looking like this:

<aside class="sidebar__right">
    <nav class="toc">
        <header>
            <h4 class="nav__title">Featured Posts</h4>
        </header>
        <ul class="toc__menu">
            <li><a href="/2017/01/foo/">Featured Post 1</a></li>
            <li><a href="/2016/02/bar/">Featured Post 2</a></li>
            <!-- ... -->
        </ul>
    </nav>
</aside>

[mmistakes]

1. Try to mimic your "featured posts" markup to match the existing TOC markup. Then it can share presentation and styling. Quick glance above that looks like what you've done.
2. Drop it into _layouts/single.html, probably as an include, and maybe behind some sort of conditional {% page.featured_posts %}{% include feature-posts.html %}{% endif %}.

The single layout would be the only file you need to override. It's a minimal change (likely a line or two depending on how you include the code), so maintaining it shouldn't be a problem for you. The layouts rarely change anyways so it's fairly safe.

[ohadschn]

Thank you Michael for your advice. I gave it some thought and I have two issues with it:

1. I want the featured posts to be present on all pages, including the home page, categories page, etc.
2. If single.html does change one day, I won't know about it.

So I guess I'll try my go-to move of adding a script that adds it dynamically to the page. Something like $("section.page__content", "div.archive").first().prepend('<aside class="sidebar__right"></aside>').load("_includes/featured-posts.html"). Does that seem reasonable?

One more thing I want to do is disable it on mobile/small displays. Basically have the same condition you currently have that determines whether the TOC is displayed on the right or below the title, except that I'll remove it completely. How would you recommend I go about that (preferably in a gem upgrade safe way)?

[mmistakes]

I don't know if that JavaScript above will work. _includes files won't be something the browser will be able to access. You most likely will need to render it into your page somewhere during the Jekyll build, then use JavaScript to move it somewhere else.

As far as floating the TOC to the right or keeping it inline on mobile. I'd try to reuse .sidebar__right which absolutely positions the sidebar to the right on large and up.

https://github.com/mmistakes/minimal-mistakes/blob/master/_sass/minimal-mistakes/_sidebar.scss#L59-L76

.sidebar__right {
  margin-bottom: 1em;

  @include breakpoint($large) {
    position: absolute;
    top: 0;
    right: 0;
    width: $right-sidebar-width-narrow;
    margin-right: -1 * $right-sidebar-width-narrow;
    padding-left: 1em;
    z-index: 10;
  }

  @include breakpoint($x-large) {
    width: $right-sidebar-width;
    margin-right: -1 * $right-sidebar-width;
  }
}

[ohadschn]

Good catch on the _includes file. I guess I could create a dummy page with the featured posts HTML and change the load call to something like .load("featured-posts.html nav.toc") (that is, only load the nav element from the compiled dummy page).

As for the mobile adjustment, if I understand correctly all I have to do in order to get the same condition is add some featured-post class to my featured posts element and add something like this in my main.scss:

.featured-post {
    display: none
    @include breakpoint($large) {
      display: block;
    }
  }

[mmistakes]

Yes. That's the right approach for showing the featured post on $large viewport widths and up.

[exetico]

@ohadschn - I would like to hear, how you ended up - if you like to share it. I'm just looking into how to make a few basic changes, if i'm going to change some stuff in the future.

[ohadschn]

@exetico In the end Michael's arguments convinced me I could do without such a featured posts section and instead I added some stuff to the author pane.

However, before that happened I did have some sort of POC in place which you can check out here: https://gitlab.com/ohadschn/ohadschn.gitlab.io/commit/e851074863e069ba8b0a912ec80309ec3d1d6916.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity.

If this is a bug and you can still reproduce this error on the master branch, please reply with any additional information you have about it in order to keep the issue open.

If this is a feature request, please consider whether it can be accomplished in another way. If it cannot, please elaborate on why it is core to this project and why you feel more than 80% of users would find this beneficial.

This issue will automatically be closed in 7 days if no further activity occurs. Thank you for all your contributions.