Scrollable/scalable sidebar

I've adapted this theme for use in a tutorial - it looks great, but one issue is that since the material is more static than a blog I'm using the sidebar to enumerate it. This works very well when the window is large enough, but on smaller screens the sidebar crops content without any way to scroll (at least on Chrome/OSX).

I'd like to figure out how to allow the sidebar to scroll and/or dynamically resize its content as appropriate. I may well look into this myself and send a pull request, but figured I'd file the issue here to let you know and welcome any thoughts you have. Thanks!

Hi @soycode, I also read the issue you referenced on 2 Jun, yet it's not clear to me if you could solve it and how.

For now I fixed it by adding a min-height condition also required (and) for the fixed side bar situation. When the window height is less than a value I empirically found based on my side bar content, the sidebar switches to top-of-content position, scrollable, same as already being done by Hyde-X in "portrait mode", when the width gets smaller than a certain value:

.sidebar {
  text-align: center;
  padding: 1rem 1rem;
  color: rgba(255,255,255,.5);
  background-color: #202020;
}
@media (min-width: 48em) and (min-height: 42em) {
  .sidebar {
    padding: 2rem 1rem;
    position: fixed;
    top: 0;
    left: 0;
    bottom: 0;
    width: 18rem;
    text-align: left;
  }
}

OFF-TOPIC: I encountered the issue you raised after introducing some padding to add further separation among the items of the sidebar menu, otherwise Google tests suggest that the items are too close to each other and that it could be difficult to operate on certain devices.

I was tempted to report about it with my simple fix, as I'm tempted to report about a few other issues, but one previous issue I have raised days ago has been so far totally ignored, although not less important functionally than this one, so I'm not sure if I should keep trying to contribute, maybe the devs here already have their route in mind and this kind of issues is already on their TO-DO list, and obliging them to answer is wasting their time...

Alas I fear I will have to ask here about some build errors I'm getting, with various different optimization tools, maybe there's a recommended optimization tool to avoid them with Hyde-X.

OOOPS just noticed this issue had already been closed.

@JazzTp, thanks for looking into this - no worries, I think this was closed automatically by that aborted pull request, but I think it would still be good to fix if there's a way to do it that doesn't mess up the non-scroll use case.

I'll try out some of the things you suggested and see how they look, but I would also suggest that you fork this repository, make your changes, and send a pull request. @zyro, the maintainer, is friendly and accepts constructive changes that don't mess up the default use cases.

I think it's also appropriate to file further issues and submit other fixes. There isn't really any developer dedicated to a project like this, zyro no doubt has other things going on and for the most part projects like this advance when folks like zyro or you or me have a need to improve them, and not because of a specific request. So, don't see issues as something to wait for others to pick up - see them as a place to discuss and work out a fix together.

Anyway, as I said above thank you for your investigation on this, it does look promising - I'm not at all a CSS expert, but I'll let you know if I have any thoughts. If you want to ask your questions about build errors/optimization tools as well feel free, though to be honest I'm not sure what you're getting at - there isn't really any tooling required for this template other than hugo itself. If you're talking about how to deploy a hugo site, you may find this helpful - https://github.com/freedomjs/tutorial/blob/master/deploy.sh

That is a script that rebuilds the site in its repo, and then pushes both the "source" (the unbuilt hugo files, including the template) to the master branch and the "built result" (static website, .html files etc.) to the gh-pages branch (which can of course then be set to show up on the web, e.g. http://www.freedomjs.org/tutorial/).

This response is already likely too long so I'll cut it here - just to reiterate, thanks again, please do feel welcome to contribute!

So from experimenting with your site, it does look like your CSS works as expected in terms of repositioning the sidebar when there isn't room. I do still think that an actual proper scroll may be nice too, e.g. with the tutorial that I linked the sidebar is too tall for some actual computers and it may be confusing to have a "tablet" interface. Part of me would still prefer a scrolling sidebar in those situations, but realistically your approach may be cleaner and more consistent overall (as it's hard to judge between "small window on a desktop" and "normal window on a phone/tablet").

I also noticed that your sidebar seems to be top-aligned rather than bottom (and the same is true of my tutorial site), which isn't necessarily bad but is different from the current default. Whatever approach we settle on, if we want to get it merged in the mainline it shouldn't (by default) change the current look for cases where it is working. I do think that something needs to change for cases where the sidebar just overflows as that looks and behaves brokenly.

Hi @soycode, thank you for the nice wave :)

I've seen this is pretty long, putting titles...

First of all, thanks for inviting me to contribute. I'm not totally new to the git flow, remote clone, pull request... thank you!

The sidebar aligned up

