In fact, I was so hacked-off about the whole thing that, a few days ago, I yanked the giscus section yet again.
Yesterday, I brought it back — and, this time, with code that makes it behave the way I wanted from the start.
At least, I did until a few days ago, when I learned that it shouldn’t even be working in any browser.
I gained this unexpected knowledge when, on the “got-questions” channel of the Discord server for Jared White’s The Spicy Web site, I described the technique and asked whether there might be a way to make it work in Firefox, too.
White, a long-time professional web dev, replied in part:
I’m honestly surprised it works like that in Chrome and Safari. I would naturally assume any HTML there is “live” even if it’s hidden before the
details[element] is open.1
. . . which meant that it was Firefox, not Chrome and Safari, which had been handling this correctly from the start! Or, to put it another way, I had been depending on buggy behavior to make something work; and that’s never wise.
innerHTML property. However, despite my subsequent and extended futzing that stretched into this past Friday morning, I was unable to get his suggestion and my site to play nicely together.
The first thing I did as a result was to unhide the giscus section — i.e., I took away the “button” and just let the section load with the page on all browsers. I also added the following update to a couple of giscus-related posts:
innerHTML. While there apparently are workarounds for this annoyance, I finally decided they weren’t worth the trouble.)
Then, only a few hours later, I decided that approach wasn’t acceptable, either. After all, I now was inflicting the giscus load on all my visitors regardless of whether they wanted it. What made that still more egregious was the fact that there are actually very few comments on any of my site’s posts, so that load usually would be happening without giving my visitors any benefits whatsoever.
One other nagging complication, albeit not as important, was that I couldn’t style the giscus section to comply with the light/dark toggle I’d recently installed here. The giscus section came in as an iframe from the remotely hosted giscus app, and I couldn’t figure out how to make it implement a visitor’s chosen light/dark setting.
I decided these aggravations were too much, so I removed the whole giscus section once more.
However, by the following afternoon, my no-longer-overheated brain decided I should at least research the whole thing once again.
Well, first, I don’t like failing, and I clearly had failed.
Second, I knew that there ought to be a way it all should work — including the light/dark toggle.
Third, even if the answer turned out to be something that I couldn’t implement for whatever reason, I just wanted to know, period. A nerd’s curiosity knows no bounds.
So, digging through search results and trying a seemingly endless string of attempted code fixes, I worked late into one night and then was back at it not many hours later the next morning.
In the end, I found the solution chiefly from reading the comments, and adapting code left in them, by Sage Abdullah (giscus’s creator and maintainer) and Marcos Ruiz in Issue #336 within the giscus repo.2 The issue concerned dynamic theme changing — i.e., like my concern about the light/dark toggle — but also provided me enough info to see how I could give a visitor the power to control the conditional injection of the giscus script.
In other words, I could have everything I’d wanted, after all. Bingo.
Once I finally had it all working properly yesterday afternoon, I restored the comments “button” under each post on this site. Now, on all of the big three browsers, the code performs as I’d originally intended:
- Once the comments section appears (simultaneously toggling the “button”’s legend to “Hide comments,” instead), it instantly uses the same light/dark setting as the rest of the page.
- If the visitor toggles the light/dark setting for the page, the comments section again follows that setting.
Edited for style. ↩︎
Of course, this is a one-way thing: i.e., once you have the JS load, clicking the button again doesn’t undo that load. The only way to get rid of it is through a page refresh, which restores the page to its default behavior. ↩︎