Show/Hide Script-Free (Which Means CSS Only)

There are many ways to hide and show content with a click (or tap or poke or key-press or …). Many of them have JavaScript under the hood and nearly all of them have dependencies on third-party libraries and/or CDNs. This may be fine when you already have to load a pile of script on a page. This may also lead to poor development practices.

You can mitigate that JavaScript failure with a little CSS-only progressive enhancement. If you lean on the :target selector you only need two lines of CSS for the most basic show/hide feature:

.expando {
  display: none;
}
.expando:target {
  display: block;
}

I made a sample to show it in action:

See the Pen Show/Hide Script-Free by Adrian Roselli (@aardrian) on CodePen.

Supporting older browsers that don’t know what to do with :target can be as simple as wrapping the CSS in media queries or using conditional comments (for old Internet Explorer).

From here you can layer all your nifty JavaScript animated effects, key bindings, and so on.

What Prompted This Post?

I was at the W3C looking for all the accessibility-related specs. I saw the list of groups of specs, saw the blue text that implied I could click (underlines are inconsistently applied, so they aren’t a consistent clue) and something would happen, but was unable to get anywhere.

A quick view-source showed me that those weren’t links nor buttons (no a href and no button to be seen). Checking the console I saw the following error: Uncaught TypeError: Cannot read property 'substring' of undefined

The script was failing and since the a href is added after the page is served, the error prevented any controls from being added, leaving the content I wanted unavailable. The raw HTML looks like this:

<div class="trviewcat expand_block closed">
  <h3 id="tr_Accessibility__All_">
    <span class="expand_section">Accessibility (All)</span>
  </h3>

I grabbed a screen shot that shows (what I think) are all the relevant bits:

The page is set up to show all the content expanded if there is no JavaScript support. That’s a good practice to support users who cannot get the script (bad connections, firewalls, etc.).

The script then comes around and collapses all the content and adds a hrefs to make it all work. Unfortunately, if the script breaks after it collapses the content but before the links are added then users are left in a bad spot. Adding the a hrefs server-side could mitigate that, reducing the scenarios where the page breaks.

I want to be fair to the folks at the W3C who built this. Nobody can reproduce this issue. I can’t reproduce it on any other browser (so far) besides Chrome, and it works properly if I visit the page in incognito mode. If I turn off all my Chrome extensions, however, the page still breaks. I just haven’t figured out what part of my configuration breaks it yet.

More on Progressive Enhancement

• Understanding Progressive Enhancement
• Progressive Enhancement: Past, Present, and Future
• Progressive Enhancement is not about JavaScript availability