It's not the default, agreed. You adopted it too if I understand correctly, so I don't need to mention that it is kind of an option.. quoting from hyde.css:

/* Sticky sidebar
 *
 * Add the `sidebar-sticky` class to the sidebar's container to affix it the
 * contents to the bottom of the sidebar in tablets and up.
 */

The issue in "portrait mode", click on a sidebar item and nothing apparently happens...

I didn't raise a pull request because I didn't think they would like to adopt the anchor way, that was sincerely explained in the issue :) Maybe you're right and that's actually the simplest and most effective way.

As for the name of the anchor, I had been very tempted by something with the word "content" indeed, and admittedly I hadn't thought of the simplest option, "content" alone... nice :) In "portrait mode" it's clearer than "pagetop"... maybe in "landscape mode", to the average visitor, not Hugo user, "pagetop" is clearer... but I admit that I like "content" more, agreed.

Tools to build/optimize

I didn't mean deploy (by now you noticed I'm online, I mentioned the domain in the issue I believe http://www.nicolabernardelli.com).

They use to call "build" or "optimize" the process of compiling/translating from eventual other languages/metalanguages (jade, sass, less or whatever) into html, css and js and then optimizing, meaning checking what's really used and only keeping that, optionally fetching remote resources and making local the parts of them which are really used. This can involve css, js, html, or the three of them.

It's often done through java software, often modules based on npm, node.js... you'll find an enormous amount of pages on the web and especially on GitHub you'll find many "gulpfile" and "gruntfile" pages.

It is not always clear to me how to use some of them, where they expect to find their input and where you are expected to look for their output, so you must look into them and it can be time consuming.

Alas, I have found many "readme" files about gulpfiles which only say "my gulpfile" or "the gulpfile I'm using on all my projects", and have found very few "readme" which mention the tasks their gulpfile actually performs, like if it acts on css and js only or html too and how, minifying only or doing concat too...

The min-height fix

I didn't raise a pull request for that either, because the value is really dependent on your sidebar content. I could eventually add mention of that possibility in the readme and issue a pull request with that, but again I suppose they'd easily come out with a better and more generic fix, once they notice the problem (not being able to access the whole side bar is actually an issue... with my current sidebar it's probably a remote eventuality that in "landscape mode" the height of the sidebar doesn't fit the screen height, but you say yours has enough content to really show the issue systematically).

And BTW yes, I had tried to have a nicely scrolling sidebar but ran into problems and really needed to get it done and eventually improve it later, so I prioritized functionality and having already whole accessibility of the sidebar.

Padding

Having the sidebar items more distant from each other might actually be the only generic improvement I might have proposed as a pull request, but you say you have many items in the sidebar, would you like that? (Besides, just after the Google tools I used to check my site suggested those items were too close to each other, I accidentally went to their main search engine page and on my cell phone their items were even closer to each other than our sidebar items LOL.)

@JazzTp @soycode Very interesting discussion!

@JazzTp soycode is right, this project is unfortunately fairly low priority for me. I created it back when I needed a theme for my site and had a lot more time on my hands. These days I mainly make sure new versions of Hugo don't break it. :smile:

Portrait mode issue I'd like to avoid JS as well, but scrolling to the content using an anchor is an imperfect solution. I've been hoping to find time to play with a pure CSS hamburger menu like this. There must be a heap of drop-in libraries that "Just Work"(:tm:).

Build tools I'm hesitant to put together a Gulp/Grunt file, even as an optional build step. A lot of this should really be handled by Hugo itself, such as minification of resources. If you have a neat solution you can run as a one-liner just after a Hugo build, please share! :+1:

max-height I like the idea, because of the wide variety of devices I also use. I haven't been able to find a CSS solution that makes the sidebar scrollable, but the content still aligns bottom as the design requires. I'm keeping my eyes open for a good solution here.

Padding The default padding at least ensures the links are readable and spaced far enough apart to behave nicely when clicked/tapped. This kind of small tweak I'd recommend doing as an override in your own site.

May I also suggest that in future we open separate issues for each discussion topic? It helps keep them separate and coherent. :smile:

@zyro Roger (= understood) everything, thank you!

CSS drawer menu

It's very nice. (It should maybe come with a fallback for older browsers, I guess 2-3 years old smartphones like mine are probably already in that category).

It could be a nice alternative to the side/top bar for small devices (I guess the added css code would not make a huge amount of extra data to download).

Build tools

Of course I'd share. After looking into various gulpfile pages and trying some, the last tool I've been trying out is optimum.

