Open-data is a huge talking point right now, especially with the [GDPR](https://en.wikipedia.org/wiki/General_Data_Protection_Regula...) regulations coming out this year, the discussion around social media and other factors effecting our electoral process, and much more.
Static site generators like Hugo make it trivial for almost anyone to author and share data in open-formats, applying powerful filtering and control over what pieces of your datasets are made available.
And another custom output format to dump search index in JSON for the whole site (to be used by sorts of fuse.js, lunr.js, etc.)
(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):
position: fixed; /* Possibly problematic */
visibility: hidden; /* Possibly problematic */
z-index: -99; /* Possibly problematic */
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...
* * *
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.
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.
Hopefully the user simlevesque will report the same.
Happy to help.
I don't always moonlight as a vigilante CSS debugger, but I am sometimes possessed by curiosity.