Build a JSON API with Hugo's Custom Output Formats

True. We use it for our Algolia search index too (documented here: https://forestry.io/blog/search-with-algolia-in-hugo/)

Don't know why you were downvoted, the problem is present for me as well (latest Chrome/Linux).

Disabling JavaScript fixes the problem — I can't be bothered to debug the problem specifically right now.

If you're not in the habit of browsing with JavaScript disabled, and you want to disable JavaScript quickly, open the Chrome dev tools, open the dev tools settings, scroll to the bottom of the options, check "Disable JavaScript" and reload the web page.

You can leave the dev tools panel open and re-enable JavaScript when you've finished reading the article.

(If you already know this, forgive me — I meant no offence, just being helpful).

EDIT: okay, so being the curious person I am, I did a little digging and uncovered the problem.

Basically, there is an aside element which, from its class name 'search-results' and id 'search', is most probably used to display search results (using ajax to load results into a panel which is supposed to appear above content like a modal window, saving the user a page load, bla bla bla).

Anyway, the interesting part is how this modal panel is made. Here is the CSS for said element (comments are added by me):

    .search-results {
      background: #fff;
      bottom: 0;
      left: 0;
      overflow: scroll;
      position: fixed;    /* Possibly problematic */
      right: 0;
      top: 0;
      visibility: hidden; /* Possibly problematic */
      z-index: -99;       /* Possibly problematic */
    }

This element is being treated as being on top of the main body of the web page, and since it is sized to fit the full window (absolutely-positioned and fixed-positioned elements are treated as filling the viewport if the containing element is statically-positioned, and if their top/left/right/bottom properties are set to 0), the browser does not pick up any scrolling of the actual article.

Now, I'm guessing that one of two things is going on. Either:

• latest Chrome either has some kind of bug regarding layer compositing (note the z-index: -99 property which should tuck the aside element behind the rest of the content i.e. preventing the aside element from interfering with scrolling of the article); or

• visibility: hidden and z-index: -99 aren't enough and either the element needs to be sized when the results are displayed or the element needs to be display: none until the results are displayed.

If it's the former, you and I just need to wait for a version of Chrome that has this bug fixed. Given that others aren't experiencing the problem, it's either Chrome specific or even specific to our build.

It may of course not be a bug — Chrome may be functioning correctly and other browsers may have an oversight regarding layer compositing. I'd need to check the position property of the parent body element.

EDIT AGAIN: okay, so actually I've just picked up on the fact that this troublesome aside element is set to position: fixed by default, which is the real cause of the problem. Whether Chrome specifically treats elements with position: fixed as being always on top, regardless of the presence of an explicit z-index property, is unclear. I think Chrome allows fixed-position elements to be given a layer order if they are within another fixed-position element or an absolutely-positioned element, but not a default i.e. statically-positioned or relatively-positioned element.

Also, to clarify one thing about how visibility: hidden works — it does indeed make an element invisible, but it doesn't prevent interactions with said element. This is the intended behaviour for this CSS property.

Anyway I'm rambling on now. This property probably ought to be set to position: fixed ONLY when the element is actually shown, and should be position: absolute until then for the z-index -99 to actually work. That said, I don't honestly know what the intended behaviour in browsers should be...

* * *

This problem goes away if JavaScript is turned off presumably because this search functionality is intended to use ajax to load results in the aside element results panel, i.e. without a full page load, and thus without JS enabled it just defaults to the old fashioned behaviour of triggering a page load to a results page. I guess.

So, the solution for you and I and anyone else affected is to either browse the page with JS disabled or you can go into the Chrome dev tools, find the aside element (id "search"), right click it and delete it.

This can also be done with a trivial bit of vanilla JavaScript in the browser console:

    document.getElementById('search').parentNode.removeChild(document.getElementById('search'));

* * *

To the developers of this website, if you are here: I recommend you apply either:

• transform: scale(0); or

• position: absolute; or

• display: none;

to this aside element until it is meant to be visible, at which point the property can be changed to the value you want, i.e. transform: scale(1), position: fixed, or display: block.

The transform is probably the best way, as messing with positioning and display properties might mess with any animation effects you might have for the search panel.

I mean, that's just so that it wouldn't get in the way for some of your users (though we may be a minority).

I'm interested to know if it's a Chrome bug or if all browsers should treat fixed-position elements like this with no absolutely-positioned or fixed-positioned parent elements.

And yes, sadly position: relative on the html or body elements would be insufficient — at least, I tried it and it didn't work in my Chrome version.

Scrolling works fine for me. Are you on Mac?