As I said, I faced build errors. Searching for the same errors on the web, I've seen nobody trying to fix them so far, it's probably just out of reach if font-awesome or the highlight pack trigger such errors. Experienced web developers apparently just switch to some other version of the same resource or quit using it. Because of build errors, I have already excluded highlight and *added an option to also avoid using font-awesome () :( I guess both moves would not be an option for many who would just choose not to optimize instead... I'm tempted too... I'd need to get to a nice setup in order to be able to forget about it for a while**, and later, eventually, after fulfilling other priorities, come back to this subject and see if newer (or older) versions of those resources go through the process without triggering any errors.

min-height

The problem is that the number is not generic, there might be one default value and a note with the need to override it according to the sidebar content.

Padding

With the default, I had complains about items too close to each other and possibly difficult to operate on certain devices (kind of true on my old LG P500) from this tool https://developers.google.com/speed/pagespeed/insights/ and it seemed to be fixed after I added a margin (which admittedly I should move out of hyde.css, overriding elsewhere):

.sidebar-nav-item {
  display: block;
  line-height: 1.75;
  margin-top: 0.5rem;
}

Separate issues for the future

Roger, my fault, I didn't know if new issues would be teasing overtaken developers (I'd understand that, I'm constantly badly overtaken these months trying to navigate to a different future LOL), so while answering to @soycode I mentioned other "items" asking for suggestions. He suggested to open an issue about build tools, and I did actually. I'd share there when I have any good news.

And of course, roger that Hyde-X is not at all your top priority at present, that's more than understandable.

Thanks again!

*()** Switching back to font-awesome 4.2.0 solved for many out there apparently, but not here for me, the older version triggered the same error, I'll retry with other tools but many of the most promising ones seem to depend on the same modules).

BTW, I have installed a brand new hard disk with Linux Fedora for this. node.js on Windows (and cygwin64 or MINGW32) are very fine tools but on npm stuff I was getting mad about dependencies... npm install is working just smooth on Linux, where there's a suitable *package.json file of course.

@zyro, I came to add something because I had this phrase still resonating in my ears:

A lot of this should really be handled by Hugo itself, such as minification of resources.

Well, I'm a newbie to most of this topics but... that sounds to me like asking Hugo to perform a whole additional set of tasks which it does not claim to be dedicated to, and bringing in a whole new "world", as vast as it seems to me now the range of tools dedicated to optimization.

Hugo, as for what I understood so far, is not really "aware" of the content of the pieces of code that we throw in our templates, it basically permits us to send to output parts of code (valid or not) based on conditions... it's a lot more than that of course and permits to organize data based on different indexes/taxonomies... but that's the basic mechanism I believe and incorporating the optimization layer would probably make it much more complex and much harder to maintain... unless that is done in a separate stage, but then gulp/grunt/optimum/and-the-like are already out there.

As I said, I'm a newbie so I might very well be missing something that you see very clearly how to implement :smile:

@soycode I realized today that the container class should also adapt like the sidebar, I mean that in "portrait mode" there's no reason to have the left indent, because the sidebar is on top instead of aside.

.content {
  padding-top:    4rem;
  padding-bottom: 4rem;
}

@media (min-width: 48em) and (min-height: 42em) {
  .content {
    max-width: 38rem;
    margin-left: 20rem;
    margin-right: 2rem;
  }
}

@media (min-width: 64em) and (min-height: 42em) {
  .content {
    margin-left: 22rem;
    margin-right: 4rem;
  }
}

As you can see, in order to have coherent behavior, I put the same min-height value that I had empirically found for the sidebar, so the content is centered, instead of indented to the right, under the same conditions which make the sidebar switch to "portrait mode". This was the sidebar fix:

.sidebar {
  text-align: center;
  padding: 1rem 1rem;
  color: rgba(255,255,255,.5);
  background-color: #202020;
}
@media (min-width: 48em) and (min-height: 42em) {
  .sidebar {
    padding: 2rem 1rem;
    position: fixed;
    top: 0;
    left: 0;
    bottom: 0;
    width: 18rem;
    text-align: left;
  }
}

Just to contribute back what I settled on:

@media (min-width: 48em) {
    .sidebar-sticky{
        top:1rem;
        overflow-y:auto;
        overflow-x:hidden;
        height:100%;
    }
}

This makes the sidebar vertically scrollable when necessary (no visible scrollbar when not needed), though it does end up top-aligning it as well (I believe due to the height 100%). Still, a net improvement in my case, and simple enough approach.

I'm not sure what if anything makes sense to push back to the main theme - if it's preferred to just keep it as is and assume that scrolling is a fringe case, that's fine by me. The solution from @JazzTp (min-height trigger) also may be a sensible default.

Thanks @soycode - you solved the problem I was experiencing due to a large number of static pages in my side nav.

zyro / hyde-x